課題と判断基準

エラーを修正してデプロイし、監視も静かになりました。しかし数週間後、似た問い合わせが届きます。以前の課題にはスタックトレースと修正PRしかありません。どの条件で利用者が失敗し、次の変更で何を再確認すべきか探せません。

本番エラーを回帰テストにするには、記録から再現条件を抽出し、期待動作を定め、修正前には期待を違反し修正後には満たすか確認します。 次の変更の検証に入るよう担当者と実行条件を定め、デプロイ後の実利用者への影響まで確認して接続が完成します。

本記事が提案する流れは次です。

利用者影響 → リリース・環境確認 → 最小再現条件 → 期待動作 → 修正 → 回帰検証 → デプロイ後確認

全ログをテストに移す必要はありません。繰り返し得る失敗を次の変更で発見することが目的です。以下の記録モデルと例は設計案で、製品の自動化機能や実顧客の試験結果ではありません。

エラー発見と原因解明を分ける

Sentryは類似イベントをfingerprintで課題にまとめます。既定分類にはスタックトレース、例外型、メッセージなどを使います。課題は調査対象を整理する単位として有用ですが、分類結果を確定原因や一テストケースと直結させてはいけません。前半は製品動作、後半は調査上の判断境界です。1 2

保存APIの401と画面例外が観測されたとします。確定事実は認証失敗応答と画面例外です。セッション満了、認証設定誤り、失敗応答を成功扱いしたかは別確認が必要です。401だけで満了と確定すると、別の失敗も同じ修正で覆う可能性があります。

記録では三状態を区別します。

状態現在言えること次に必要なもの
観測済みある利用者操作で特定結果を観測した対象版・環境、証拠、影響範囲
再現・説明済み制御条件で同じ失敗が発生し原因仮説を検討した代替仮説、除ける条件、期待動作
回帰資産として検証済み同じ期待条件で修正前後の差を確認した反復実行条件、担当、デプロイ後確認

原因解明前に利用者視点の失敗をテスト化しても構いません。その場合は「症状再現済み、原因調査中」と記録します。テストの存在は原因分析完了を意味しません。

サービスの仕組み

実行結果の信頼を保つ保守 — 変更に強い識別子で実行し、失敗原因を分類・修正して結果を再検証します。

ログをコピーする前に、どの版のどの失敗かを固定する

最初に書くのは利用者が完了できなかった作業です。「TypeError」より「文書保存が完了せず入力も消えた」の方が検証につながります。入力消失、誤成功案内、重複処理は別の影響として分けます。

発生時刻・タイムゾーン、サービス・リリース識別子、本番か検証環境か、設定・機能フラグを結びます。Sentryのreleaseは環境に配備したコード版で、JavaScript SDKにはreleaseとenvironment設定があります。イベント実値とデプロイ記録を照合し、名前だけで本番と推測しません。3 4

フロントエンドとAPIが別配備なら版も分けます。再現に影響するブラウザー・ランタイム・設定は実値を残し、無条件に全情報は集めません。特定役割だけの失敗なら役割・権限が重要です。全ブラウザーで同じ応答処理エラーなら細かな端末情報は最小再現から除く候補です。

OpenTelemetryのコンテキスト伝播はTrace ID・Span IDなどでサービス間の要求と観測信号を結ぶ基盤です。ログとトレースは計測・伝播が正しく構成されて初めて結べます。この関連は調査を絞る証拠で、特定コードが原因という結論の代わりにはなりません。5

本番証拠はアクセス制限された元の保管場所を参照し、テストリポジトリにはそこから得た条件を残します。期限前に共有可能な技術事実を要約し、誰がいつ何を確認したか記録します。認証情報を含む原文保存を求めるものではありません。

顧客データを持ち込まず失敗条件を保存する

fixtureは実行前に準備するデータと状態です。本番から持ち込むべきものは顧客名や実文書ではなく、失敗を起こした構造と条件です。

合成データを作り、影響した属性を残します。空値、文字列長、文字コード、欠落とnullの違い、レコード関係、役割・所有権、満了前後の状態などです。数字を適当に置換したり関係を切ると、個人情報を除けても再現条件を失います。

SentryはSDK送信前の除去と、サーバー側で保存しない処理を分けて案内しています。収集済みでもテストリポジトリへコピーできるとは限りません。イベントだけでなくトレース・ログ・添付の経路も確認し、一設定が全経路を保護すると仮定しません。6

メールの一部マスクや識別子置換だけで再識別不能とは断定しません。公開・共有例は初めから合成し、実行アカウントと秘密情報はリポジトリ外で管理します。OpenTelemetryのbaggageはサービス境界を越えるため認証・個人情報を入れないよう注意します。5

