以前、「ベテランエンジニア」としてご紹介いただきました、shimashimaです。社内では開発をしつつもテストを中心に動いていたり、業務外ではソフトウェアテストシンポジウム JaSST(Japan Symposium on Software Testing) Tokyoに実行委員として参加していたりします。

今回の記事では、 2018年6月16日〜17日に開催されたWACATEという勉強会の参加レポートをします。

WACATEとは

WACATE（ワカテ）という名前は、 Workshop for Accelerating CApable Testing Engineersの略称で、主に若手テストエンジニア向けのワークショップを開いています。有志で運営しているワークショップで、1泊2日でソフトウェアテストをテーマとした合宿形式の勉強会を年2回開催しています。

この合宿では、ソフトウェアテストの体系的な勉強や、テストエンジニア同士の交流をすることができます。もう10年近く続いている会ですが、私自身は今回が初参加でした。ずっと気になっていた会ではありますが、ちょうど今回のテーマ「モデリング」がテスト以外でも使える上に、自社で導入しやすいのではと思い、参加を決めました。

また、今後社内でWACATEを勧める際に自分が行っておく必要があったのも参加の理由の一つです。

参加者紹介

shimashima：今回参加にあたり、他のエンジニアがもし興味があればと思い、slackで募ってみたところ、yasuとdanbo-tanakaの二人が参加表明してくれました。私とは参加理由が違ってくると思うのですが、参加理由を教えてもらえますか？

yasu：メディア事業部に所属するエンジニアのyasuです。ピクシブの各サービスに配信している広告関係の開発およびディレクションを担当しています。普段から単体テストを書いていますが、よりソフトウェアテストについて学んで開発に活かしたいと思うようになりました。より上流のテストを学んだら開発がより良くなるはずだと思ったことが、WACATEへの参加のきっかけです。テストエンジニアと交流したいという思いもありました。

danbo-tanaka： BOOTHのiOSアプリを担当している、テストYATTEIKIエンジニアです。ピクシブには今年の6月に百合転職で入社をしました。参加理由は主に4つあります。

開発エンジニアとして、テストエンジニアが集まる空間で知識と雰囲気を感じて視野を広げるため
レガシーコードを整理し改善するためのヒントとして、モデリングやテストの方法を知るため
機能開発とバランスをもってテストしていくための方法を知るため
テストエンジニア界隈を知るため

shimashima：ありがとうございます。テストエンジニア界隈の会は他にはあまりないので、視野を広げるものとしてはとても貴重な会だと思っています。

WACATE当日

shimashima：当日は、UMLを使ったモデリングとテストケースの導き方について学びました。今回対象となったUMLはユースケース図、アクティテビティ図、状態遷移図の3つです。また、特別公演として原因結果グラフについての説明と演習も行いました。

復習会もあるほどに熱気があり、参加者みな真剣だったように思います。その当日の様子は、ブロッコリーさんもあげてます。

WACATE 2018 夏に参加しました #WACATE

WACATEに参加して

　すべてをテストすることはできない

shimashima：ではWACATEに参加してどうだったのか、各人に聞いてみます！

yasu：僕は2日目午前中のワークショップが特に面白かったですね。

shimashima：「やらないことを決める」経験ができるようにワークショップの設計がなされていましたよね。140分という限られた時間で、システムの要求に対してUMLでモデリングを行いテスト項目まで導くという内容でした。

danbo-tanaka：テスト対象のもつ条件の組み合わせはあまりにも膨大で、時間などのコストとの兼ね合いがあるため、テスト界隈では「すべてをテストすることはできない」というのが通説となっています。

WACATEはこれを疑似体験できるように、時間制限がシビアに設定されたワークショップ設計になっていました。時間というコストとの兼ね合いで、どういうテストでどこまでを担保するのか判断させる内容でした。

yasu： A4の仕様書1枚からテストパターンを作成したんですが、大人6人がかりで140分かけても、全然時間が足りませんでした。

この「すべてをテストすることはできない」というのは割と当たり前なことで、テスト技術者資格制度シラバスのFoundation Levelのテスト7原則の中でも以下のように触れられています。

