테스트 케이스 작성법, QA 전에 먼저 볼 기준

처음이라면 먼저 범위부터 확인하세요

테스트 케이스 작성법을 찾는 사람은 보통 QA 직전에 문서가 비어 있다는 걸 발견합니다. 화면은 어느 정도 나왔고 기능도 개발됐는데, 무엇을 눌러야 통과인지 팀마다 말이 달라지는 순간이 오죠.

먼저 볼 기준은 간단합니다. 테스트 케이스는 “어떤 조건에서, 어떤 값을 넣고, 어떤 결과가 나오면 정상인가”를 한 줄씩 확인하는 문서입니다. 시나리오처럼 큰 흐름을 설명하는 문서가 아니라, 실제 검증 단위를 작게 쪼개는 쪽에 가깝습니다.

아래에서는 테스트 케이스 작성법을 서비스 기획자와 QA 초보자 기준으로 풀어보겠습니다. 요구사항에서 확인 항목을 뽑는 법, 정상 케이스와 예외 케이스를 나누는 기준, 표에 꼭 들어가야 하는 항목, 개발자에게 다시 물어봐야 할 지점까지 순서대로 정리합니다.

공식 QA 용어로 보면 테스트 케이스는 사전 조건, 입력값, 실행 행동, 기대 결과, 사후 조건을 포함하는 검증 단위입니다. 말은 조금 딱딱하지만, 실무에서는 “이 기능이 진짜 약속대로 움직였는지 확인하는 작은 레시피”라고 생각하면 편합니다.

처음부터 완벽한 테스트 문서를 만들려고 하면 손이 멈춥니다. 대신 기능 하나를 고르고, 그 기능이 성공하는 흐름과 실패하는 흐름을 나란히 적어보세요. 여기서 문서의 뼈대가 생깁니다.

기획 단계에서 요구사항이 아직 넓다면 요구사항 정의서 작성법에서 범위를 먼저 줄이는 편이 좋습니다. 요구사항이 흐리면 테스트 기준도 같이 흐려지기 때문입니다.

테스트 문서는 개발자만 보는 자료가 아닙니다. 기획자는 누락된 조건을 찾고, 디자이너는 안내 문구를 확인하고, 운영자는 배포 뒤 문의 기준을 잡습니다. 그래서 독자가 읽고 바로 움직일 수 있게 짧고 구체적으로 쓰는 것이 중요합니다.

테스트 케이스와 시나리오 차이는 어디서 갈릴까

시나리오는 사용자가 서비스를 이용하는 큰 흐름을 보여줍니다. 예를 들어 “회원이 상품을 장바구니에 담고 결제한다”는 하나의 QA 시나리오가 될 수 있습니다.

반면 테스트 케이스 작성법에서는 그 흐름을 더 잘게 쪼갭니다. 장바구니 담기 버튼이 활성화되는 조건, 재고가 없을 때 안내 문구, 결제 수단별 성공 결과, 쿠폰이 적용되지 않는 예외처럼 각각을 확인 단위로 나눕니다.

여기서 많이 헷갈리는 부분은 “시나리오가 있으면 케이스는 안 써도 되나”입니다. 답은 보통 아니에요. 시나리오는 흐름을 이해하는 데 좋고, 케이스는 통과와 실패를 판단하는 데 좋습니다.

결제 기능을 예로 들면 시나리오는 “상품 선택부터 결제 완료까지”를 다룹니다. 케이스는 “품절 상품을 결제하려 할 때 결제 버튼이 막히는가”, “카드 승인 실패 시 주문이 생성되지 않는가”처럼 하나의 조건을 확인합니다.

실무에서는 먼저 시나리오로 큰 길을 그리고, 그 길 위에서 끊어질 수 있는 지점을 케이스로 뽑는 방식이 편합니다. 이렇게 하면 테스트가 너무 넓어지지 않고, 누락도 줄어듭니다.

QA 전에 전체 흐름을 먼저 점검하고 싶다면 서비스 기획자 QA 체크리스트를 같이 열어두면 좋습니다. 체크리스트는 큰 구멍을 찾고, 테스트 케이스는 그 구멍을 확인 가능한 문장으로 바꾸는 역할을 합니다.

요구사항에서 확인 항목을 뽑는 순서

테스트 케이스 작성법의 출발점은 화면이 아니라 요구사항입니다. “이 기능이 왜 필요한가”를 알아야 어떤 결과를 확인해야 하는지도 보입니다.

