回答。

回帰手動テストは、コードに変更を加えた後に、システムの既にテストされた機能を再確認するプロセスであり、これらの変更が製品の安定した部分に新しい欠陥を引き起こさなかったことを確認するためのものです。

問題の歴史： ソフトウェアライフサイクルの初めでは、テスト担当者は通常、新機能の確認に集中します。時間が経つにつれて、システムには変更が加えられ、想定外の回帰リスクが高まります。多くのソフトウェアのエラーは、以前に機能していたものを「壊す」修正の後に発生したため、回帰テストは次第に必須の実践となりました。

問題点： 主なジレンマは、頻繁な変更がある中で、できるだけ多くの機能を効率的かつ短期間で再確認するにはどうすればよいかということです。無秩序または一貫性のないアプローチで取り組むと、重要な欠陥を見逃す恐れがあり、期限に間に合わなかったり、チームが過労になったり、時にはチェックが形式的になることもあります。

解決策： 効果的な回帰テストを組織するためには：

重要な機能に対する安定した保守可能なテストケースやチェックリストのセットを持つこと；
これらのセットを機能強化の際に定期的に更新すること；
可能であればルーチンを自動化し、手動テストでは重要または非標準的なシナリオを選ぶこと；
ビジネスリスクと変更頻度に基づいて、確認する機能の優先順位を調整すること。

主な特徴：

回帰は、明らかなバグだけでなく、モジュールの相互作用に関連する隠れたエラーの連鎖も明らかにします。
テストケースのセットを定期的に見直し、優先順位を付けることが重要です。
最適な戦略は、可能な限り手動チェックと自動化を組み合わせることです。

トリッキーな質問。

回帰テストは、すべての変更が完了した後に開始するのが最適か、それとも変更の導入と並行して行うべきか?

多くの人は、回帰テストはすべての変更が完了した後に行うものだと誤解しています。実際には、変更を行うごとに部分的に計画し実施する方が、重大な障害に迅速に対応できます。

回帰テストケースを一度作成して、それ以降は更新しなくても十分か?

いいえ、回帰テストケースは常に最新の状態に保つ必要があります。ビジネスロジックやインターフェイスが変更された場合、テストシステムは製品に合わせて変わらなければなりません。

スモークテストは回帰テストの一部か?

いいえ、スモークテストはビルド後の明らかな障害を迅速に確認するものであり、回帰テストはより広範な機能をカバーし、「深く」問題を探ります。

一般的な間違いとアンチパターン

不適切なテストケース — これによりテストが形式的なものとなり、無意味になります。
重要だが目立たないシナリオを無視すること。
明確な優先順位の欠如 — 重要な機能と重要でない機能に均等な注意を払う。

実生活の例

ネガティブケース

チームがリリースを行い、テスト担当者が古いテストケースのリストに基づいて形式的に機能を確認しますが、最新のAPIの強化については知らない。古いバグが修正されるが、システムの別の部分で重大な欠陥が発生し、誰もリリースまで気づかなかった。

利点：

テストケースの作成にかかる時間の節約。

欠点：

重要な回帰を見逃すリスクが高い。
テストの品質への信頼が低下します。

ポジティブケース

リリース前にテスト担当者が回帰チェックリストを更新し、アナリストとリスクのあるエリアを議論し、実際のシナリオに基づいてテストの優先順位を付け、重要なフローに対して手動の回帰テストを実施しました。