テストを停止するタイミング（ソフトウェアテストの終了基準）

when stop testing

テストの終了基準：

「開始は半分完了しました」–ソフトウェアテストも含め、どこにでも適用できます。

プロジェクトの開始時に、ソフトウェアテスターが非常に熱心であることがよくあります。作成します テストドキュメント テスト戦略、テスト計画、テストケースなどを熱心に熱心に。

次に、BANGを使用してソフトウェアをテストします。これは、プロジェクトの開始時に見つかった興味深い欠陥によってのみ増幅されます。それらを解決することは、私たちの成果に追加されるだけです。

多数の欠陥を見つけて最初の実行を完了すると、次のフェーズに進みます。 2回目の実行に入ると、リラックスします。一般的な人間の傾向も同様です。 同じことをテストすることに飽きる 2回目の実行で。

ソフトウェア工学におけるライフサイクルモデル

多くのテスターはそれが 単調な仕事 後の実行で、同じソフトウェアを何度も何度もテストすることに興味を失い始めます。おそらく3回目の実行に到達すると、1つの質問が私たちを悩ませ始めます。それは、「ソフトウェアのテストをいつ停止するか」です。

少なくとも一度は、同じように感じて、「いつテストをやめるのか」と尋ねたに違いありません。質問は 「いつ、どこで、どのようにテストを停止しますか？」 :)

概念的には読んだことがあり、多くのテスターは、「いつテストを停止するか」を決定するための特定の条件や方程式はあり得ないと考えています。この質問を結論付ける前に考慮すべき多くの要因があります。

今日の記事では、このテストで十分であると言えるテストサイクルのポイントに到達したときに、テストアクティビティを終了する方法についての私の考えを共有したいと思います。これは、典型的なテストサイクルでいくつかの実際の例を使用して行います。

学習内容：

• 十分なテストはいつですか？
• すべての欠陥が見つかったときに停止する：それは可能ですか？
• テストを停止する決定：終了基準
• 完了または終了基準とは何ですか？
• 終了基準には何が含まれている必要がありますか？
• 次の場合にテストを停止できます。
• 結論：
• 推奨読書

十分なテストはいつですか？

これだけのテストで十分だといつ言えるでしょうか。テストを完了することはできますか？

これらの質問に答えるためには、テスト活動を最初から最後まで分析する必要があります。注意してください–私はこれらの活動を素人の言葉で定義します–派手な技術的な方法ではありません。

新しいプロジェクトのテストを開始しているとしましょう。

初期活動：

• テストチームは要件を受け取ります。
• テストチームが開始します 計画 とデザイン。
• 初期テストドキュメントの準備が整い、レビューされます。

テスト実行＃1）

• テストチーム テストの実行を開始します 開発された製品を受け取ったら。
• テスト段階では、ソフトウェアを破壊して多くの欠陥を見つけるために、さまざまなシナリオを実行します。 （また、アプリケーションが新しく、初めて評価を受けているため、ここでの不良率は高くなります。）
• 欠陥は開発者によって修正され、再テストのためにテストチームに戻されます。
• テストチームは、欠陥の再テストを実行し、リグレッションを実行します。
• 重大度の高い欠陥のほとんどが解決され、ソフトウェアが安定しているように見えると、 開発チームは次のバージョンをリリースします。

テスト実行＃2）

• テストチームはテストの2回目の実行を開始し、同様のアクティビティが実行1として実行されます。
• 2回目のテスト実行中のこのプロセスでは、さらにいくつかの欠陥が検出されます。
• 欠陥は開発者によって修正され、再テストのためにテストチームに戻されます。
• テストチームは欠陥を再テストし、実行します 回帰 。

これは永遠に続く可能性があります。ソフトウェアのすべての欠陥が見つかり、ソフトウェアにバグがなくなるまで、3、4を実行します。

これらのアクティビティのフローチャートを作成する場合、大まかに次のようになります。

上記のフローチャートから、ソフトウェアのすべての欠陥が見つかるまでテストを続行できることが明確に結論付けられます。

しかし、問題は–ソフトウェアのすべての欠陥を見つけることは可能ですか？この百万ドルの質問に対する答えを見つけてみましょう:)。

すべての欠陥が見つかったときに停止する：それは可能ですか？

ほとんどのソフトウェアは複雑で、膨大なテスト範囲があります。ソフトウェアのすべての欠陥を見つけることは不可能ではありませんが、それは永遠にかかります。

ソフトウェアに多くのバグを見つけた後でも、 現在、ソフトウェアに欠陥がないことを実際に保証することはできません。 テストが完了し、ソフトウェアのすべての欠陥が見つかり、バグがなくなったと自信を持って言える状況はあり得ません。