먼저 기능정의서나 요구사항 문서에서 동사를 찾으세요. 저장한다, 발급한다, 취소한다, 검색한다, 알림을 보낸다처럼 사용자의 행동이나 시스템 처리가 보이는 단어가 테스트 후보입니다.

그다음 조건을 붙입니다. 누가 할 수 있는지, 어떤 상태에서 가능한지, 입력값이 비어 있으면 어떻게 되는지, 권한이 없으면 어디서 막히는지 확인합니다. 조건이 붙는 순간 케이스가 훨씬 선명해집니다.

예를 들어 “관리자가 회원 상태를 변경한다”는 요구사항이 있다면 그대로는 너무 넓습니다. “정상 회원을 휴면으로 변경하면 상태가 휴면으로 저장되고 목록에 즉시 반영된다”처럼 바꿔야 실제 테스트가 됩니다.

요구사항과 기능의 경계가 헷갈린다면 기능정의서 작성방법을 먼저 보고 내려오면 흐름이 잡힙니다. 기능 기준이 정리되어 있어야 QA 문서도 흔들리지 않습니다.

잠깐 정리하면, 케이스는 “기능명”이 아니라 “검증 가능한 조건”으로 써야 합니다.

• 요구사항에서 동사를 찾습니다.
• 동사에 조건과 입력값을 붙입니다.
• 기대 결과와 실패했을 때의 안내를 나눕니다.
• 확인 위치를 화면, API, 관리자, 알림 중 어디인지 표시합니다.

이 순서를 거치면 회의에서 나온 말이 테스트 가능한 문장으로 바뀝니다. 처음에는 느려 보여도, QA 중간에 질문이 줄어드는 효과가 큽니다.

표에는 무엇을 넣어야 바로 확인될까

테스트 케이스 작성법에서 표는 복잡할수록 좋은 게 아닙니다. 초보자라면 3열 정도로 시작해도 충분합니다. 중요한 것은 각 행이 실제로 실행 가능한지입니다.

처음 표를 만들 때는 확인 조건, 실행 방법, 기대 결과를 기본으로 둡니다. 여기에 프로젝트 상황에 따라 테스트 데이터나 우선순위를 덧붙이면 됩니다. 모바일에서 보는 팀원도 많다면 열을 늘리기보다 설명 문단을 아래에 붙이는 편이 읽기 좋습니다.

예를 들면 “비밀번호 찾기” 기능은 사전 조건이 이메일 가입 회원인지, 실행 행동이 이메일 입력 후 인증 요청인지, 기대 결과가 인증 메일 발송과 안내 문구 노출인지로 나뉩니다. 이 정도만 적어도 테스트 담당자는 어디서 시작할지 알 수 있습니다.

주의할 점은 기대 결과를 “잘 된다”라고 쓰지 않는 것입니다. “성공 토스트가 노출된다”, “인증 메일 발송 로그가 남는다”, “비가입 이메일이면 가입 이력 없음 문구가 보인다”처럼 관찰 가능한 결과를 적어야 합니다.

기획자가 표를 쓰는 경우에는 개발자에게 확인할 항목도 표시해두면 좋습니다. API 응답 코드, 데이터 저장 위치, 배치 반영 시점처럼 화면만 봐서는 확인하기 어려운 부분이 있기 때문입니다.

표를 다 쓴 뒤에는 한 줄씩 직접 읽어보세요. “내가 이 문장만 보고 테스트할 수 있나”에 답이 나오지 않으면 실행 행동이나 기대 결과가 아직 흐린 상태입니다.

정상과 예외는 어디서 갈릴까

테스트 케이스 작성법에서 가장 중요한 습관은 성공만 적지 않는 것입니다. 실제 장애나 고객 문의는 정상 버튼보다 예외 상황에서 많이 나옵니다.

정상 흐름은 사용자가 기대한 대로 기능을 끝내는 길입니다. 회원가입이면 입력값을 모두 맞게 넣고 가입 완료 화면까지 도달하는 흐름이죠. 이 흐름은 기본 통과 기준을 확인하는 데 필요합니다.

예외 흐름은 조건이 맞지 않을 때 서비스가 어떻게 반응하는지를 봅니다. 필수값이 비었을 때, 이미 가입된 이메일을 넣었을 때, 권한 없는 사용자가 관리자 메뉴에 접근했을 때, 네트워크가 끊겼을 때처럼 사용자가 실제로 마주칠 수 있는 상황을 적습니다.

