それに対する簡単な答えはテストを行うことだと理解していますが、それでもこのテストをどのように行うのですか? テスト ケースを変更して、実行する追加のテスト ケースとしてバグを含めるか、古いリリースから最新のリリースまで、バグ追跡システムですべてのバグを検証するだけですか。
答えてくれてありがとう。私の質問が明確ではなかったようです。バグレポートを書き、バグを修正し、修正検証のためのテストを行う必要があることを理解しています。ただし、次のバージョンのリリース時にテストを再実行して、新しい変更によってバグが再導入されていないことを確認するには、このテストをどのテスト フェーズで実行する必要がありますか。回帰テストを行うべきか、特定のプロジェクトの統合テストを行うべきか、それともバージョン 1.0 以降のバグ追跡システムのすべてのバグをテストするべきか?
問題を再現する自動テストを作成します。次に、問題を修正し、新しいテストと既存のすべてのテストが引き続きパスすることを確認します。
これは回帰テストであり、可能な限り自動化する必要があります。
バグを見つけた場合、最初に行う必要があるのは、バグを示す単体テストを作成することです。テストに合格するので、いつ修正したかがわかります。そのテストは突然失敗するため、後退から保護されます。
システムの「バグ」は、機能の一部の単位が機能していないことです。機能の単位をカバーする単体テストを作成することにより、その作業単位でバグが再発するかどうかを知ることができます。これで、同様の状況で失敗する可能性のある他の機能領域をテストする追加の単体テストを作成すると、より多くのカバレッジが得られます。
とはいえ、単体テストは答えの一部にすぎません。このバグのテストケースも追加すると、バグの発生を防ぐのに役立ちますが、残念ながら、開発ライフサイクルの後半になり、修正に費用がかかります。
QA として、いくつかの修正の結果として影響を受ける領域を予測する必要があります。同じことについてアプリケーションを徹底的にテストしますが、フリーズするたびにビルド全体をリグレッションすることを強くお勧めします。
それが長期プロジェクトであり、手元に時間がある場合は、テストを自動化することをお勧めしますが、プロジェクトが短期間でアジャイル モデルで開発され、要件が変化する場合は、手動でテストして、可能な限りカバーします。
どの観点から質問するかによって、さまざまな方法で問題に取り組むことができます。開発者の観点からは、1.0 (またはそれ以前) 以降のすべてのバグを適切な単体テストでチェックし、CI でも実行できるようにすることが最善である可能性があります。それが面倒になったら、すべてのビルドで実行される重要なテストをグループ化してみてください。
QA/テストの観点からは、もう少し努力が必要です。
回帰テスト、テストの自動化には注意が必要であり、バージョン 1.0 からのすべてのバグをチェックする必要があることに注意してください。バージョン 1.0 からアプリケーションが大幅に変更されたため、一部のバグが不要になったのではないでしょうか? 古いバグに基づいてリグレッション テストを作成する場合は、このことを考慮する必要があります。