さらに、テストの目的は、ソフトウェアのすべての欠陥を見つけることではありません。ソフトウェアテストの目的は、ソフトウェアを壊したり、現在の動作と期待される動作との偏差を見つけたりすることで、ソフトウェアが意図したとおりに機能することを証明することです。

ソフトウェアには無制限の欠陥があります。したがって、どの欠陥が最後の欠陥であるかを知ることはできないため、すべての欠陥が見つかるまでテストすることは現実的ではありません。真実は、テストを完了するためにソフトウェアのすべての欠陥を見つけることに依存することはできないということです。

正直なところ、テストは無限であり、テストサイクルは、いつどこで停止するかが決定されるまで続きます。現在、テストを停止する決定を下すのはさらに複雑になっています。 「すべての欠陥が見つかったときに停止する」がテストを停止する基準ではない場合、どのような基準で決定する必要がありますか？

テストを停止する決定： 終了基準

ここで理解してみましょう–テスト活動を終了する際に考慮すべき最も重要な要素は何ですか？テストをやめる決定は主に依存していると思います テストの時間、予算、および範囲。

最も一般的なアプローチは、時間/予算が使い果たされたとき、またはすべてのテストシナリオが実行されたときに停止することです。ただし、このアプローチでは、テストの品質に妥協することになり、ソフトウェアについて十分な信頼を得ることができません。どうやって？

で見てみましょう例。

テストシナリオ：

ソフトウェアモジュールをテストしているとします。あなたはそれをカバーするために特定の予算を割り当てられました。プロジェクトのタイムラインは1か月です。合計テストシナリオは200です。このモジュールをテストしているのはあなただけです。

シナリオ＃1）

1週目： 1日目にショートッパー/重大度1の欠陥が見つかり、テスト全体が3日間ブロックされます。したがって、重大度1の欠陥が解決されるまで、どのシナリオも実行できません。 3日を失った後、ブロッカーは解決され、実行を続行します。

週の終わりに、20のシナリオを完了しますが、重要な高値はほとんどありません。 優先欠陥 。

2週目： ソフトウェアのテストを開始し、欠陥の発見に重点を置きます。 2週目に、さらにいくつかの重大度1、重大度2、および重大度3の欠陥を開き、週末には70のシナリオをカバーできます。

3週目： 3の始まりまでに^rd優先度の高いすべての欠陥が解決された週なので、保留中のシナリオの実行とともに、テス​​トバケットに到達したすべての欠陥を再テストする必要があります。順調な進歩を続けると、追加の欠陥がある120のシナリオをカバーします。

この時点で、すべての優先度の高い欠陥がすでに検出され、報告されています。これで、重大度3の欠陥しか見つかりませんでした。

4週目： 4週目までに、開いている欠陥のほとんどと残りの80のシナリオを再テストする必要があります。これにより、第4週の終わりまでに、すべての高および中優先度の欠陥を修正して再テストして、最大180のシナリオを完了することができます。

この情報を表形式で表示する：

ここでやめるべきですか？

Windows10を最適化するための最良のソフトウェア

あなたが疲れ果てた理由 時間を完全にテストする 優先度の高い欠陥のほとんどを報告して修正しました。この時点で停止すると、ソフトウェアに自信が持てますか？以下の理由によるものではありません。

• シナリオは完全には実行されません。
• 一度もテストされていないフローはほとんどありません。
• カバーされているすべてのシナリオは一度だけ実行されます。
• ソフトウェアにはまだ欠陥があります。
• 回帰はカバーされていません。

シナリオ＃2）

1週目： 1日目に重大度1の欠陥が見つかり、完全なテストは3日間ブロックされます。したがって、重大度1の欠陥が解決されるまで、どのシナリオも実行できません。 3日を失った後、ブロッカーは解決され、実行を続行します。

週の終わりに、さらにいくつかの欠陥がある20のシナリオを完了します。今週はシナリオ1と同じです。

2週目： 2週目に、さらにいくつかの重大度1、重大度2、および重大度3の欠陥を開きますが、焦点は、第1週からのバックログをカバーするために、より多くのシナリオをカバーすることです。週末には、120のシナリオをカバーできます。

3週目： 3の始まりまでに^rd未解決の欠陥がすべて解決された週なので、保留中のシナリオの実行とともに、テス​​トバケットに到達したすべての欠陥を再テストする必要があります。最後に順調に進んでいると、完了したシナリオの数は200になり、追加の欠陥があります。

これで、重大度2と重大度3の欠陥のみを報告できます。

この情報を表形式で表示する：

ここでやめるべきですか？

あなたが持っている すべてのテストシナリオを完全にカバーしました 一度、いくつかの大きな欠陥を開いています。この時点で停止すると、ソフトウェアに自信が持てますか？

以下の理由によるものではありません。

• すべてのシナリオは1回だけ実行されます。
• ソフトウェアにはまだ多くの大きな欠陥があります。
• 回帰はカバーされていません。