처음에는 예외를 너무 많이 넣으려 하지 않아도 됩니다. 대신 돈, 개인정보, 권한, 알림, 저장 실패처럼 영향이 큰 부분부터 고르세요. 이 다섯 가지는 작은 오류가 큰 불편으로 이어지기 쉽습니다.

예외 문구도 확인 대상입니다. “오류가 발생했습니다”만 보이면 사용자는 다시 무엇을 해야 할지 모릅니다. 입력값을 고치면 되는지, 잠시 뒤 다시 해야 하는지, 고객센터에 문의해야 하는지 안내가 나와야 합니다.

관리자 기능이라면 권한 예외를 따로 봐야 합니다. 접근 권한, 수정 권한, 삭제 권한은 비슷해 보여도 위험도가 다릅니다. 어드민 권한 관리 문서를 작성할 때처럼 역할별로 가능한 행동을 나눠두면 테스트 범위가 훨씬 선명해집니다.

실제 예시로 순서를 확인해볼까요

테스트 케이스 작성법을 말로만 보면 추상적으로 느껴질 수 있습니다. 이번에는 “회원이 배송지를 추가한다”는 기능을 가정해보겠습니다.

먼저 정상 케이스입니다. 로그인한 사용자가 배송지 관리 화면에 들어가고, 이름과 전화번호와 주소를 입력한 뒤 저장을 누릅니다. 기대 결과는 배송지 목록에 새 주소가 보이고, 기본 배송지 여부가 설정대로 저장되는 것입니다.

다음은 예외 케이스입니다. 전화번호 형식이 맞지 않으면 저장하지 않고 안내 문구를 보여줘야 합니다. 주소 검색을 완료하지 않은 상태에서 저장을 누르면 주소 입력을 요청해야 합니다. 이미 같은 주소가 있으면 중복 등록을 허용할지, 안내만 보여줄지 기준이 필요합니다.

여기서 테스트 데이터도 같이 적어두면 좋습니다. 정상 전화번호, 잘못된 전화번호, 빈 주소, 긴 상세주소 같은 값을 미리 준비하면 QA 중간에 즉석으로 데이터를 만들 필요가 줄어듭니다.

아래처럼 짧게 써도 실행 가능한 케이스가 됩니다.

1. 로그인한 사용자가 배송지 관리 화면을 엽니다.
2. 이름, 전화번호, 주소를 모두 입력합니다.
3. 저장 버튼을 누릅니다.
4. 목록에 새 배송지가 보이는지 확인합니다.
5. 같은 입력값으로 중복 저장 기준을 확인합니다.

이 예시에서 핵심은 문장 길이가 아닙니다. 누가 봐도 같은 행동을 하고, 같은 결과를 기대할 수 있어야 합니다. 그래서 입력값과 기대 결과가 빠지면 케이스 품질이 급격히 떨어집니다.

화면 설계가 아직 정리되지 않았다면 화면설계서 작성방법과 함께 보세요. 화면의 버튼, 입력칸, 안내 문구가 케이스의 실행 행동과 기대 결과로 이어집니다.

작성 후에는 무엇을 체크할까

테스트 케이스 작성법을 적용한 뒤에는 문서를 한 번 더 QA하듯이 봐야 합니다. 테스트 문서 자체가 애매하면 실제 QA도 애매해집니다.

가장 먼저 볼 것은 중복입니다. 같은 케이스가 이름만 바뀌어 반복되면 QA 시간이 늘고, 중요한 예외가 묻힙니다. 비슷한 케이스가 있다면 조건이나 기대 결과가 정말 다른지 확인하세요.

두 번째는 누락입니다. 정상 흐름은 있는데 실패 흐름이 없는지, 권한 조건은 있는데 데이터 조건이 빠졌는지, 화면 결과는 있는데 저장 결과가 빠졌는지 봅니다. 특히 관리자와 결제 기능은 화면만 보고 통과시키면 위험합니다.

세 번째는 추적성입니다. 각 케이스가 어떤 요구사항이나 기능정의서 항목에서 나온 것인지 표시해두면 변경 대응이 쉬워집니다. 기능이 바뀌었을 때 관련 케이스를 빠르게 찾을 수 있기 때문입니다.

체크리스트로 보면 더 간단합니다.

• 사전 조건이 있는가
• 입력값이나 테스트 데이터가 보이는가
• 실행 행동이 한 사람이 그대로 따라 할 만큼 구체적인가
• 기대 결과가 화면과 데이터 기준으로 나뉘는가
• 예외 상황과 권한 조건이 빠지지 않았는가
• 요구사항이나 기능 ID와 연결되어 있는가

