リリースに最低限必要なテストをどう見極めるか

はじめに

先日「ソフトウェアテスト自動化カンファレンス」に登壇させていただいたのですが、懇親会にて「リリースに最低限必要なテストをどう見極めるか？」という議論が起こりました。面白かったので私なりの考えを書いてみようと思います。

リリースの頻度とテスト

かつてのソフトウェア開発では、リリース後の変更・修正コストが高いなどの要因から「完璧な製品をリリースし、その後は基本的に変更しない」考え方が主流であり、リリース前に様々な可能性を考慮する必要がありました。必然的に、ソフトウェアはいちどに多くの複雑さを扱うことになり、その複雑さを検証するためのテストもまた複雑なものになりました。複雑なドメインを分析し、膨大な組み合わせのテストを考え、重箱の隅をつつくようなテストを考えることが求められました。
しかし、リリース後の変更・修正コストが徐々に下がってきたなどの要因から「必要最低限の製品をリリースし、その後は継続・反復的に開発し続ける」考え方に時代が変わってきました。例えば、リリースサイクルを1週間と決めて、サイクルごとにリリースを繰り返すイメージです。リリースごとに求められるものは、リリースに最低限必要な設計と実装であり、テストも必要最低限に絞って設計する必要が出てきました。

では、必要最低限のテストをどう設計すれば良いのでしょうか。私なりに4Stepで考えてみました。

必要最低限のテスト

Step1.明確な変更点

例えば、「日本円で合計金額を表示する」機能があるとして、「USドルでも合計金額を表示できる」変更をするとします。この場合、「USドルで合計金額を表示できる」ことは最初に思いつくテストでしょう。明確な変更点についてのテストは、要件に書かれていることを右から左に書き写すだけで組み立てられるので、実務でも特に見落とすことはなく、この記事の冒頭にある議論の範疇には含まれないように思います。

ところで、「日本円でもUSドルでも合計金額を表示できる」機能が完成するとすれば、「日本円とUSドルの表示を相互に切り替えることができる」機能が必要になるかもしれません。必要ならば実装もテストもするし、「いや、まずはUSドルで表示できさえすればいいから、切り替えられなくても今回はOKだと」ということなら実装もテストも不要です。どちらが正解ということはないのですが、どちらに意思決定したかは関係者間で共通認識を作っておく必要があるでしょう。

Step2.暗黙の前提

仮に、このサービスが複数のブラウザをサポートしているとします。このとき、各ブラウザで「USドルでも合計金額を表示できる」テストをする必要はあるでしょうか。
「USドルで合計金額を表示できる」を実現するためには、暗黙の前提として様々な要素が関係します。例として、ユーザーの種別や、ソフトウェアが動作する環境の種別、表示に用いるデータの種別、ソフトウェアを取り巻く法律などが挙げられます。これらは、(Step1で挙げた)明確な変更点だけに目が行っていると抜けがちなポイントですが、かといってこれらの要素を全て網羅してテストする必要があるかは別の話です。

テストの考え方として、このような状況で個人的によく見聞きするのが「リスク分析」の考え方です。もし不具合が発生したときの影響の大きさと、発生頻度の2軸で考えることが一般的なようです。これについても正解はないのですが、リスクを関係者間で話し合ったうえで、どこまで細かくテストをするか意思決定することが良いと思います。

Step3.過去の経験

Step2後段のリスク分析の話にも関係してきますが、過去の経験、特に、過去に発生した障害の情報を思い出してみることには価値があると思います。私の経験の範囲では、Step2で挙げたような何らかの暗黙の前提に対する考慮が欠けていた場合が多いです。大事なものは、きっと関係者みんなが覚えていると思いますが、障害の記録を取っておくのもひとつの手段だと思います。

Step4.いま現在できていることの維持

ここは補足的な話ですが、「USドルで合計金額を表示できる」変更を行なった結果、「日本円で合計金額を表示できなくなってしまった」のであれば問題です。いま現在できていることが維持されていることは、テストとして考えておく必要があると思います。

ほどほどに議論する

ここまで、私なりに「必要最低限のテスト」の軸となりそうな要素を4つのStepとして書いてみました。これらを、あまり時間をかけずに議論することも重要だと思います。重箱の隅をつつきに行ってしまうと、結局リリースは遅れてしまいます。この「ほどほど」のバランス感覚は関係者のスキルなのではないかと思います。スキルであるならば、最初はみんな下手ですが、思考と経験によって鍛えることができるでしょう。

なにが「ほどほど」かという点については、これも正解はないと思いますが、個人的には「次回のリリースを待つことができるか」あたりがラインだと思っています。

補足：万が一間違っても大丈夫な仕組み

最後に補足として、間違ってしまっても大丈夫な仕組みの必要性に触れます。見極めが常にうまくいくとは限らない以上、本番環境に致命的な不具合をリリースしてしまうこともゼロにはならないでしょう。ですから、何か問題が起きた場合に迅速に対応できる仕組みが併せて必要になります(Blue/Greenスイッチやフィーチャートグルなど)。この仕組みが無かったり、弱かったりするうちは、やはりリリース前のテストを厚くするしかないでしょう。

おわりに

私なりに、普段からモヤモヤと考えていたことを文字にしてみました。勢いで書いてみたのでいろいろと突っ込みどころがありそうな気がしますが、今後の議論のたたき台になればとても嬉しいです。今回記事として書いてみて、個人的にもとても楽しかったので、このテーマには引き続き取り組んでいきたいと思います。