개발자도 다시 묻지 않는 ‘좋은 테스트 케이스’ 작성법

QA 엔지니어가 버그를 발견하고 개발자에게 “로그인이 안돼요”라고 말하는 상황을 상상해 봅시다. 아마도 개발자에게 가장 먼저 돌아올 질문은 이것일 겁니다. “어떻게 테스트하셨는데요? 재현 경로 좀 알려주세요.”

이때 빛을 발하는 것이 바로 ‘테스트 케이스(Test Case)’입니다. 잘 작성된 테스트 케이스는 이런 불필요한 질문과 커뮤니케이션 비용을 없애주는, QA와 개발자 사이의 가장 중요하고 기본적인 소통 도구입니다.

이번 글에서는 누가 읽어도 명확하게 이해하고 따라 할 수 있는, 효율적이고 효과적인 테스트 케이스를 작성하는 방법에 대해 알아보겠습니다.

테스트 케이스란 무엇이고 왜 중요한가?

테스트 케이스는 특정 기능이나 경로가 의도대로 동작하는지 검증하기 위해 수행해야 할 ‘행동과 조건의 집합’입니다. 간단히 말해, 특정 테스트를 위한 상세한 ‘단계별 실행 매뉴얼’이라고 할 수 있습니다.

많은 사람들이 테스트 케이스 작성을 번거로운 문서 작업이라고 생각하지만, 이는 다음과 같은 중요한 가치를 가집니다.

• 명확성: 테스트의 목적과 방법을 명확히 하여, 누가 테스트를 수행하더라도 동일한 결과를 보장합니다.
• 재사용성: 한번 잘 만들어두면, 새로운 기능이 추가되거나 코드가 수정될 때마다 반복적으로 사용하며 ‘회귀 테스트(Regression Test)’를 효율적으로 수행할 수 있습니다.
• 추적성: 요구사항과 테스트 케이스를 연결하여, 어떤 요구사항이 테스트되었고 어떤 부분이 누락되었는지(테스트 커버리지)를 추적할 수 있습니다.
• 지식 이전: 새로운 팀원이 합류했을 때, 테스트 케이스를 읽는 것만으로도 서비스의 주요 기능과 동작 방식을 빠르게 파악할 수 있는 훌륭한 가이드가 됩니다.

좋은 테스트 케이스를 구성하는 필수 항목 7가지

효과적인 테스트 케이스는 정해진 양식이 있는 것은 아니지만, 일반적으로 아래 7가지 필수 항목을 포함할 때 가장 명확하고 유용합니다.

1. 테스트 케이스 ID (Test Case ID)각 테스트 케이스를 고유하게 식별하기 위한 번호입니다. 나중에 결함을 추적하거나 테스트 실행 결과를 관리할 때 매우 중요합니다. (예: TC-LOGIN-001)
2. 테스트 항목 (Test Suite / Feature)테스트가 속한 큰 기능 단위나 모듈을 의미합니다. (예: 로그인, 회원가입, 장바구니)
3. 테스트 목표/설명 (Test Objective / Summary)이 테스트 케이스가 무엇을 검증하려 하는지를 한두 문장으로 요약하여 기술합니다. (예: 올바른 사용자 정보로 로그인 시 성공 여부 검증)
4. 사전 조건 (Preconditions)테스트를 수행하기 전에 반드시 만족되어야 하는 환경이나 상태를 의미합니다. 재현성을 위해 매우 중요한 항목입니다. (예: 테스트 계정이 데이터베이스에 존재해야 함)
5. 테스트 절차 (Test Steps)테스트를 수행하기 위한 구체적인 행동을 순서대로, 번호를 붙여 작성합니다. 각 단계는 간결하고 명확한 단일 행동이어야 합니다.
6. 예상 결과 (Expected Result)테스트 절차를 모두 수행했을 때, 검증하고자 하는 ‘단 하나의 명확한 결과’를 기술합니다. ‘성공’처럼 모호한 표현이 아닌, ‘메인 페이지로 이동해야 한다’처럼 객관적으로 참/거짓을 판단할 수 있어야 합니다.
7. 실제 결과 및 상태 (Actual Result & Status)테스트를 실제로 수행한 후 관찰된 결과를 기록하고, 예상 결과와 비교하여 ‘성공(Pass)’ 또는 ‘실패(Fail)’ 상태를 판정하는 란입니다.