이 정도만 확인해도 문서 품질이 꽤 올라갑니다. 처음부터 대형 QA 도구를 쓰지 않아도 됩니다. 작은 표와 체크리스트로 시작해도 팀이 같은 기준을 보는 효과가 있습니다.

추천 대상과 피해야 할 방식

테스트 케이스 작성법은 서비스 기획자, QA 담당자, 프로젝트 매니저에게 모두 필요합니다. 특히 QA 전날마다 말로 확인하던 팀이라면 문서 한 장만으로도 질문이 많이 줄어듭니다.

추천하는 대상은 기능 범위가 자주 바뀌는 팀입니다. 변경이 많을수록 확인 기준이 남아 있어야 합니다. 개발자에게 “이거 맞나요”를 반복해서 묻는 대신, 케이스를 기준으로 대화하면 훨씬 빠릅니다.

초보 기획자에게도 도움이 됩니다. 테스트를 직접 하지 않더라도 케이스를 써보면 요구사항의 빈칸이 보입니다. 입력값, 예외, 권한, 데이터 저장 위치를 묻는 습관이 생기기 때문입니다.

반대로 피해야 할 방식도 있습니다. 화면 캡처만 잔뜩 붙여놓고 기대 결과를 안 쓰는 문서, “정상 동작 확인”처럼 넓은 말만 남기는 문서, 실패 상황을 전부 QA 담당자 감으로 맡기는 방식은 오래 버티기 어렵습니다.

툴도 처음부터 무겁게 고를 필요가 없습니다. 스프레드시트, 노션, 지라, 테스트 관리 도구 중 무엇을 쓰든 기본은 같습니다. 실행 행동과 기대 결과가 분명하면 도구가 바뀌어도 문서는 살아남습니다.

문서를 다 쓴 뒤 팀원 한 명에게 한 케이스만 실행해달라고 해보세요. 질문 없이 따라 할 수 있다면 좋은 출발입니다. 질문이 나온다면 그 질문이 바로 보강해야 할 항목입니다.

자주 묻는 질문

테스트 케이스 작성법은 누가 알아야 하나요?

QA 전담자가 있으면 QA 팀이 주도하는 경우가 많지만, 서비스 기획자도 기본 구조는 알고 있어야 합니다. 기능을 만든 의도와 조건을 가장 먼저 정리하는 사람이 기획자인 경우가 많기 때문입니다.

기획자가 모든 테스트를 직접 실행할 필요는 없습니다. 대신 사전 조건, 입력값, 기대 결과, 예외 기준을 문서에 남겨두면 QA 담당자가 훨씬 빠르게 확인할 수 있습니다.

작은 팀이라면 PM, 기획자, 개발자가 함께 케이스 초안을 만들기도 합니다. 이때 중요한 것은 담당자보다 기준입니다. 누가 쓰든 다른 사람이 그대로 따라 할 수 있으면 충분히 좋은 문서가 됩니다.

처음 맡았다면 기능 전체를 한 번에 쓰려고 하지 마세요. 로그인, 저장, 삭제, 알림처럼 위험도가 큰 기능을 하나 고르고 정상 흐름과 실패 흐름을 나눠보면 감이 빨리 잡힙니다.

이 과정을 거치면 QA 담당자에게 넘길 때도 대화가 쉬워집니다. “어떤 조건을 기준으로 봐야 하는지”가 문서에 남아 있으면 담당자가 바뀌어도 같은 기준을 유지할 수 있습니다.

QA 시나리오만 있으면 테스트 케이스는 생략해도 될까요?

간단한 기능이라면 시나리오만으로도 큰 흐름을 볼 수 있습니다. 하지만 결제, 회원, 권한, 알림, 데이터 저장처럼 조건이 많은 기능은 케이스로 쪼개는 편이 안전합니다.

시나리오는 사용자의 여정을 보여주고, 케이스는 통과 기준을 보여줍니다. 두 문서가 하는 일이 다르기 때문에 하나로 모든 문제를 해결하려고 하면 빈칸이 생기기 쉽습니다.

처음에는 시나리오를 먼저 쓰고, 그 안에서 실패할 수 있는 지점을 케이스로 뽑아보세요. 이렇게 나누면 문서가 너무 커지지 않고, 실제 QA에서 빠뜨리는 조건도 줄어듭니다.

예를 들어 결제 시나리오는 상품 선택부터 결제 완료까지 이어지는 길입니다. 여기서 쿠폰 오류, 재고 부족, 카드 승인 실패, 배송지 누락 같은 지점은 각각 별도 케이스가 됩니다.

