テストを停止する時期を知る方法

これは非常に基本的な質問です。一部のソフトウェアアプリケーションには、アプリケーションのテストケースがほぼ無限に多数あります。これらすべてのテストケースをテストすることは実用的ではありません。テストをいつ停止するかをどのように決定しますか？（「お金がなくなったとき」を除く）。

Glenford Myersの著書The Art of Software Testingには、このためのシンプルだがきちんとした原則があります。バグの発見を止めたらテストは完了します。または、より現実的には、新しいバグを見つける率が大幅に低下する場合。

バグは、特定のモジュールおよび特定の機能で「クラスター化」する傾向があります。バグを見つけた瞬間、さらにバグを探す必要があることがわかります。バグを見つけるには、ブラックボックステスト、ホワイトボックステスト、突然変異テストの手法を使用できます。バグを見つけている限り、テストプロセスが機能していることがわかります。

進捗を視覚化するには、チームが1日あたりに発見したバグの数をグラフ化します。グラフが下に傾斜している場合、チームが使用している手法がとにかくそれらを見つけられないことがわかります。もちろん、テクニックが標準に達していないと思われる場合は、マイヤーズの本を読んで原則を適用してください。

現在、バグの新しいパッチが不足している可能性があり、さらにテストを続ければ、バグの発見率が大幅に向上します。ただし、テクニックが適切であると信じている場合、これはほとんどありません。

簡単な答えは、システムによって異なります。心臓モニター用の組み込みソフトウェアまたは原子炉用の安全性監視ツールを作成している場合、標準はブログプラットフォームを作成している場合よりもはるかに高くなります。

これは本当に優れたシステムテスターに​​とっての質問です（私はそうではありません）が、試してみましょう。

基本的な尺度は、テストカバレッジです。実際にテストされたアプリケーションの量（単体テストと機能の両方）。

使用される可能性のある各ユースケース（およびそのユースケースのパラメーター）を、実際に使用される可能性（したがって、エッジケースを削除する可能性）、複雑さ（バグを含む可能性が低い単純なもの、またはハードを含む可能性が低いもの）を評価する必要があります（バグを見つけるため）、テストのコスト（時間的に）、およびその領域で発見された場合の欠陥の潜在的な影響（これは原子炉対ブログプラットフォームの出番です）。

その評価に基づいて、どれをテストするのか、どの程度詳細にテストするのかを決める必要があります。そのようなリストを作成したら、チーム（製品マネージャー/プロジェクトマネージャー/ユーザーの代表者を含む）がそのリストを調べて、制約に基づいて優先順位を付けることができます。

考えておくと便利なテクニックの1つは、各リリースでテストされるユースケースも変更できることです。たとえば、重要ではないテストケースのリストを作成し、それらの半分を1つのリリースでテストし、半分を次のリリースでテストします（その後、代替）。このようにして、努力のために得られる総テスト範囲を増やしています（ただし、回帰バグが導入されるリスクがあります）。

これは、プラットフォームテストにも拡張できます。2つのデータベースバックエンド（または複数のブラウザー）をサポートする場合、一方のアプリの半分をテストし、他方のアプリを半分テストしてから、次のリリースを交換します。

（これはストライピングと呼ばれていると思いますが、そのことを引用しないでください。）

そして最後に考えるべきことは、テストするものではなく、問題が発見されたときに実際に修正するものです。「すべてのバグを修正する」と言うのが一般的ですが、現実には時間的なプレッシャーがあり、すべてのバグが同じというわけではありません。繰り返しますが、関連するすべての関係者との定期的なバグスクラブが最善の方法です。これは、バグ修正が特に侵入的である可能性がある場合に特に関係します。再テストおよび回帰テストで生成される追加作業が修正の利点を上回る場合があるためです。

ソフトウェアの使用に関連するリスクが許容レベルまで低下したとき。

「プログラムのテストはバグの存在を示すために使用できますが、バグがないことを示すことはできません！」-エズガー・ダイクストラ

テストを自動化するかどうかにかかわらず、テストを行う際に留意すべきこと。これ以上バグが見つからなかったことを証明することはできますが、それ以上ないことは証明できません。

しかし、コードのセクションに目を向けるほど、その適切な操作に自信を持つことができます。その点での最適化に関するクヌースの引用とよく似ています。間違ったものを非常に簡単にテストでき、開発中に間違ったタイミングでテストできます。

本質的に、あなたは2つの大きな場所でカバーされることを望みます：

1. ソフトウェアは、指定された要件を満たしていることを示すBDDテストに合格していますか。これが正しくない場合、ソフトウェアを完了と呼ぶことさえできません。

