WACATE2020冬に参加したら「最低限のテストって何？」が見えてきた話
こんにちは、ずんです。
今日もテストや品質のことで、1人悶々と悩んでいます。
最低限のテストって何だろう？
最近何を悩んでいたかというと、「最低限のテストって何だろう？」ということです。
時々、仕事で「今回の変更では、最低限のテストさえできればいいよね！」というざっくりとした会話をするのですが、私自身最低限の定義が分からず困っていました。業務フローを最低限カバーすれば業務が止まらないからいいのかな、いやもっと浅いのか深いのか・・・
WACATE2020冬に参加
そんなとき、2020/12/12, 19の2日間に渡って開催された若手向けテスト勉強会・ワークショップのWACATE2020冬に初参加しました。
WACATEとは、若手（35歳以下）を対象に年2回開催されるワークショップ中心の勉強会です。今年の参加者は実行委員会も含め30名程度でした。ちなみに実行委員会もみんないわゆる若手です。ワークショップではもちろん、休憩中もおしゃべりしたり、お悩み相談し合ったり、意見交換もできて充実した2日間でした。
読みたくなるテスト計画書のお話
中でも楽しかったのは、図やデザインの力を駆使して、読みたくなるテスト計画書をなんと紙にまとめたというお話でした。いわゆるグラレコの技術を応用してテスト計画書が書かれており、一目で惹き込まれるような、すごく見やすくてわかりやすいテスト仕様書でした。
（※登壇者様が会社の許可を得て資料を公開してくださいました。ありがとうございました！）
（※以下、今回の登壇者様の講演内容と休憩中の会話から学んだことです）
発生してはいけない不具合の認識をそろえる
まずはざっくりと優先度についての認識を揃えるため、トレードオフスライダーを使っていきます。例えば、スピード ＞ 品質 ＞ コスト だったとします。このときは品質についての詳細は詰めません。
次に話し合うのは最も怖い不具合の認識を揃えます。要するにそのプロダクトで発生したらニュースになってTwtterで騒がれて関係各位が辛い思いをするようなバグです。（書いていて気付きましたが、これってインセプションデッキの夜も眠れない問題ですね）
例えば業務用アプリだとしたら、最も致命的な状況は「ユーザーの業務が止まること」とかになるでしょう。業務の助けになりたくてアプリを開発したのに、業務を止めたくないですから。
その調子で、残りをなるべく発生させたくない不具合なのか、発生しても許容できる不具合なのかを切り分けていきます。
さあ、テスト計画が見えてきました
1. 最も怖い不具合
2. なるべく発生させたくない不具合
3. 発生しても許容できる不具合
さあ、プロダクトにおいて発生しそうな不具合の優先度付けが完了しました。上記の3つの不具合のレベルについて関係者の認識がそろったとします。そうしたら、この3つの不具合を検出するために立てたテスト計画を立てます。
1. 最も怖い不具合
→より早くテスト対象とし、確実に修正してからリリース
2. なるべく発生させたくない不具合
→全てテスト対象し、修正できない場合は個別にリリース可能か判断する
3. 発生しても許容できる不具合
→テスト対象しない。もし発生してもリリースを優先する。
1. と2. は必ずテストを実施します。1. と2. の違いは、リリース前に修正すべきか否かです。
テストはリリース判断材料となるフィードバックを提供します。
リリースする判断をするためには、少なくとも最も怖い不具合が発生していないことを確認しなくてはなりません。つまり、1. の不具合が発生していないテストを実施することが必須となります。2. は状況に応じて判断可能なので、最低限とは言えません。
つまり、最低限のテストとは最も怖い不具合が発生していないことを確認するためのテストなのです。
もし「最低限のテストを実施して」と言われて1. を実施すると回答した場合に議論が紛糾するようなら、最低限の基準を見直すか、「最低限のテストだけすればいい」という言葉の真相を確認します。
最低限のテストが見えた私が、これから取り組むこと
・最も怖い不具合の認識を関係者間で揃える
・"最低限のテスト"を開発者と連携して作り上げていく
・普段の生活でも、何が最も怖いことかを考えて行動して回避策を練る（リスクマネジメント）
言葉にすると簡単そうですが、実際調整は大変そうだなと感じています。
相手の言葉の奥底の真意を汲み取れるよう、慎重に、丁寧に会話していきたいと思っています。
最後に
こういう他愛もない会話からも発見があって、本当に楽しい2日間でした。WACATE実行委員の皆様には、このような機会を設けて頂いて本当に感謝しかありません。ありがとうございました！