回帰テスト、テストのメンテナンス、脆弱なテストへの対処 — ソフトウェアテストとQAにおける人工知能

利益:

回帰テストの目的を理解し、人工知能による変化に応じてテストの選択と回帰ケースの生成ができる
脆弱なテストの根本原因 (タイミング、順序依存関係、共有状態、外部依存関係) を診断し、症状を抑えることなく永続的な解決策を適用する能力
重複したテストを排除することで回帰スイートの高速性、独立性、信頼性を維持しながら、完全なパッケージのプレリリース実行の規律を維持する機能

ソフトウェアは常に変化します。すべての新機能や修正は、以前は機能していた機能を壊す可能性があります。以前に機能していた機能がその後中断されることを回帰といいます。回帰テストでは、変更が加えられるたびに既存の機能を再テストして、こうした機能低下を検出します。時間の経過とともに、これらのテストスイートは大きくなり、何千ものテストが発生し、2 つの大きな問題が発生します。スイートの速度が低下することと、不安定なテスト (同じコードで合格することもあれば失敗することもある信頼性の低いテスト) により、テスト結果に対するチームの信頼が失われます。人工知能 (AI) は、回帰スイートを適切に維持し、高速かつ信頼性の高い状態に保つための強力な助けとなります。しかし、重要な注意点は依然として残っています。AI は脆弱なテストを「パスさせる」と提案するかもしれませんが、多くの場合、実際のバグを隠すパッチを作成する可能性があります。あなたの仕事は、症状を抑えることではなく、不安定性の根本原因を見つけることです。

脆弱なテストの根本原因

脆弱なテストは最も潜行的なテストの問題です。テストが合格するか失敗するかの信頼性が低く、チームは「また行き詰まったに違いない、もう一度実行する」という習慣に陥ります。そしてこの習慣は、いつか本物のバグを「不安定」として無視することになります。主な根本原因:

タイミング/競合状態: テストは、操作の終了を待たずに結果をチェックします。最も一般的な理由。
順序依存性: テストは相互に残されたデータに依存します。順番が変わると壊れます。
共有ケース: 複数のテストが同じテストデータ/ユーザーを使用し、競合しています。
外部依存関係: 実際のネットワーク、サードパーティのサービス、システム時間、ランダム値。
環境の違い: ローカルに切り替え、CI (継続的統合環境) に残ります。

注意: 「数回再試行」して脆弱なテストに合格すると、多くの場合、実際の同時実行エラーが隠蔽されます。再試行は診断ツールであり、治療ではありません。まず根本原因を見つけてください。再試行は、文書化された真の外部の不安定性に対する最後の手段としてのみ使用してください。

テストのメンテナンス: パッケージを健全に保つ

回帰スイートは庭園のようなものです。手入れをしないと雑草が生えてきます。 AI は次の 3 つのメンテナンスタスクを支援します。

1. 重複/不必要なテストクリーニング。時間が経つにつれて、同じことをテストする多数のケースが蓄積されます。 AI は、類似したテストをグループ化して結合することを提案します。

2. 脆弱性テスト診断。 AIにテストコードと不安定パターンを与えます。考えられる根本原因と恒久的な解決策を提案します。

3. テストの選択/優先順位付け。変更のたびにパッケージ全体を実行するとコストがかかります。テストの影響分析 (変更されたコードに基づいて関連するテストのみを選択) により、AI はどのテストを最初に実行するかを推奨します。ただし、完全なプレリリースパッケージは必須です。

隔離: 脆弱なテストを適切に管理する

テストが脆弱であることが判明しましたが、根本原因をすぐに修正する時間がありません。何をするか？間違った方法は 2 つあります。テストを完全に削除する (その動作はまったく保持されなくなります)、または再試行してテストを沈黙させる (本当のバグを隠す) ことです。正しい方法は、隔離することです (脆弱なテストをメインパッケージから一時的に分離し、別のリストで追跡します)。隔離されたテストはバージョンのマージを妨げませんが、目に見える負債として残り、定期的に対処されます。重要な点は、隔離は待合室であってゴミ箱ではないということです。隔離リストが増加している場合、これはチームのテストの状態が悪化しているという警告です。 AI は定期的に隔離リストを確認し、根本原因のパターンごとにグループ化します。「6 つのテストすべてが同じ共有テストユーザーに接続されている」など、共通の原因を明らかにすることで、集合的な解決策を可能にします。

ヒント: 各隔離レコードに「所有者」と「最終レビュー日」を追加します。遺棄された検疫所は恒久的なゴミ捨て場となる。誰も気にしないので、脆弱なテストは永遠にそこに残ります。

回帰戦略テーブル

ステータス

戦略

AIの役割

軽微な修正

患部+煙テスト

弱いプロンプト / 強いプロンプト

弱者: 「このテストは時々失敗するので、修正してください。」

Strong: 「このテストは 10 回中 3 回失敗し、コードは変更されていません。不安定性の根本原因を診断します。タイミング/競合、順序依存関係、共有状態、外部依存関係、または環境の違いである可能性があります。テスト内のどの行が考えられるそれぞれの原因を示しているかを示します。永続的な解決策を提案します。「再試行の追加」などの症状を抑制する解決策は提案しないでください。やむを得ない場合は、理由を明確に書きます。テスト: [コード]。エラー追跡: [ログ]。