上記の両方のシナリオで品質が低下していることがわかります。最善のアプローチは、シナリオ1とシナリオ2のすべての要素がカバーされ、品質も損なわれないポイントを見つけることです。これを達成するには、テストの開始時に特定の基準を定義する必要があります。

これらの基準は、完了基準または終了基準と呼ばれます。 それは私たちの質問への答えです– 「いつテストを停止しますか？」。

完了または終了基準とは何ですか？

終了基準は、テストサイクルの最後に評価され、テスト計画で定義されます。これは、テストを完了するために満たす必要のある一連の条件またはアクティビティです。

終了基準は、十分なテストの量と、テストアクティビティの完了を宣言できる時期を定義します。 カバレッジ と完了基準を組み合わせて、テストの終了基準を定義します。

終了基準には何が含まれている必要がありますか？

理想的には、終了または停止基準はさまざまな要素を組み合わせて定義されるため、すべてのプロジェクトで一意です。これはプロジェクトの要件に依存するため、テスト計画中に定義する必要があります。プロジェクトの開始時に。その中で定義されているパラメータは、可能な限り定量化する必要があります。

以下は、機能テストまたはシステムテストの場合に終了基準を定義する際に考慮すべきいくつかの指針です。プロジェクトのニーズに応じてテストを停止する場所を決定する際に、以下の要素のいくつかまたはすべてを組み合わせることができます。

次の場合にテストを停止できます。

要件：

• 100％の要件カバレッジが達成されます。

欠陥：

• 定義済み/望ましい欠陥数に達しました。
• Show Stopperの欠陥またはブロッカーはすべて修正され、既知の重大/重大度1の欠陥はオープンステータスではありません。
• すべての優先度の高い欠陥が特定され、修正されます。
• 欠陥率が定義された許容可能な率を下回っています。
• 開いている中優先度の欠陥はほとんどなく、回避策があります。
• ソフトウェアの使用に影響を与えない、優先度の低い未解決の欠陥はほとんどありません。
• すべての優先度の高い欠陥が再テストされてクローズされ、対応する回帰シナリオが正常に実行されます。

テストカバレッジ：

• テストカバレッジは95％達成する必要があります。
• テストケースの合格率は95％である必要があります。これは式で計算できます
  • （合格したTCの総数/ TCの総数）* 100。
• 重要なテストケースはすべて合格です。
• 5％のテストケースは失敗する可能性がありますが、失敗したテストケースの優先度は低くなります。
• 完全な機能カバレッジが達成されます。
• すべての主要な機能/ビジネスフローは、さまざまな入力で正常に実行され、正常に機能しています。

締め切り：

• プロジェクトの締め切りまたはテスト終了の締め切りに達しました。

テストドキュメント：

• すべてのテストドキュメント/成果物（例– テスト概要レポート ）準備され、レビューされ、公開されます。

予算：

• 完全なテスト予算が使い果たされました。

「Go / NoGo」ミーティング：

• 「」 Go / No Go 「」 会議 利害関係者と実施され、プロジェクトを本番環境に移行するかどうかが決定されます。

結論：

最後にそれを非常に単純にしましょう。

簡単な「はい」または「いいえ」で質問に答えてください。

ほとんどの回答が「はい」の場合は、この時点でテストを停止できることを意味します。ほとんどの答えが「いいえ」の場合、それはテストから何が欠けているかをチェックする必要があることを意味し、これはエスケープする生産上の欠陥を見つけるのに役立つかもしれません:)

• すべてのテストケースは少なくとも1回実行されていますか？
• テストケースの合格率は定義どおりですか？
• 完全なテストカバレッジは達成されていますか？
• すべての機能/ビジネスフローは少なくとも1回実行されていますか？
• 決定された欠陥数に達しましたか？
• すべての主要な優先度の高い欠陥は修正され、クローズされていますか？
• すべての欠陥が再テストされ、クローズされましたか？
• すべての未解決の欠陥に対してリグレッションが実行されましたか？
• テスト予算を使い果たしましたか？
• テストの終了時間に達しましたか？
• すべてのテスト成果物がレビューおよび公開されていますか？

著者について： これはRenukaKによるゲスト記事です。彼女は11年以上のソフトウェアテストの経験があります。

この記事がお役に立てば幸いです。また、このトピックについてのあなたの考え/コメントを聞きたいです。

ハッピーテスト！

推奨読書

• 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
• ソフトウェアテストQAアシスタントジョブ
• ソフトウェアテストコースのシラバス–オンラインコースの詳細なトレーニングプラン
• ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
• キャリアとしてのソフトウェアテストの選択
• ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
• いくつかの興味深いソフトウェアテストのインタビューの質問
• ソフトウェアテストコースのフィードバックとレビュー