실전 예제: 로그인 기능 테스트 케이스 ‘분리하여’ 작성하기

좋은 테스트 케이스는 하나의 케이스가 하나의 검증 항목만 갖도록 ‘원자적으로(atomically)’ 작성하는 것이 가장 이상적입니다. ‘성공적인 로그인’이라는 하나의 시나리오를 이 원칙에 따라 아래와 같이 여러 개의 테스트 케이스로 분리해 보겠습니다.

케이스 1: 페이지 이동 검증

• TC ID: TC-LOGIN-001
• 테스트 항목: 로그인
• 테스트 목표: 올바른 아이디와 비밀번호로 로그인 시, 메인 페이지로 올바르게 이동하는지 검증한다.
• 사전 조건:
  1. 테스트 계정(ID: testuser, PW: Password123)이 DB에 생성되어 있어야 함.
  2. 웹 브라우저에서 로그인 페이지(https://example.com/login)에에) 접속한 상태여야 함.
• 테스트 절차:
  1. ‘아이디’ 입력란에 ‘testuser’를 입력한다.
  2. ‘비밀번호’ 입력란에 ‘Password123’을 입력한다.
  3. ‘로그인’ 버튼을 클릭한다.
• 예상 결과: 현재 페이지의 URL이 메인 페이지 주소(https://example.com/main)여야여야) 한다.

케이스 2: 환영 메시지 표시 검증

• TC ID: TC-LOGIN-002
• 테스트 항목: 로그인
• 테스트 목표: 로그인 성공 후, 메인 페이지에 사용자 환영 메시지가 올바르게 표시되는지 검증한다.
• 사전 조건: TC-LOGIN-001 실행 성공. 즉, 사용자가 로그인하여 메인 페이지에 있는 상태여야 함.
• 테스트 절차:
  1. 메인 페이지 우측 상단 영역을 확인한다.
• 예상 결과: 화면 우측 상단에 ‘testuser님, 환영합니다.’ 라는 텍스트가 표시되어야 한다.

원칙과 실용 사이의 균형

위와 같이 테스트 케이스를 기능적으로 잘게 분리하여 작성하는 것이 가장 정석적인 방법이며, 특히 테스트 자동화를 설계할 때는 거의 필수적인 원칙입니다. 실패 시 원인을 명확하게 특정할 수 있기 때문입니다.

다만, 실제 현업의 ‘수동 테스트’ 환경에서는 테스트 효율성을 위해, ‘하나의 사용자 행동으로 인해 발생하는 직접적이고 연속적인 결과들’을 하나의 케이스에 묶어 기술하기도 합니다. 예를 들어, TC-LOGIN-001의 기대 결과에 ‘1. 메인 페이지로 이동한다. 2. 환영 메시지가 표시된다.’ 와 같이 번호를 붙여 여러 검증 포인트를 두는 방식입니다.

두 방식 모두 장단점이 있으므로, 중요한 것은 팀의 규칙과 상황(수동/자동, 프로젝트 복잡도 등)에 맞는 최선의 방식을 선택하고 일관성을 유지하는 것입니다.

결론: 잘 쓴 테스트 케이스 하나가 열 마디 말보다 낫다

좋은 테스트 케이스는 단순히 버그를 찾기 위한 도구가 아닙니다. 팀 전체의 이해도를 높이고, 불필요한 커뮤니케이션을 줄이며, 장기적으로는 서비스의 품질을 안정적으로 유지하는 가장 중요한 자산입니다.

처음에는 항목 하나하나를 채우는 것이 번거롭게 느껴질 수 있지만, 명확하고 재사용 가능하며 추적 가능한 테스트 케이스를 작성하는 데 시간을 투자하는 습관은, 훗날 디버깅과 회귀 테스트에 들어갈 훨씬 더 많은 시간을 절약해 줄 것입니다. 이는 모든 QA 엔지니어가 갖춰야 할 가장 기본적인 핵심 역량입니다.