Playwright Testの既定page・contextはテスト別に隔離されますが、共有DBまで初期化しません。専用データ領域と実行後整理は別設計です。worker共有fixtureとテスト単位資源も区別します。7 8

待ち時間を延ばさず失敗条件を制御する

再現できたら偶然を減らします。「遅いネットワークで時々失敗」を「この応答がこの処理順序で返ると失敗」へ変えます。次はその設計基準です。

変動条件テストで制御するもの合格だけでは証明しないこと
ネットワーク応答状態・本文、接続失敗、必要な応答順序実外部サーバーの正常動作・可用性
時間基準時刻・時差、満了境界、タイマー進行ブラウザー外のAPI・DB時刻も変化したこと
外部依存文書化された契約に合うmock、許可済み検証環境事業者の実障害が解消したこと
権限・データ合成アカウントの役割・所有権、事前データ、機能フラグ他役割・他データ状態でも安全なこと
非同期処理要求発生、応答処理、完了状態など明示条件一定時間経過だけによる完了判断

PlaywrightのネットワークmockでHTTP応答を制御できます。ただしサーバーが返し得ない応答を都合よく作ると実連携から離れます。状態と構造を現契約に合わせ、確認対象はその条件への自社コードの反応だと明確にします。9

時間も区別します。page.clock.setFixedTime()はDate.now()とnew Date()の時刻を固定します。タイマーを進めるにはinstall()などのClock機能を検討します。ブラウザー側制御なので、サーバー判定のセッション満了には別のテスト時計やセッション状態が必要です。10

画面では「3秒後確認」より条件を待つassertionを使います。Playwrightの非同期assertionは成立かタイムアウトまで再確認します。ただしエラー表示だけで全処理完了とせず、画面の完了状態を定義してから入力保存と成功表示の不在を確認します。機能テストの待機限度はサービス性能目標とも別です。11

設計例：セッション満了後の保存で入力が消える

以下は架空の文書作成サービスです。IXCの実顧客事例でも、記載テストを実行した結果でもありません。版・識別子・データ・担当は説明用です。

ログイン中に文書を書いている間にセッションが満了したとします。保存は401で拒否されたのに画面が入力を消し、応答から文書識別子を読んで例外を起こします。守る要求は「必ず保存成功」ではなく、認証失敗の要求を保存せず、失敗案内と承認範囲内の入力保持を行うことです。

次はログ転記書式ではなく、本番課題からテストに渡す内容を埋めた例です。

記録項目記入内容：設計例
関連識別子本番課題OBS-DEMO-044 → 要求REQ-DRAFT-401 → 修正FIX-DEMO-044 → テストREG-044-UI
利用者影響保存失敗後に現在画面の入力消失。再入力が必要
リリース・環境frontend web-demo-r1、API api-demo-r1、productionを仮定。再現は隔離検証環境
エラー根拠同じ保存試行の401、画面例外、入力消失記録を関連付ける仮定。実イベント・trace IDは記載しない
仮説と未確定事項失敗応答を成功扱いし入力を先に初期化した可能性。本番401の原因が満了かは別調査
最小再現条件入力画面が開き合成入力が存在、保存要求に契約上401を返す。UI再現に実顧客・満了トークン不要
合成fixture題名検証用文書、本文合成入力A、検証専用editor。顧客原文・cookie・認証ヘッダーなし
期待結果再ログイン案内、要求処理完了、現在入力維持、保存成功表示なし。APIは拒否要求で文書を作らない
修正候補成功確認後だけ成功処理。401では入力初期化せず復旧案内。実修正は原因確認後に決定
回帰資産UI応答処理REG-044-UI、実認証・保存境界REG-044-API、正常保存REG-044-OK
修正前後比較旧UIは入力維持期待に違反し修正版は満たすべき。未実行なので全結果NOT_RUN
担当・遮断基準frontendがUI修正・試験、API担当が認証・保存確認、QAリードが期待レビュー。安定後に関連変更の必須検査へ
配備後確認修正版適用環境で保存失敗・入力消失信号を分ける。収集状態と実経路利用も確認
維持・廃止認証・応答契約・入力保持方針変更時に再確認。機能廃止や同等検証への置換時は根拠と承認者を残す

ブラウザーとサーバーのテストを分ける

REG-044-UIは合成入力後、保存要求に契約どおり401を返すよう制御します。要求発生と失敗処理完了を確認してから再ログイン案内・入力維持・保存成功表示の不在を検証します。例外が消えただけで終えません。利用者に見える動作の検証はPlaywright公式推奨にも沿います。8 9 11

この試験は401を自分で生成したためサーバー認証を証明しません。REG-044-APIでは隔離環境に試験セッションを作り、サーバー方針で満了状態を設定して実APIを呼びます。拒否応答と非保存状態を確認し、対象の認証・保存ロジック自体はmockにしません。

