mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

WACATE2016夏に参加してきました!

こちらのイベントに参加してきた感想を書いていきます。
WACATE2016 夏 ~走りきるテスト設計~ 開催概要 - WACATE (ソフトウェアテストワークショップ)
togetter.com

WACATE2016夏 1日目

オープニング

WACATEのオープニングはいつもとてもテンションが高まっていて、気合が入ります。
今回はついに常連枠になってしまったので、僭越ながらも「わからないことがあったら聞いてください」と言いました。
責任感とか、重みある立場になった感じがします。

ポジションペーパーセッション

ポジションペーパーを使って自己紹介をしました。
今回は初参加の方も多いようでしたが、私の班はテストの経験自体は自分よりも長い方が多くいました。
あと、ポジションペーパーが若干とがった内容だった(勉強して実践しないとかありえないでしょ?みたいなこと書いた)のでとても話しづらかったです。

BPPセッション

個人的に大ヒットのセッションでした。
私は、今の品質保証の部署に新人からストレートに配属され、開発の経験は1年弱しかありません。それも、設計はほとんど行わず、だいたいは実装と単体・結合レベルのテストで終わりました。(しかもCOBOLの!)
なので、設計の経験がほとんどないです。しかし、テストなり品質保証なりしていく中では設計の知識が必須だといつも感じていて、ここでも「テスト活動も「段階的」戦略で構造設計が必要」といった、ソフトウェア設計の経験・知識がテスト設計に生かされるという内容が発表されていました。
「目的認識、構成要素選択、関連性と相互作用の決定」といった内容はまさに、アーキテクチャ設計の話です。
改めて、テスト設計を学ぶからこそソフトウェア設計を学ぶべきだと感じました。

個人ワーク(テスト分析)

仕様書一式(画面定義書、データモデル定義書、業務フローとか色々)を渡されて、それを40分くらいで分析しました。
自分は「マインドマップから始めるソフトウェアテスト」のやり方に沿って、三色ボールペンで仕様分析、マインドマップの書き起こし(ブランチは画面単位にしました)、そこからテスト項目への落とし込み…をやろうとして時間切れでした。
マインドマップのブランチをどう置くかでかなり分析結果が変わってきそうです。そもそも画面単位に分割するやり方が妥当なのかも怪しいです。
後述しますが分割するときは既存のフレームワークを使って分けられるといいのかなと思いました。

※ 三色ボールペンはイマイチ使いこなせないでいたのですが、アドバイスをいただいたり色々試してみたりして、以下のやり方を見つけました。ご参考までに。
三色ボールペン仕様分析術がうまく実践できない場合の対応策 - 自分、燃えてるんで。

座学:テスト設計技法

当日の発表資料については、公式サイトのプログラムのページに載っています。
WACATE2016 夏 プログラム内容 - WACATE (ソフトウェアテストワークショップ)
今回、Foundation Levelのテスト技術者シラバスを事前に予習してくることが必須だったのですが、確かにその内容をしっかりと踏まえられていてとても勉強になりました。
今回紹介されたのはテスト設計技法の初歩的な部分ではありますが、適切なタイミングで適切に技法を選択するというのは思っているよりも難しいです。
ユースケーステストなど、実践するとなると意外とよくわかっていないことがあります。改めて復習しなければと思いました。

グループワーク1(テスト分析)

ここでは、各グループで個人の分析結果を見せ合い、一つのベースを選択するあるいは作り出すということをしました。
今回私のチームでは色々な分析結果が出てきたのですが、今回は「経験的に必要そうなテストの種類に基づいて、具体的なテストすることを洗い出した」という分析パターンをベースにすることとしました。ここでいうテストの種類は、議論の中で付け足したり直したりということもできそうで、かつグループのメンバーがなんとなくそのプロセスに納得感があったためです。
あれこれ意見出しをして、必要そうなテストを拡充していきました。

ディナーセッション

ディナーセッションでは、「パーソナルソフトウェアプロセス入門」という、今まさに欲しいな〜と思っていた本を偶然お譲りいただくことができました。とてもうれしいです。最近読んだCMMの本とも関連しているようで、少しずつ読み進めています。

夜の分科会[テーマ:セキュリティテスト]

セキュリティテストについては、申し込み時に自分が関心があった分野なので分科会オーナーを買って出ました。
以下に簡単に議論内容について示します。

