どのくらいテストすれば十分なのか? (更新版)
ソフトウェア開発チームでよくある質問の1つに「いつテストをやめるべきか?」というものがあります。「不具合がすべて見つかったらテストをやめる」と言えば簡単です。しかし、ソフトウェアテストではアプリケーションに欠陥がないことは分かりません。分かるのは、「何がテストされたか、どのような欠陥が発見されたか」のみです。そのため、テストをいつ止めるかを決定するために、さまざまな手法が開発されてきました。書籍や非常に多くの論文が執筆され、多数のプレゼンテーション、講義、ワークショップがこの質問に答えるために開催されてきました。
最近、RanorexはPulse Research社と提携して、ITリーダーに対し「十分なテストを実施したと判断するタイミングをどのように決めているのか」を尋ねました。下記のグラフはその回答を示したものであり、下記でそれについて説明します。
メトリクスの使用
上のグラフの一番上にあるのは、テストの状況を評価するために使用する定量的な尺度であるメトリクスです。十分なテストを行ったかどうかを判断するための一般的なメトリクスには、次のようなものがあります。
- 成功した重要なテストの割合：（成功した重要なテストの総数/実行された重要なテストの総数）* 100
- 成功したテストの割合：（成功したテストの総数/実行されたテストの総数）* 100
- テストでカバーされた要件の割合（コード カバレッジ）：（テストされた要件の総数/要件の総数）* 100
- 実行されたテストの割合：（実行されたテストの総数/テストの総数）* 100
- 成功した重要なビジネス フローの割合：（成功した重要なビジネス フローの総数/テストされた重要なビジネス フローの総数）* 100
また、これらのメトリクスを以前のリリースサイクルと比較して、アプリケーション開発とQAプラクティスの改善を測定することも有効です。サイクルごとに実行されるテストの数は増加していますか、それとも減少していますか？毎回、より多くの重要なテストが成功していますか、それとも数が減っていますか？
Go/No-Goミーティングを開催する
Pulse Research社の調査では、テストの中止を決定するための一般的な方法として、2番目にGo/No-Goミーティングの開催が挙げられています。「Go/ No-Goミーティング」というと、宇宙船の打ち上げを準備する管制チームのようなイメージを持たれることが多いようです。チームの各メンバーは、利用可能なメトリクスをレビューした後、最新のソフトウェア リリースをリリースする準備ができているかどうかについての推奨事項を作成します。
しかし、名前は Go/No-Go と二択に聞こえますが、Go/No-Goミーティングでは実際には3つの結果を出すことが可能です。
- Go -リリースはデプロイ準備ができている。
- 注意点あり – 特定された問題が一定時間内に解決される場合に限り、そのリリースをデプロイできる。
- No Go – リリースはデプロイ準備ができていない。チームは、次のGo/No-Goミーティングをスケジュールする前に完了しなければならないアクションアイテムを特定する。
メトリクスだけでは十分なテストができたかどうかを判断することはできません。重要なテストの98%が合格していることは、チームにとってどのような意味を持つのでしょうか？それで十分ですか？それとも、100％のテストが成功する必要があるのでしょうか？ここで、Go/No-Goミーティングが役に立ちます。
収益率の低下を適用する
このグラフの最後の要素は「収益率の低下」という概念でグループ化することができます。ある時点で、ソフトウェアテストを継続するコストは、その利点を上回ります。これは、次のいずれかが発生したために起こる可能性があります。
- 許容できる最小限の欠陥率を達成した：欠陥率は、(欠陥の総数/テストされたモジュールまたは機能) として計算できます。許容できる欠陥率は、アプリケーションの性質によって大きく異なります。航空機や宇宙飛行（英文）のような人命に関わるシステムは、ゲーム機よりもはるかにエラーの許容度が低くなります。
- プロジェクトの納期に達した：ソフトウェア開発において、テストに十分な時間をかけられるかどうかは一般的な課題です。Pulse Research社と共同で行った最近の調査では、現在のソフトウェア開発プロセスでQAテストのための十分な時間を確保できていると強く同意した IT リーダーはわずか13%でした。また、56%は十分な時間があることに「やや同意」しています。
- プロジェクトの予算に達した：時間がないのと同様に、利用可能な予算もまた、テストを中止するタイミングを決定する要因になりえます。
適切な質問をする
カンファレンスのスピーカーであり、アジャイル アライアンス、スクラム アライアンス、米国品質協会（ASQ）のメンバーであるPeter G. Walen氏は、「いつテストを中止するか」という質問について、異なる見解を共有しました。以下は Walen氏の発言です。
ある開発チームから違う質問をされました。その開発チームは多くの種類のテストをおこなっており、対象システムをさまざまな観点からテストしています。彼らは、「要件に対する簡単なチェック」から「要件を中心としたテスト」へとテストを進めており、また、過去に問題となった個所を深く掘り下げていました。
彼らは、「要求事項」や「受け入れ基準」では網羅されていないが、対象システムへのこれまでの経験から、トラブルの原因になりそうな個所について調査していました。また、ユーザーがどのようにソフトウェアを使用し、どのような動作を期待しているかという知識も活用し、調査しました。
彼らは、手動テストと自動テストを組み合わせて実施していました。テストによってカバーされる領域は、対象システムについて何を調べようとしているかによって、複数のレベルに分かれていました。あるものは、CI 環境で使用できる単純な「スモーク テスト」であり、あるものは、システムのセグメント間の相互作用を調べる、より複雑な統合テストでした。
彼らの質問は、「これらすべてのテストを定期的に実施しています。そして、製品の変更に合わせてさらにテストを作成しています。いったいどれほどのテストを実施すれば十分と言えるのでしょうか？」というものでした。
ステップ 1 : 開発チームが言う “十分” とは何かを特定する
「十分なテスト」についての質問は、組織によっては混乱を招くかもしれません。ある組織では、”テスト” とは、例外やエラーがない状態で正常に実行される、いわゆる「ハッピーパス」での、正常な期待動作を確認するものである、と理解しているかもしれません。「1つの要求：1つのテスト」という考え方は一般的です。問題は、これはある組織では許容できても、他の多くの組織では不十分であることです。
また、冒頭で紹介したような取り組みをおこなっている組織もあります。
- 彼らは可能な限り多くのシナリオをカバーします。
- 意味のあるテストは、 CI テストスイートに含まれています。
- その他のテストは、自動化された統合テストと回帰テストのスイートに含まれています。
- 過去に興味深い結果や予想外の結果をもたらしたテストをツールで実行しているので、熟練したアナリストは新しい仕事に集中でき、自動化ツール（英文）で実行できるステップを繰り返すことに時間を費やさずに済みます。
他のほとんどの組織は、この両極端な状況の狭間にいます。
ステップ 2: 「思ったよりもテストをしていない」という罠を避ける
多くの組織は、自分たちが思っているよりも、最低限の「1つの要件：1つのテスト」に近い状態にあります。簡単なテストシナリオが作成されますが、これは自由回答形式の質問に近いものであり、正常値や異常値などの異なるデータを使い、さまざまな手順で何度も実行されるシナリオです。
このようなテストで期待されるのは、要件を中心としたテストです。ただし、納期が迫っていたり、納期を過ぎていたりして、「テストを終わらせなければならない」というプレッシャーが大きくのしかかっているときには、本来ならば 7～8回実行するところを、2～3回しか実行しないかもしれません。また、可能性のあるすべての論理パスを認識していたとしても、その一部しか実行しないかもしれません。
時間の都合でテストが省略されます。「このテストはこの要件を検証する」というチェック項目だけを見ている人は、「検証」が実際に何を意味するのか考えようとしないでしょう。彼らは「思ったよりもテストが少ない」という罠に陥っているのです。
意図は存在し、目標も認識することができますが、その目標には達していません。
ステップ 3: 「キッチンシンク」 の罠を避ける
開発チームや組織によっては、ありとあらゆる動作や値の組み合わせをテストでカバーしようとします。彼らは、システムで可能なすべてを評価して完全に文書化できるか、少なくともそれらの可能性を十分にカバーすることができるテスターを求めています。
そして、テスターはテストを繰り返すことを期待されます。すべてのリリースとビルドに対してです。
必要な作業量には圧倒されます。テストを自動化しようとしても、回帰テストですべての機能テストを実行し続けることは不可能です。結果として、テストは省略されてしまいます。時間のかかる複雑なテストの代わりに、早く簡単に実行できるテストがしばしば選ばれます。
なぜでしょうか？その理由は、開発チームリーダーは多くの場合、作業の大変さを理解すると、テストの何割かだけを実行することで良しとするからです。小さな簡単なテストを実行することで全テストの80％を実行できれば、テスト チームはより慎重な検討が必要な新機能に時間を集中させることができるからです。
ステップ 4: 適正なバランスを見つける
「十分」という考えは何を意味するのでしょうか？ 両極端な考えの間にバランスがあります。そのバランスがどこにあるかは、状況によって異なります。
私は、主要な機能を徹底的に調査し、副次的な機能も適度にカバーできるようなレベルのテストが、多くの場合に上手くいくと考えています。他の機能よりも多くまたは少なくテストする機能については、関係者やプロジェクト チームと話し合い、全員が合意する必要があります。その上で、回帰テストや統合テストを変更に応じて更新する必要があります。
これらをどこでおこなうかは、組織、チーム、プロジェクトによって異なります。要するに、私が冒頭で紹介したチームは、非常にうまくバランスを取っていたということです。最初から上手くいくことはほとんどなく、多少の努力と忍耐が必要になります。しかし、それだけの価値があるのです。
作者について：
この記事は、2021年1月にPeter G. Walenによって書かれたものです。2022年3月にRanorexチームによって更新されました。Peter G. Walen は、ソフトウェア開発、テスト、アジャイルの実践において25年以上の経験があります。彼は、自分たちのソフトウェアがどのように動作し、他のソフトウェアやそれを使用する人々と相互作用するかをチームが理解できるように支援することに尽力しています。彼は、アジャイルアライアンス、スクラムアライアンス、米国品質協会（ASQ）のメンバーであり、ソフトウェアミートアップに積極的に参加し、頻繁にカンファレンスのスピーカーを務めています。
（この記事は、開発元 Ranorex 社 Blog 「How Much Testing is Enough?」2022年3月14日の翻訳記事です。）
