テスト計画とは「納得感」を作ることだ by やまずん

「全数テストは不可能」というソフトウェアテストの原則があります。
ごく単純なソフトウェアを除けば、すべてのバグを見つけることは不可能です。
では、私たちは不完全さを理由に、テストという活動やその責務を放棄してよいのでしょうか？

私はそうではないと考えます。
無限のテストに立ち向かうためには、「どこまでやれば我々の責務を果たしたと言えるか」を定義し、チームで納得する必要があります。
私はそれを「テスト計画」によって示せると考えています。

多くの現場において、テスト計画は「スケジュール調整」「テンプレートを埋める作業」と誤解されていますが、それは本質ではありません。
本来のテスト計画とは、ソフトウェア開発におけるコンテキストを深く理解し、「テストすべきもの」と同時に「テストしないもの」を定義します。
そして、「我々はこれでリリースできる」と納得することです。

本セッションでは、QAエンジニアである私の視点から、テンプレ埋め作業ではない、「テスト計画」という活動を構成するプラクティスを一部紹介します。

「コンテキスト」を集める

「テストはコンテキスト次第」という原則があります。
「なぜ作るのか」「誰が使うのか」、そして「制約」そういった情報を集め、整理することがテスト計画の第一歩となります。

「作ってはいけないもの」を見つける

我々は「作るべきもの」に集中することが多いです。
一方テストでは、「作ってはいけないもの」ということも考える必要があります。
プロダクトリスクと言いますが、これを批判的な問いによって見つけていきます。

完璧なソフトウェアが存在しないように、完璧なテストも存在しません。
しかし、我々はプロとして、「これなら大丈夫」と胸を張って顧客に届ける必要があります。

その方法のひとつとしての「テスト計画」について語りたいと思います。