팀의 테스트 문서는 한 시나리오 안에 완료 조건, 따라 할 단계, 수행 결과가 있었습니다. 기존 결과를 보면 일부 결함이 있다는 메모를 남겨도 어느 조건을 다시 실행해야 하는지 단번에 찾기 어려웠습니다. 반대로 단계에 있는 확인 절차를 조건과 대조하면, 그 동작의 기대 결과가 문서 어디에도 없는 경우가 있었습니다.

번호로 판정과 재현 연결

완료 조건 번호와 가이드 단계 번호를 맞췄습니다. 예를 들어 조건 ④가 곡을 지정하지 않을 때 가장 최근에 연주한 곡이 선택된다는 내용이면, 단계 ④에는 곡 ID 없이 요청하고 응답과 DB에서 비교할 위치를 적습니다. 조건은 기대 결과를, 단계는 그 결과를 볼 방법을 담습니다. 로그인과 같은 공통 준비는 시작 상태에 적고, 결과나 결함은 같은 번호 줄에 남기도록 했습니다.

이미 결과가 기록된 시나리오에서 조건 번호를 다시 매기면 기존 결함이 다른 조건을 가리킵니다. 그래서 새 조건은 마지막 번호 뒤에 붙이고 기존 문장은 번호가 확인되는 줄로 옮겼습니다. 번호가 없는 기록은 별도 구역에 그대로 보존했습니다. 비어 있는 번호 줄은 기록이 없다는 뜻으로 정했습니다.

조건에 매핑되지 않은 절차 검토

47개 행을 대조하는 과정에서 검토 대상이 125건 나왔습니다. 그중 연습 기록의 메모 길이 500자와 501자가 입력값에 있는데 기대 결과가 없던 행이 있었습니다. 서버의 도메인 테스트는 한글 500자를 허용하고 501자를 거절합니다. 실제 HTTP와 임시 MySQL을 연결한 테스트에서는 501자 메모를 PUT으로 보내 400을 확인했고, DB에서 대상 기록의 저장 시각도 여전히 비어 있었습니다.

QA 조건에는 이 두 검사를 근거로 허용 길이와 초과 입력의 기대 응답을 적을 수 있습니다. 500자 허용의 근거는 도메인 검사이며, 501자 초과의 근거는 HTTP 응답과 DB 상태입니다. 125건은 문서에서 찾은 검토 대상의 수이고, 실제 앱에서 이 경계값을 실행한 결과는 별도입니다.

가이드 단계가 어느 조건에도 대응하지 않으면 코드와 명세에서 근거를 찾습니다. 요구사항이면 판정 조건을 추가하고, 다른 행에서 다루면 그 위치를 남깁니다.

코드와 문서의 기준값 대조

문서에 적힌 최소 템포는 40 BPM이었고, 앱 코드의 가장 느린 단계는 곡의 기본 BPM에 0.6을 곱해 정수로 반올림했습니다. 늴리리야는 66에 0.6을 곱한 39.6이 40, 아리랑은 96에 0.6을 곱한 57.6이 58이 됩니다. 40은 검토한 곡 중 기본 BPM이 가장 낮은 곡의 결과였습니다. 완료 조건에 곡별 계산 규칙을 적으면 어떤 곡을 골라도 기대하는 수치를 구할 수 있습니다. 계산만으로 차이를 설명할 수 없으면 승인된 계약과 구현을 대조하고, 어느 쪽을 고칠지 판단할 근거를 남겼습니다.

가이드의 화면 이름은 이동 코드와 화면에 표시하는 문자열을 함께 확인했습니다. 연습 기록지를 보려면 결과 화면에서 기록 보러 가기를 누른 뒤 연습 기록 화면에서 연습 기록지로 이동합니다. 이 경로는 코드에서 확인했습니다. 테스트 데이터에는 입력하거나 선택할 값만 남겼고, 로그인처럼 미리 갖출 조건은 가이드의 시작 상태로 옮겼습니다. 이 작업으로 확인한 것은 문서의 판정 기준과 재현 단계가 코드와 일치하는지였습니다. 실제 앱에서 그 절차를 수행한 결과는 별도로 기록하도록 했습니다.

API 정보를 QA 문서로 옮길 때는 경로와 설명만 복사했습니다. 명세에 앱이 아직 연결되지 않았다고 적힌 소셜 가입 API를 실제로는 앱 코드에서 호출하고 있었습니다. 진행 상태까지 복사했다면 QA 문서에도 같은 차이가 생겼을 겁니다. 상태는 원본 문서를 가리키도록 하고, 코드에서 호출 지점을 확인한 결과와 실기기에서 가입을 끝까지 검사한 결과는 따로 다뤘습니다.