WACATE 2025 夏に参加いただいた皆さん、お疲れさまでした！
各班の発表後にお話ししたフィードバックですが、時間が足りずに伝えきれなかった部分がたくさんありました。そこで改めて、皆さんにお伝えしたかったことをまとめてみました。参加していない方には「何の話？」という内容かもしれませんが、ご容赦くださいね。
はじめにお断りを…
このフィードバックは、各班3分間の発表とワーク中に拝見した内容をもとに書いています。発表では触れられていなくても、実際にはここで挙げるポイントをしっかり実践されていた班もあると思います。「ちゃんとやってたのに、なんで指摘されるの？」と感じる方もいらっしゃるかもしれませんが、その点はご理解ください。
また、あくまでも、私ブロッコリーの個人的な意見です。WACATE実行委員会の総意ではない点もご理解ください。
1. 「このシステムならでは」を意識できていましたか？
「テストしたいこと」を見ていると、宿泊予約システムなどといった他の予約システムでも同じようなことが書かれているケースがありました。これって、今回の業務ならではの部分をしっかり理解できていないサインかもしれません。
発表で「閉店時間を考えると…」や「このシステムでは、お金よりもまず予約が取れることが重要だから…」といった意見が出ていたのは、とても良い視点だと感じました。そのシステム特有の観点を見つけられると、テストもより価値のあるものになりますね。
2. 取捨選択のタイミングは実は2回あります
今回のワークでは、テスト内容を絞り込むチャンスが2回ありました。
1回目は、テスト分析での優先度付け。ここで「これは優先度が低いからやらない」と判断できたはずです。
2回目は、テスト設計時の網羅基準設定。ルールに従ってケースを洗い出した後、「このケースは実際にはテストしない」と決めるタイミングです。
普段の業務でテスト分析やテスト設計を頭の中だけで済ませがちな方は、この取捨選択が曖昧になっているかもしれません。「なぜこれを選んで、なぜこれを捨てたのか」を明確にしておくことって、意外と大切なんです。
ちなみに、「デシジョンテーブルで表現したけど、ケース数が多くなったのでペアワイズで削った」という発表がありましたが、これは「デシジョンテーブルテスト」と「ペアワイズテスト」を混同されているように見えました。テスト技術は正しく理解して使いたいですね。
3. 想定外で見つけた不具合こそ振り返りのチャンス
テスト実行で時間が余って、当初のテスト設計では考えていなかった部分をテストした方もいると思います（これを「探索的テスト」と呼ぶ人もいるかもしれません）。
そこで不具合を見つけても、「ラッキー！」で終わらせないでください。「なぜ最初のテスト設計で拾えなかったんだろう？」を振り返ってみてください。
今回は偶然その部分を見ただけかもしれません。でも、こういう不具合をもっと確実に見つけるには、テスト設計の段階で組み込めるはずです。この振り返りも、テスト完了というプロセスでやるべき大切な作業の一つだと思っています。
4. 自分たちの現場に合わせてアレンジしてください
今回は要求仕様書と受け入れテスト計画書があったので、3色ボールペン法を使った仕様書読み込みをプロセスに入れました。
でも皆さんの現場はどうでしょう？「もっとしっかりしたドキュメントがある」という組織もあれば、「Figmaの画面デザインしかない」という組織もありますよね。
画面デザインしかない環境なら、3色ボールペン法はあまり役に立たないかもしれません。でも画面により注目することになるので、業務分析をもっと丁寧に行うプロセスがあっても良いかもしれませんね。
また、「普段はテスト手順なんて詳しく書かない」という組織もあるでしょう。それはそれで構いません。ただ、「自分たちはテスト実装というプロセスを省略しているんだな」と自覚しながら業務に取り組むことが大切だと思います。
今回のやり方は、WACATEなりの一例にすぎません。「これが絶対的な正解」と言いたいわけではありません。黒木さんのセッションでもお話があったように、テストプロセスには様々な定義があります。皆さんの組織に合う形にテーラリングしてみてください。
最後に
偉そうなことをたくさん書きましたが、私も日々勉強中です。皆さんと一緒に切磋琢磨しながら、より良いテストについて考え続けていきたいと思っています。
WACATEの内容や今回の投稿について、疑問や意見がある方はぜひ教えてください。お待ちしています！