正常保存を守るREG-044-OKも残します。全要求を失敗扱いにすれば401試験だけは合格する誤修正が可能だからです。正常経路とAPI試験は修正前から合格し得ます。修正前不合格を求めるのは実欠陥を示す再現試験で、関連する全試験ではありません。

入力保持範囲も合意します。本例は現在画面のメモリ状態保持です。ログアウト後の永続保存や機密内容のブラウザー自動保存を提案しません。別アカウントへの切替時は別のセキュリティ・製品方針を定めます。

サービスの仕組み

製品の文脈を保ち、実行規模を調整 — 固定リードが基準と履歴を引き継ぎ、期間ごとのスクワッドの実行結果を判断の根拠にまとめます。

同条件で修正前不合格と修正後合格を確認する

課題を閉じる前に「テスト追加」より強い証拠が必要です。同じ期待とfixtureで欠陥版と修正版を比較し、要件を変えた合格か、欠陥修正による合格かを区別します。

旧版の失敗が対象欠陥によるものか先に確認します。ログイン準備失敗、誤セレクター、環境エラーは再現証拠ではありません。次に修正版の期待と正常・隣接条件を検証します。アプリ版、試験版、fixture版、設定、実行ID、失敗理由を結びます。

旧版や過去状態を復元できなければ、修正前失敗確認を合格で埋めません。「修正後のみ確認」、復元不能条件、不確実性を記録し別証拠で補います。安全なローカル実験で核心条件を戻せても、本番過去状態の完全再現とは混同しません。

最も直接失敗を確認できる階層を選びます。純粋な分岐は単体、認証・保存境界はAPI・統合、画面入力消失はブラウザー試験が適します。全階層に複製せず証明する要件を分けます。Google SREも試験種別とシステム検証の役割を区別します。12

今回どの変更範囲に含めるかは次の判断です。変更別回帰テスト範囲決定ワークブックで記録できます。本記事は本番失敗のテスト化、ワークブックは実行対象と除外根拠の整理を扱います。

配備基準に入れても失敗を隠さない

影響が大きく、制御条件で安定して欠陥を示し、失敗対応担当がいるテストは関連変更の配備遮断基準にできます。検査名・実行条件を定め、関連変更で未実行を成功扱いしません。緊急回避は承認者・理由・補完検証・解除時点を記録します。

原因不明の間欠失敗を急いで必須化すると、配備を止められ続けたチームが検査を切る可能性があります。隔離しても担当と再確認期限を残し、その間の代替検証を定めます。再実行合格と安定性判断は別です。

自動化失敗分析・隔離・復帰の運用書式は、作った試験が不安定になった後の資料です。本番課題から新試験を定義する作業と試験自体の失敗分析を同じ記録に混ぜない方が適切です。

試験を永久に積むだけにもなりません。要件消滅や同等検証への置換で削除できますが、修正が古いだけでは消しません。失敗条件がどこで継続検証されるか確認します。サービス担当は要件、試験担当は実行品質、配備担当は遮断・例外を所有できます。小規模で兼任しても判断は分けて残します。

回帰テストが正解ではない場合も記録する

情報不足なら名目だけの試験より、次回発生時の証拠収集作業を設定します。収集項目・個人情報境界・担当・再確認時点が完了条件です。未観測を再発なしという結論にしません。

外部事業者障害なら自社のタイムアウト、再試行、失敗案内を制御応答で検証できます。ただし事業者の可用性は保証できません。契約に合う連携確認、依存先観測、迂回・復旧手順が別に残ります。

メモリリーク、資源飽和、配備設定、長時間蓄積状態が核心なら、機能回帰だけでは不足し得ます。許可環境の性能・持続負荷検証、設定検査、容量・構造改善、ランブックを組み合わせます。Google SREの事後分析も文書作成より再発・影響を減らす後続措置を重視します。12 13

配備後も課題状態一つで終了しません。修正版が対象環境・利用者へ適用され、問題経路が使われ、収集・サンプリング条件が変わっていないか確認します。利用なし・収集断でのゼロ件は改善証拠になりません。観測期間と再開条件を頻度・影響に合わせ、根拠不足なら確認待ちを維持します。

新プラットフォームは必須ではありません。既存課題管理、試験リポジトリ、配備記録でも結べます。回帰資産設計とCI連携の余力がなければ、IXCテスト自動化サービスの範囲を確認できます。

次の担当者が記録から同じ失敗条件を作り、同じ期待を確認できるとき、本番課題は回帰資産になったと言えます。 エラーを閉じるだけでなく、何を再確認し誰が継続するかを残す必要があります。