セキュリティテストって機能テスト?非機能テスト?

ここの線引きがよく分からない、という話が出ました。例えばアクセス権限の管理機能のテストは、機能テストなのか、それとも非機能テストなのか。
意図的に脆弱性を突くとか、機能レベルの品質確保にプラスして保障しなければいけないセキュリティ的な品質がある場合に、セキュリティテストと呼ばれるのではと話していました。

セキュリティテストのゴールって何?

しかし、セキュリティテストというのはイマイチゴールがよく分からないよねという話があります。というのも、「これでセキュリティについてはOK!」みたいなことは言えないのではと感覚的に思うからです。ツールを使用したりアウトソーシングしたりしたとしても、結局どこまでやればいいのかという疑問は解消されません。
そこで、まずは脆弱性としてどのようなものがあるか洗い出した上で、それに対するアプローチを考えるという手法もあるのではという議論になりました。脆弱性のリストを作成するときは、以下のようなリンクが役立ちそうです。
Japan - OWASP
気をつけるべき脆弱性のトップ10が載っています。「OWASP TOP10 2016」で検索しても出てくるそうです。
脆弱性対策:IPA 独立行政法人 情報処理推進機構
脆弱性に関する調査結果やレポートが掲載されているIPAのページです。
また、セキュアに開発するプロセスを定義し、それに沿って開発することでセキュリティを担保するという考え方も紹介されました。以下のリンクがその資料です。
Microsoft Security Development Lifecycle
ドメインによっては要件定義の段階から「このようなセキュリティ要件を満たしていること」という規格があり、それに対する監査をすることで網羅性を確認することもあります。
例えば以下に示すのは、PCIDSSというカード情報を扱う際のセキュリティ規格です。これは情報セキュリティスペシャリストの試験対策本にも載っていました。
PCIDSSとは|日本カード情報セキュリティ協議会

セキュリティスペシャリストとテスト技術者

今回、分科会参加者でもなかなか実際にセキュリティテストを実践したことがあるという人は少なく、セキュリティのスペシャリストとテストのスペシャリストはドメインが重ならないのかもという話をしました。セキュリティは特に進歩も早く、専門的なセキュリティ技術者が必要とされるのもその一因かもしれません。

分科会の後に

分科会の後は、モデリングの話をしていました。これもとても興味深かったです。
こちらのブログにも、議論の内容についてまとめられています。
toshimana.hatenablog.com
僕は恥ずかしながらMVCモデル自体初見だったので、数少ないソフトウェア開発の経験を思い返して話についていくのがやっと、みたいな感じでした。
その時は近くにあったエアコンのリモコンを例にとって議論をしました。温度調整機能はどのレイヤーで、それを呼び出すところ、温度の状態を管理するところ、いやパネルにも状態があるのでは、などなど。
状態が増えるとテストも増えますから、状態を減らすための手法(宣言型プログラミングなど)があるとのこと。
しかしここでやっていることも結局は階層的に抽象化/詳細化を行っているというだけで、本質的には特殊なやり方をしているというわけではないのかなと思いました。
私は最近、こう言った設計や実装周りの知識が足りていないことを強く認識しているので、このような議論や交流は積極的にしていきたいと思っています。
ちなみに、「UMLモデリング、オブジェクト指向がよく分からない」という話をしたら以下の本をオススメされました。

また、そのオブジェクト指向の原点とされる構造化設計についても、本屋で買ったデマルコの「構造化分析とシステム仕様」を読んでみています。これもわかりやすく、基礎から学べて勉強になります。

WACATE2016夏 2日目

ゲストセッション 分解について(秋山 浩一氏 富士ゼロックス株式会社)

秋山さんによる、分解の基本的な考え方の講義を聞きました。
粒度を揃えて分解すること、適切なラベルをつけること、数を増やしすぎず適切な階層化をして全体を見えるようにするのが大事とのことでした。また、分解するときは思いつきでやると漏れたりしてうまくいかないので、USDMとか既存のフレームワークをうまく活用すると良いとのことです。
このあたりは実際にやってみないと感覚がつかめなそうな印象でした。

グループワーク2(テスト分析・続き)

秋山さんの講義を踏まえて、粒度や階層の見直しをしました。
ここでも色々と議論がなされましたが、比較的グループで合意を取りながらスムーズに決めていけたように思います。

グループワーク3(テストケース設計)

