수동 테스트 체크리스트에 필요한 사전 조건, 행동, 예상 결과, 실제 결과, 통과 여부를 설명하고 예약 앱 예시 표를 제공합니다.
수동 테스트는 누가 실행해도 같은 조건과 결과로 판단할 수 있을 때 반복 가능한 품질 기준이 됩니다.
연재 안내: 27편 전체 순서와 현재 공개된 글은 비개발자 바이브코딩 로드맵에서 확인할 수 있습니다.
무엇을 먼저 테스트할지 정하지 못했다면 비개발자 앱 테스트 시작 순서부터 읽어보세요.
한 줄 답변
수동 테스트 체크리스트는 기능 이름만 나열하는 표가 아닙니다. 테스트 전 상태, 사용자가 할 행동, 기대 결과, 실제 결과, 통과 여부, 오류 증거를 누구나 같은 순서로 반복할 수 있게 적은 문서입니다.
좋은 체크리스트의 일곱 칸
| 항목 | 적을 내용 |
|---|---|
| 번호 | 다시 찾기 쉬운 고유 번호 |
| 기능 | 로그인, 예약 등록 같은 대상 |
| 사전 조건 | 계정 상태, 기존 데이터, 사용 기기 |
| 행동 | 클릭과 입력을 순서대로 기록 |
| 예상 결과 | 눈으로 확인할 완료 기준 |
| 실제 결과 | 실행 후 나타난 결과 |
| 판정·증거 | PASS/FAIL, 로그, 스크린샷 링크 |
사전 조건이 빠지면 사람마다 다른 환경에서 테스트해 결과가 달라집니다. 예상 결과가 모호하면 통과 여부를 판단할 수 없습니다.
예약 문의 앱 예시
| 번호 | 기능 | 사전 조건 | 행동 | 예상 결과 |
|---|---|---|---|---|
| RES-01 | 정상 등록 | 로그인, 미래 날짜 | 이름과 날짜 입력 후 저장 | 목록 최상단에 한 건 표시 |
| RES-02 | 필수값 검사 | 로그인 | 이름을 비우고 저장 | 저장하지 않고 이름 안내 표시 |
| RES-03 | 과거 날짜 | 로그인 | 어제 날짜 선택 후 저장 | 과거 날짜 불가 안내 표시 |
| RES-04 | 중복 클릭 | 로그인, 느린 네트워크 | 저장 버튼을 빠르게 두 번 누름 | 예약 한 건만 생성 |
| RES-05 | 권한 확인 | 다른 고객 계정 | 타인의 예약 주소로 접근 | 데이터 없이 접근 거절 |
| RES-06 | 서버 실패 | 테스트 서버 오류 설정 | 정상값으로 저장 시도 | 로딩이 끝나고 재시도 안내 표시 |
실행할 때는 실제 결과와 PASS/FAIL 열을 추가합니다. 실패한 경우 오류 메시지와 발생 시각도 적으면 서버 로그를 찾기 쉽습니다.
정상, 실패, 경계, 권한을 섞는다
체크리스트가 정상 시나리오만 있으면 “잘 쓰는 사용자”만 시험하게 됩니다. 다음 네 종류가 최소한 한 개씩 있어야 합니다.
- 정상: 올바른 입력과 순서
- 실패: 빈 값, 잘못된 형식, 서버 오류
- 경계: 최대 길이, 정원 전후, 날짜 경계, 연속 클릭
- 권한: 로그아웃, 일반 사용자, 관리자, 다른 사용자 데이터
결제나 삭제 기능에는 취소, 재시도, 중복 요청, 처리 중 새로고침도 추가합니다.
문장은 재현 가능하게 쓴다
“이상한 값을 넣어본다”는 사람마다 다르게 실행합니다. “이름 칸에 공백 한 칸만 입력하고 저장 버튼을 누른다”처럼 값과 행동을 적습니다. “정상 동작한다” 대신 “데이터를 저장하지 않고 입력창 아래에 이름을 입력하세요가 표시된다”고 씁니다.
다른 사람이 같은 문서를 보고 같은 결과를 만들 수 있어야 좋은 테스트입니다.
테스트 데이터와 환경을 분리한다
고객 이름과 연락처를 복사하지 말고 테스트 전용 계정과 가짜 데이터를 사용합니다. 운영 데이터베이스에서 삭제 테스트를 하지 않습니다. 테스트 환경이 따로 없다면 삭제 가능한 임시 항목과 복구 방법을 먼저 정합니다.
브라우저, 모바일 크기, 운영체제, 앱 버전이 결과에 영향을 줄 수 있으면 체크리스트 상단에 테스트 환경을 기록합니다.
실행 순서를 정한다
로그인처럼 뒤 기능의 전제가 되는 항목부터 실행합니다. 기본 흐름, 실패 입력, 권한, 네트워크 실패 순으로 진행하면 앞 단계 오류가 뒤 결과에 미치는 영향을 줄일 수 있습니다.
매 배포마다 반드시 실행할 핵심 5개와 큰 변경 때만 실행할 전체 목록을 구분하면 부담이 줄어듭니다. 실패가 잦고 반복 실행하는 항목은 자동화 후보로 표시합니다.
실패 항목을 관리하는 방법
FAIL이 나오면 체크 표시를 지우고 끝내지 않습니다. 오류 ID, 재현 순서, 로그, 수정 커밋을 연결합니다. 수정 후 같은 항목을 다시 실행하고 관련된 핵심 항목도 확인합니다.
체크리스트는 한 번 만들고 버리는 문서가 아니라 실제 오류를 발견할 때마다 좋아지는 운영 자산입니다. 다음 글에서는 앱이 외부 기능과 연결되는 기본인 API 요청·처리·응답을 설명합니다.
체크리스트도 버전을 남긴다
기능이 바뀌었는데 과거 예상 결과를 그대로 두면 정상 동작을 실패로 판단할 수 있습니다. 체크리스트 상단에 앱 버전, 수정일, 작성자, 관련 요구사항 링크를 기록하세요. 항목을 삭제하기보다 더 이상 적용되지 않는 이유와 마지막 사용 버전을 남기는 편이 좋습니다.
오류 수정으로 새 테스트가 생겼다면 해당 버그 ID와 연결합니다. 어떤 문제 때문에 항목이 추가됐는지 알면 나중에 자동화 우선순위를 정하기 쉽습니다. 배포에 사용한 체크리스트 결과는 그 시점의 품질 근거이므로 수정본과 분리해 보관하세요.
여러 사람이 실행한다면 예상 결과의 문구와 화면 위치를 구체적으로 맞춥니다. 판정이 사람마다 달랐던 항목은 증거 예시를 추가하고, 테스트 자체가 모호한지 요구사항이 모호한지 먼저 구분하세요. 좋은 체크리스트는 기능 기준을 더 선명하게 만드는 도구이기도 합니다.
수동 테스트 체크리스트 최종 점검
수동 테스트 체크리스트의 각 항목에는 사전 조건, 한 가지 행동, 눈으로 확인할 예상 결과가 있어야 합니다. 수동 테스트 체크리스트에 “잘 되는지 확인”처럼 모호한 문장이 있다면 어떤 값과 화면 상태가 PASS인지 구체적으로 다시 적으세요.
정상값뿐 아니라 빈 값, 경계값, 중복, 권한 없는 계정, 느린 네트워크를 포함하고 실제 결과와 증거를 남깁니다. 수정할 때마다 핵심 항목을 다시 실행하면 이전 기능이 깨지는 회귀 오류를 배포 전에 발견할 수 있습니다.
바이브코딩 전체 순서 보기
바이브코딩 뜻, 하는법, 도구 선택, API 연결, 데이터베이스, 배포 흐름은 바이브코딩 가이드에서 이어서 볼 수 있습니다.