全てをテストすること(入力条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスクや優先順位によりテストの焦点を絞る。 (http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf の15ページ目から抜粋)

僕が過去に読んだときには、正直実感が湧きませんでした。でも、WACATEに参加した今なら絶対無理だとわかりますし、あまり意味のあるものじゃないとわかります。

今回のWACATEでは、アクティビティ図、ステートマシン図、シーケンス図でそれぞれワークがありましたが、どれも時間制限がシビアで初めて触れるテストパターン列挙の試みに苦戦しました。

列挙するということは、一度取り組んでしまうとゲーム感覚になって夢中になりがちですが、WACATEのワークは、全部テストすることはできないから優先度を考えてテストパターンを考えなさいという暗黙的なメッセージを抱えた課題になっていたことが印象的です。

danbo-tanaka：そうですね。個人的にレポーティングしたブログでも書いてますが、「すべてはテストできない」ことを前提に置いて、何をテストしないかを決めるという考え方が僕にとっても良い知見になりました。

「テスト設計ハッカソン」的な言葉がしっくりくるように感じます。どういう観点でどこまで担保すれば良いか、なぜそう判断するのかをチーム毎に話し合いながら、最終的にUMLを成果物としてテストの妥当性をプレゼンすることになっていましたが、適切なテスト手法や観点を得られるかどうかの他に、タイムキープの能力も求められる内容でした。

yasu：時間感覚だけではなくテスト観点でも学びがあり、仕様書の漏れに気づく人がいたり、システムで最重要な重要な部分がどこであるかについてチームメンバーでアイデアを出しあったりしました。実務では、テストの観点について話し合う機会が少ないので、様々なバックグラウンドを持つメンバーとの議論は、ためになりました。

shimashima：テストに対する説得力を持たせるために、自分たちのチームは何をどこまで優先させるかを決める必要がありましたね。

ワークショップの後、最後に各チームから成果物とともに手法や方針などについてのプレゼンがありましたが、それはどうでしたか？

yasu：成果物発表では、同じ課題に取り組んだ各チームの成果物がそれぞれ異なったことに驚きました。A4一枚の仕様書で意外と異なるんだなと。各チームの発表後、2-3分の短い時間でしたが、どうしてそうしたか、こういう場合こうじゃないのかなどの質問がたくさん飛び交っていました。

同じ課題に取り組んでいたので、活発な発表会となりました。どの人も丁寧で配慮のある質問の仕方をしていたことが心に残っています。おかげで存分に話ができました。

shimashima：そうですね。WACATEの良さは、かならず手を動かすワークショップになっていることだと思います。手法についての座学を行った後、演習が行われるということの繰り返しになっています。決して聞くだけのスタイルはなく、実際に自分で実践することで納得感をもって学ぶことができるのではないでしょうか。

プロダクト開発を主とするエンジニアとして

shimashima： WACATEの参加を通じて、日々の開発への向き合い方が変わった事例などありますか？

yasu：以前から、UMLを書いてシステムの概要を説明する機会はありましたが、テストパターンを出すために利用することは初めてでした。他人に伝えるためのツールだと思って使っていたUMLですが、テストパターンを作るときにも有用だとは気づきませんでした。

WACATEを通じて思ったことですが、どんな人も何かしら抜け漏れがあるのでどんな経験者でも完璧はないんだなと実感しました。完璧にできないなら、他人と議論するためにより伝えやすく図を書こうと思いました。

これまで実装寄りのテストについて考えがちだったのですが、設計段階からテストについて考える大枠からアプローチできる手段を手に入れたのは大きな収穫でした。

danbo-tanaka： UMLは様々なプログラムに出てくる複雑なものに対処するために便利ですよね。今回はテストケースの漏れを確認するためにUMLを使いましたが、テストに限らず、開発という立場でチームメンバーとの共通理解を得たり、仕様の漏れを確認するのにも有効なツールです。それを理解できたのは大きなことでした。

shimashima：私も、もともとUMLは知っていたものの、仕事で使う機会はあまりなかったですね。UMLの使い方とテストでの活かし方を学べたことも良かったですが、それ以上にyasuさんdanboさんが来てくれて共通言語ができたことに意義があると感じています。

いま社内の設計を表現するときはどうしても文章が多いですが、全体図を表す時にUMLを使った方が伝わりやすいと感じています。書いても読み手が理解できなければ意味はないので、UMLを理解できる人が増えたことはありがたいです。

yasu：また、「テストは上流から入り込まないとテストできる構造にならない」という点も一つ面白かった学びでした。

小さいモジュールの単体テストでは、すべてのパターンを網羅することができますが、システム設計から考える場合、観点が多すぎてテストパターンを網羅することができません。

そういったシステムの要所などをワークでメンバーと議論している時に、テストは開発にも役立つと確信しました。開発のチームとシステムの要所についてすり合わせれば、モジュールの粒度や開発の優先度などのすれ違いが起こりづらくなりそうだな、と。もし上流からテスト設計できない場合、開発がうまく進んだとしてもかなりテストがしにくい粒度や設計にもなるだろうな、と思いました。