自動テストの失敗分析・隔離・復帰運用シート

再実行で成功しても、最初に失敗した理由は消えません。実行順序やデータが変わった可能性も、最初の実行が残した状態で結果が変わった可能性もあります。最初の失敗と再実行を同じ事象番号でつなぎ、製品とテストのリビジョン、環境、事前データ、期待結果を記録します。製品の版が同じでも、別のアカウントや初期化したデータを使ったなら、その違いが調査の根拠になります。

実行結果、調査の進行状態、資産の使用状態は分けます。PASS・FAIL・BLOCKED・NOT RUNはシナリオの実行記録に使い、受付・調査・対応・レビューは失敗事象の進行を表します。隔離は、その自動テストをどの実行から外したかという別の判断です。ツール固有の状態名も定義に沿って読みます。Playwrightの再試行文書は、初回で成功したテストと再試行後に成功したテストを区別しています。その状態を製品欠陥数やリリース判定に直接置き換えません。

分類では、合意した要求、テストの期待値、製品の実際の動作を先に比べます。要求が正しく製品の動作が違うなら製品欠陥を調査します。製品は要求どおりでも期待値、ロケーター、観察のタイミングが誤っていればテストの修正が必要です。共有データが上書きされた場合や環境が異なる場合は、その条件を制御して確認し直します。ログの最後がタイムアウトというだけで環境の問題と確定しません。

調査シートには事象番号と仮説、確認または除外した根拠、次の調査、担当と確認日を残します。製品、テスト、データを同時に変えると、何が原因を解消したのか分かりにくくなります。可能な範囲で条件を分けて変え、前後の結果をつなぎます。根拠が足りなければ未確定のまま扱います。準備条件の点検にはPlaywrightのテスト独立性とデータ制御の指針を参考にできます。

完成例は、IXCがこの資料の作成用に実行したローカルのNode.js合成試験です。小さな関数と制御したデータ操作順序に、既知の原因を意図的に組み込んで結果を比較しました。顧客のソフトウェア、ブラウザー、運用CIの試験ではなく、実際の失敗頻度を測定した結果でもありません。

F-PRODUCTでは、閲覧者に編集を許可する製品ロジックが原因でした。同じ入力と期待値で再度失敗を確認し、製品の役割条件を修正しました。F-DATAでは準備処理AとBが同じ文書キーを使い、BがAの所有者を上書きしました。初期化したデータでの再試行は成功しましたが、Aの書き込み・Bの書き込み・Aの読み取りを繰り返すと再び失敗しました。実行別のキーに分けてから同じ順序を確認しました。これは制御した順序の例で、実際の並列スケジューラーの検証ではありません。

F-TESTでは、有効なレコードだけを数える要求に対し、テストが全レコード数を期待していました。有効二件、無効一件のデータと要求を照合し、製品は変更せず期待値だけを修正しました。各事象は修正後に三回の成功を確認しました。この回数はローカル例の観察記録であり、すべての自動テストに適用する安定性基準ではありません。実務では修正したコードやデータ準備規則、期待値を変更した理由まで記録します。

隔離するテストと事象番号、外す実行段階、理由、リリースへの影響、次の確認日を記録します。一時的に手動で検証するなら、誰がどのデータを使っていつ実行するかを決めます。別の層のテストで代替するなら、元のシナリオのどこまで確認するかを残します。代替手段がなければ未検証範囲としてリリース担当に伝えます。隔離したテストを、実行していない検証の成功として数えません。

共有データの衝突を調べている間に、独立したデータで主要動作を確認することはできます。ただし、それで並列実行全体が安定したとは言えません。代替確認の実行番号と残った条件を記録します。隔離件数だけを減らす目標はテストの削除でも達成できるため、経過期間、代替検証の有無、未解決リスクを併せて見ます。自動化から外すと決めた場合も、その検証を人が引き続き担うかを決める必要があります。

復帰記録には原因の根拠、修正番号、再検証条件、結果、残る限界、レビュー担当をつなぎます。製品を直したならテストが同じかを、テストを直したなら要求の検証を弱めていないかを確認します。期待値を実際の結果に合わせるだけでは、信号を消して成功表示だけを残すことがあります。F-TESTの修正が妥当なのは結果が二件だったからではなく、合意した要求が有効件数を数えるものだったからです。

必要な繰り返し回数と環境は、製品リスクとデータや実行の変動を見て合意します。元の失敗を起こした順序や条件を外して回数だけ満たしても、復帰の根拠は足りません。復帰後に同じ症状が出た際の担当と記録先も引き継ぎます。自動テストの復帰とリリース承認は別に扱い、会議にはそのビルドで実際に行った結果と未検証の領域を渡します。

定期レビューでは、初回失敗、再実行、原因調査時間、スクリプト修正時間、環境やデータの準備時間を分けます。同じ観察期間で比較して初めて実行量と保守作業の変化を読めます。再試行後の成功率が上がっただけで、製品品質の改善や費用削減と断定しません。どの検証を自動化に残すかはテスト自動化ポートフォリオで扱い、リリース判断には判定メモ・シナリオ結果表をつなぎます。

提供するPDFと編集用Excelは日本語版です。基本記録、原因調査、隔離と代替検証、復帰レビュー、保守作業を同じ事象番号で結びます。代表的な実行ログ、環境とデータの準備方法、現在の保守担当を整理すると、IXCのテスト自動化サービスで調査、修正、引き継ぎの範囲を具体的に相談できます。