具体的なテストケースをどんどん作成していきました。一部、デシジョンテーブルといったテスト技法を活用するところもありました。

グループワーク4(発表資料作成)

ここで、グループで問題に直面しました。
今回、経験的に必要そうなテストの種類を大分類としているのですが、なぜそれで十分かというのが説明できないのです。
「今回のテストではそこまでは保証しない」というストーリーで発表を組み立てましたが、ややモヤモヤも残り・・・

発表&振り返り

ワールドカフェ形式の発表となりました。
自分は2つの班を聞いてきたのですが、チームによって進め方、工夫点、成果物が全く異なっていたことに驚きました。
ユースケース中心に網羅するチーム、画面遷移を中心に考えるチームなど、どのチームもそれぞれの特色が出ていたように思います。

私のグループは、先述した課題を当然他のチームの人に突っ込まれ、うーん。という印象でした。
そこまで踏み込めた議論はできなかった、というのが正直なところです。
作ったテストがうまく説明できない、というのはとてもモヤモヤが残るところとなりました。

お越しいただいていたレジェンドの方からは、「テストの目的」についてより一段階深い検討が必要なのではと言われました。
ユーザーがどう使うか(一晩放置して翌朝に操作、とか)、一番どうなることを避けたいか(例えば、システムを使うことで友達を無くすとか)というところにもっと目を向けられたのではとのことでした。
改めて、足りない視点があったことに気づかされました。

クロージング

二日間の振り返りと、ポジションペーパー3賞の発表がありました。
選ばれた作品はどれも、ご本人の思いを的確に表していたり見どころのあるものでした。

自分が提出したポジションペーパーの反省として、もっと図解してわかりやすく表現すべきだったかなというのがあります。
大量の文章を参加者の方は読むわけなので、その中で「おっ」と目を引くには、やはり図解したり強調したりしてポイントを示す必要があります。
また、次回はもっとこれまで学んだことをアウトプットする場としてポジションペーパーを活用してみようかと思っています。
ひとまず、次回のWACATEの日程(12/17, 18)は手帳に書いておきました。

後夜祭

後夜祭でもいろいろと面白い話題が出ました。
はじめは「お客さんに納得してもらえるテストって何?」という話になりました。
にしさんも言われていたことなのですが、「網羅していることを証明する」というのは不可能です。
なので、なぜこのテストになったのか、その理由と経緯を説明し、それを納得してもらうのがゴールになるのではないかと話していました。
そのためには、ワークでやった分析をどう進めていくかが重要になります。
他にも、ワークに対する色々な意見や感想、次にやってみたいことを話せて有意義な会でした。

個人的な感想「テストエンジニアも、設計を学ぶべき」

WACATEにいくたびに思うことですが、まだまだ山ほど学ぶべきことがあります。
実践ももちろん大事ですが、基礎となる知識が全然身についていないと感じました。
あまりに悔しくて、当日終わって帰宅した日の夜中に描いたマインドマップがこれです。
f:id:mhlyc:20160715230605j:plain

また、特に今回の構造化、分割の考え方は設計の考え方そのもので、これは仕事ではやっていないことです。
ですが直近の仕事でも必要になる考え方なので、今回オススメしてもらった本などで独学していきます。

私は、理想として品質保証は、「設計・開発の上位職」であるべきと思っています。
つまり、要件定義〜設計、開発の全てにおいて卓越したスキルと実践経験を持ち、プロジェクトを成功に導く存在です。
こんな人がいたらそれだけでプロジェクトにとっては大きな価値となるわけですが、ここまでたどり着くのは果たしていつになるやらと思います。

そうは言っても、やはり設計スキルはテストエンジニアにとっては必須スキルだと改めて思いました。
構造を分割してわかりやすくし、それらの相互関係を明らかにし、モデルで示す。テスト設計もソフトウェア設計も、結局やることは同じだからです。

改めて、WACATEの実行委員会の方には感謝しています。
今回出てきた色々な悩みも、こうして実践する機会があったからこそ出てきたものです。
学んだことを実務に活かせるよう、きちんと手を動かして復習をしようと思います。

7/15 追記
ということで、WACATE復習会を開催しました。まとめはこちらです。
togetter.com

まずは7月の連休でたまったタスクを消化しつつ、来月に受験予定のテストマネージャ試験に向けて学習を進めたいと思います!