2. 最も重要で複雑で不確実なセグメントには、信頼性を提供するのに十分なテストがありますか？コアループである場合、または最適化またはハッキングが必要な場合：テストを行います。複雑で論理的な分割が多い場合：多くのテストを行います。単体テストができない場合、または実際に直接テストするにはあまりに深く埋め込まれている場合は、コードを確認し、コードを手作業で間接的にテストしてください。

プロジェクトが終了するまで待つと、実際には非常に多くのテストケースがあります。小規模な配信に焦点を合わせて継続的に配信する場合、各反復でのテストケースが少なくなり、すべてをテストできるようになります。少量の配達ができない場合は、優先順位を付けて最も優先度の高いものからテストを開始し、停止するまでテストを続けます。

ユニットテストについて話している場合、TDDを実行している（最初にテストを作成する）場合、これは問題ではありません。機能が完了したらテストを停止するだけです。

インクリメンタルTDDでは、失敗するテストを作成し、それを通過させることができる最小限のコードを実装してから、リファクタリングします。メソッドが機能が完了するまで、この方法でテストを追加し続けます。

これは素晴らしい例です。

統計学者もこの問題に注目しています-実際には早くも1970-80年代に。バグの発見方法に関する適切な仮定が与えられれば、彼らはテストのデータからバグの数を推定しようとします。次に、これを使用して、損失関数の最適化に基づいて停止するタイミングを決定します。例えば、https：//rpubs.com/hoehle/17920 ...を参照してください。実際にこれを行う方法に関するRコードを含む、この問題に関する論文の1つを簡単に扱ってください。

もちろん、1つの問題は常にバグ発見プロセスに関する仮定です。たとえば、上記の処理では、バグは互いに独立して検出されると想定されています。実際には、1つの大きなバグを修正すると、たとえば、新しいバグが発生する可能性があります。しかし、それは開始を与え、直感を補います。

出荷日が到着したとき。ソフトウェアのテストに終わりはありません。しかし、それでもスケジュールと呼ばれるものがあります。スケジュールされた時間内にほとんどの機能をテストし、発生したバグを修正する必要があります。ソフトウェアが完璧であることを保証する方法はありません。

最初にテストするのは、「ハッピーパス」、エッジケース、および無効な入力です。複数の同時ユーザーが存在する場合は、ロックや競合状態などの同時実行の問題をテストする必要があります。アプリが外部リソースを使用する場合、それらのリソースが利用できない場合のアプリの動作をテストする必要があります。その後、コードを使用して、コードを壊し、それらをテストする可能性のあるものを探すことができます。これらのすべてのテストに合格すると、さらにテストを行うことで得られる費用対効果の比率が上がり始めるため、その時点で停止するのが妥当です。

それはすべて、信頼の問題に帰着します。システムが十分にテストされていると確信していますか？

明らかに、「自信レベル」は非常に主観的です。完全に確信することはできませんが、十分に確信できるからです。それが私たちが求めていることです。そのためには、一般的に完了の定義として知られているインジケーターのリストを作成する必要があり、チーム全体が同意するものでなければなりません。

「完了インジケータ」に関連するいくつかのテストを次に示します。

• ビルドとインストールは完全に自動化され、すべてのテスト（ユニット、GUI、統合）は自動的に実行されますか？
• テストを書いたのは、コードを書いている間ではなく（できれば前に）ですか？
• バグを発生させずに大規模なコードのリファクタリングを行うのに十分安全だと感じていますか？
• コードカバレッジレベルは十分ですか？
• チームに専用のテスターがいますか？彼だけでなく、開発全体を通じて日々関与していますか？
• テスターは手動で（探索的）成功せずに破壊しようとしましたか？

これらの点を確認できれば、おそらく十分にテストしたと言えるでしょう。

決して、システムでテストを終了することは決してないと思います。管理できない変数がたくさんあります。

しかし、私たちが知っているように、「永遠に」テストすることはできないので、制限は基本的に次のことに依存すると思います。

• ソフトウェアの使用に関連するリスクが許容レベルまで低下したとき。（@Graham Leeが言うように）
• システムユーザーは誰ですか？それはあなたまたは米国の大統領になります。最初のケースでは、バグが表示されても、それを解決して完了したため、あまり気にしません。2番目のケースでは、バグを表示したくありません。
• クライアントとの関係は？クライアントはあなたのお父さんかもしれないので、それほどひどくはありません。あるいは、大企業かもしれません。
• システムユーザーにとってバグはどれほど深刻ですか？それは第三次世界大戦を引き起こすのでしょうか、それともjustいメッセージでしょうか？

デプロイにサインオフする必要がある人々が満足したとき。

または場合によっては、責任者の大半が満足しています。