強力なプロンプト。診断を根本原因に導き、症状の抑制を明示的に禁止します。

コピー可能な 4 つのテンプレート

1) 脆弱性テストの診断:

このテストコードは、変更せずに合格する場合もあれば、失敗する場合もあります。根本原因の候補 (人種、順序依存性、共有状態、外部依存性、クロック/ランダム、環境の違い) をリストし、それぞれのテストで一連の証拠を示します。恒久的な解決策を提案します。再試行などの抑制的な解決策を最後の手段として、正当な理由を付けてマークします。テスト: [コード] / 不安定パターン: [何回の実行で何回]

2) 回帰ケースの提案:

次の変更が加えられました: [変更/PR 概要]。この変更により壊れる現在の動作をリストし、それぞれの回帰テストケースを提案します。特に副作用と共有依存関係の領域を強調表示します。

3) 重複したテストのクリーンアップ:

以下のテストスイートをチェックしてください。同じ動作をテストする重複または重複するケースをグループ化します。グループごとにどれを保持し、どれを組み合わせるべきかを提案します。補償が失われるリスクがある場合は警告します。テスト: [リスト/コード]

4) テスト効果の選択:

次のファイル/関数が変更されました: [リスト]。既存のテストスイートから、最初に実行する必要があるテスト (変更されたコードに直接/間接的にリンクされているテスト) を選択して正当化します。注: 今後も完全なプレリリーススイートを実行する予定であることを思い出してください。

ミニケース3個

ケース 1 — 本当の間違いは再試行によって隠蔽されます。あるチームは、時折行われる残りの支払いテストに 3 回の再試行を追加しました。今ではテストは常に「合格」していました。「脆弱性テスト診断」を適用すると、不安定性は実際の競合状態に起因することがわかりました。高負荷では、支払い確認が二重処理される場合がありました。 Retry は何ヶ月にもわたって、実際にライブでお金が失われる可能性があるバグを隠蔽しました。根本原因が修正され、再試行が削除されました。

ケース 2 — パッケージが縮小し、速度が向上しました。 1,400 件のテストからなる回帰スイートには 55 分かかりました。「重複テストのクリーニング」では、380 件のテストが重複またはカバーされていることが判明しました。合併した。パッケージはテスト数 900 件に減り、時間は 34 分に短縮されましたが、カバレッジは目に見えて減少しませんでした。フィードバックが迅速化されたことで、チームはより頻繁にテストするようになりました。

ケース 3 — 順序依存性。テストはローカルでは常に合格しますが、CI ではランダムに失敗します。 AI 診断では、テストが別のテストで作成されたユーザーに依存していることが示され、CI ではテストが並列/異なる順序で実行されたために機能しませんでした。各テストは独自のデータを確立するために行われました。優柔不断はもう終わりです。

よくある間違い

脆弱なテストを再試行して沈黙させます。根本原因を探らずに再試行する。本当の間違いを隠蔽する。
「また行き詰まった」文化。赤の結果を定期的に無視する。ある日、本当の間違いを飛ばしてしまいました。
パッケージをまったく削除しません。重複したテストが蓄積し、パッケージの速度が低下する可能性があります。
テスト間の依存関係。テストは一般的な条件/シーケンスに基づいています。不確実性の源。
変更された部分のみをテストし、パッケージ全体をスキップします。プレリリースのショートカット。隠れた副作用が逃げ出す。
外部依存に依存している。実際のネットワーク/クロック/ランダム値に基づいてテスト。もともと不安定。

要約すれば

回帰テストは、以前に動作していた機能を破壊する変更を検出します。しかし、パッケージが大きくなるにつれて、テストの遅さと脆弱さが信頼を損ないます。脆弱なテストの根本原因は通常、タイミング、順序依存関係、共有状態、外部依存関係です。 AI は、診断、クリーニング、テストの選択を強力に支援します。しかし、再試行によって優柔不断を抑制すると、本当の間違いが隠蔽されます。根本原因を見つけ、テストを独立かつ決定論的にし、定期的にパッケージを整理し、リリース前に完全なパッケージを実行します。

アプリケーションタスク

脆弱であることがわかっている (または不安定に見える) 独自のプロジェクトからテストを選択します。「脆弱性テスト診断」テンプレートを使用して、根本原因の候補を抽出し、テストの証拠を検証します。根本原因を特定し、再試行せずに永続的な解決策を実装します。次に、パッケージから 10 個のテストを選択し、「重複テストのクリーンアップ」と組み合わせることができるテストを見つけます。根本原因から解決したテストの不安定性の数と、スイートから削除した不必要なケースの数を報告します。

チェックリスト

[ ] 脆弱なテストの根本原因を診断しました。症状を抑えられなかった。
[ ] 私は再試行を治療法ではなく、正当な最後の手段として考えました。
[ ] テストを独立かつ決定論的に (外部依存関係から分離して) 作成しました。
[ ] 回帰スイートから重複/不必要なテストを削除しました。
[ ] 変更に基づいてテストすることを選択しましたが、完全なパッケージのプレリリースを実行しました。
[ ] 私は、「また詰まったらパス」という文化に対抗して、すべての赤を真剣に受け止めました。