시나리오만 있으면 “흐름은 봤다”는 느낌은 들지만, 어떤 조건에서 통과인지가 흐릴 수 있습니다. 그래서 일정이 짧을수록 위험한 분기만이라도 케이스로 남겨두는 편이 좋습니다.

테스트 케이스는 몇 개 정도 쓰면 적당한가요?

정해진 숫자는 없습니다. 기능 규모, 위험도, 사용자 영향도에 따라 달라집니다. 작은 설정 화면은 몇 개로 충분할 수 있고, 결제나 권한 기능은 훨씬 많은 케이스가 필요합니다.

처음 기준은 정상 흐름 1개, 필수값 누락 1개, 권한 또는 상태 예외 1개, 데이터 저장 확인 1개 정도로 잡아보면 좋습니다. 여기서 위험도가 높은 조건을 더합니다.

숫자를 채우려고 억지로 늘리는 건 피하세요. 같은 케이스를 이름만 바꿔 반복하면 QA 시간이 길어지고, 중요한 조건이 묻힙니다. 실행할 가치가 있는 확인 항목인지 먼저 보는 편이 낫습니다.

팀에 시간이 없다면 사용자 영향도가 큰 기능부터 우선순위를 붙이면 됩니다. 돈이 오가거나 개인정보가 바뀌거나 권한이 달라지는 기능은 작은 화면보다 먼저 확인하는 편이 안전합니다.

운영 중 자주 들어오는 문의도 좋은 힌트입니다. 고객이 자주 헷갈리는 입력값, 실패 문구, 저장 여부를 케이스로 바꾸면 배포 뒤 문의를 줄이는 데 도움이 됩니다.

개발 완료 후에 작성해도 괜찮을까요?

가능은 하지만 추천하기는 어렵습니다. 개발이 끝난 뒤에 케이스를 만들면 요구사항의 빈칸이 늦게 드러납니다. 이때 수정이 필요하면 일정 부담이 커질 수 있습니다.

가장 편한 시점은 기능정의서가 어느 정도 정리되고, 화면 설계가 초안으로 나온 뒤입니다. 이때 케이스를 얇게라도 써두면 개발 중 질문이 줄고, QA 직전에도 기준을 빨리 잡을 수 있습니다.

이미 개발이 끝난 상태라면 걱정할 필요는 없습니다. 지금 화면을 기준으로 정상 흐름과 예외 흐름을 분리하고, 발견된 빈칸을 다음 배포 전 보강하면 됩니다.

늦게 작성하는 경우에는 실제 화면을 보면서 빠르게 역추적하세요. 버튼, 입력칸, 안내 문구를 하나씩 보며 “이 요소가 어떤 조건에서 보여야 하는가”를 묻는 방식이 현실적입니다.

이후에는 새 기능부터라도 개발 전 초안을 남겨두면 됩니다. 완벽한 문서보다 반복 가능한 습관이 중요합니다. 작은 케이스라도 먼저 남기면 팀의 QA 기준이 조금씩 쌓입니다.

QA 전에 이 순서로 확인해보세요

테스트 케이스 작성법은 복잡한 양식을 외우는 일이 아닙니다. 요구사항을 보고, 조건을 나누고, 입력값과 기대 결과를 적어 팀이 같은 기준으로 기능을 확인하게 만드는 일입니다.

처음이라면 기능 하나만 고르세요. 정상 흐름을 먼저 적고, 그다음 필수값 누락, 권한 없음, 저장 실패처럼 실제로 생길 수 있는 예외를 붙이면 됩니다. 이 순서만 지켜도 문서가 훨씬 선명해집니다.

다 쓴 뒤에는 다른 사람이 한 줄만 보고 테스트할 수 있는지 확인하세요. 질문이 나오면 문서가 틀린 게 아니라 보강 지점이 발견된 것입니다. 그 질문을 사전 조건, 실행 행동, 기대 결과 중 어디에 넣을지 정하면 됩니다.

오늘 QA를 앞두고 있다면 전체 문서를 새로 만들기보다 위험한 기능부터 잡는 편이 좋습니다. 결제, 로그인, 권한, 데이터 저장, 알림처럼 사용자 영향이 큰 부분부터 케이스를 만들면 적은 시간으로도 효과가 큽니다.

헷갈린 케이스 문장이나 QA에서 자주 막히는 조건이 있다면 댓글로 남겨주세요. 실제로 막히는 문장을 기준으로 다시 풀어보면, 다음 글에서 더 실무적인 예시로 이어갈 수 있습니다.