2021年8月27日 / 最終更新日時 : 2021年8月27日 user 事例・ソリューション

どのくらいテストすれば十分なのか？

ソフトウェア開発チームでよくある質問のひとつに、「いつテストをやめるべきか？」というものがあります。この単純な質問には、さまざまな答えがあります。この質問に答えるために、数多くの書籍や論文が出され、多くのプレゼンテーション、講演、ワークショップがおこなわれてきました。

また、ある開発チームから違う質問をされました。その開発チームは多くの種類のテストをおこなっており、対象システムをさまざまな観点からテストしています。彼らは、「要件に対する簡単なチェック」から「要件を中心としたテスト」へとテストを進めており、また、過去に問題となった個所を深く掘り下げていました。

彼らは、「要求事項」や「受け入れ基準」では網羅されていないが、対象システムへのこれまでの経験から、トラブルの原因になりそうな個所について調査していました。また、ユーザーがどのようにソフトウェアを使用し、どのような動作を期待しているかという知識も活用し、調査しました。

彼らは、手動テストと自動テストを組み合わせて実施していました。テストによってカバーされる領域は、対象システムについて何を調べようとしているかによって、複数のレベルに分かれていました。あるものは、CI 環境で使用できる単純な「スモークテスト」であり、あるものは、システムのセグメント間の相互作用を調べる、より複雑な統合テストでした。

彼らの質問は、「これらすべてのテストを定期的に実施しています。そして、製品の変更に合わせてさらにテストを作成しています。いったいどれほどのテストを実施すれば十分と言えるのでしょうか？」というものでした。

開発チームが言う “十分” とは？

「十分なテスト」についての質問は、組織によっては混乱を招くかもしれません。ある組織では、”テスト” とは、例外やエラーがない状態で正常に実行される、いわゆる「ハッピーパス」での、正常な期待動作を確認するものである、と理解しているかもしれません。「1つの要求：1つのテスト」という考え方は一般的です。問題は、これはある組織では許容できても、他の多くの組織では不十分であることです。

また、冒頭で紹介したような取り組みをおこなっている組織もあります。

彼らは可能な限り多くのシナリオをカバーします。
意味のあるテストは、 CI テストスイートに含まれています。
その他のテストは、自動化された統合テストと回帰テストのスイートに含まれています。
過去に興味深い結果や予想外の結果をもたらしたテストをツールで実行しているので、熟練したアナリストは新しい仕事に集中でき、自動化ツール（英文）で実行できるステップを繰り返すことに時間を費やさずに済みます。

他のほとんどの組織は、この両極端な状況の狭間にいます。

「思ったよりもテストをしていない」という罠

多くの組織は、自分たちが思っているよりも、最低限の「1つの要件：1つのテスト」に近い状態にあります。簡単なテストシナリオが作成されますが、これは自由回答形式の質問に近いものであり、正常値や異常値などの異なるデータを使い、さまざまな手順で何度も実行されるシナリオです。

このようなテストで期待されるのは、要件を中心としたテストです。ただし、納期が迫っていたり、納期を過ぎていたりして、「テストを終わらせなければならない」というプレッシャーが大きくのしかかっているときには、本来ならば 7～8回実行するところを、2～3回しか実行しないかもしれません。また、可能性のあるすべての論理パスを認識していたとしても、その一部しか実行しないかもしれません。

時間の都合でテストが省略されます。「このテストはこの要件を検証する」というチェック項目だけを見ている人は、「検証」が実際に何を意味するのか考えようとしないでしょう。彼らは「思ったよりもテストが少ない」という罠に陥っているのです。

意図は存在し、目標も認識することができますが、その目標には達していません。

「キッチンシンク」の罠

開発チームや組織によっては、ありとあらゆる動作や値の組み合わせをテストでカバーしようとします。彼らは、システムで可能なすべてを評価して完全に文書化できるか、少なくともそれらの可能性を十分にカバーすることができるテスターを求めています。

そして、テスターはテストを繰り返すことを期待されます。すべてのリリースとビルドに対してです。

必要な作業量には圧倒されます。テストを自動化しようとしても、回帰テストですべての機能テストを実行し続けることは不可能です。結果として、テストは省略されてしまいます。時間のかかる複雑なテストの代わりに、早く簡単に実行できるテストがしばしば選ばれます。

なぜでしょうか？その理由は、開発チームリーダーは多くの場合、作業の大変さを理解すると、テストの何割かだけを実行することで良しとするからです。小さな簡単なテストを実行することで全テストの 80％を実行できれば、テストチームはより慎重な検討が必要な新機能に時間を集中させることができるからです。

適正なバランスを見つける

「十分」という考えは何を意味するのでしょうか？両極端な考えの間にバランスがあります。そのバランスがどこにあるかは、状況によって異なります。

私は、主要な機能を徹底的に調査し、副次的な機能も適度にカバーできるようなレベルのテストが、多くの場合に上手くいくと考えています。他の機能よりも多くまたは少なくテストする機能については、関係者やプロジェクトチームと話し合い、全員が合意する必要があります。その上で、回帰テストや統合テストを変更に応じて更新する必要があります。

これらをどこでおこなうかは、組織、チーム、プロジェクトによって異なります。要するに、私が冒頭で紹介したチームは、非常にうまくバランスを取っていたということです。最初から上手くいくことはほとんどなく、多少の努力と忍耐が必要になります。しかし、それだけの価値があるのです。

作者について：

Peter G. Walen は、ソフトウェア開発、テスト、アジャイルの実践において25年以上の経験があります。彼は、自分たちのソフトウェアがどのように動作し、他のソフトウェアやそれを使用する人々と相互作用するかをチームが理解できるように支援することに尽力しています。彼は、アジャイルアライアンス、スクラムアライアンス、米国品質協会（ASQ）のメンバーであり、ソフトウェアミートアップに積極的に参加し、頻繁にカンファレンスのスピーカーを務めています。

（この記事は、開発元 Ranorex 社 Blog 「How Much Testing is Enough?」2021年1月14日の翻訳記事です。）