개념
이 모듈에서 여덟 개의 기법을 배웠다. 실무에서는 이 기법들을 하나만 골라 쓰지 않고 한 기능에 여러 기법을 겹쳐서 적용한다. 이 마지막 레슨은 그 조합을 실제로 해보고, 결과물(테스트 케이스 목록)에서 중복과 누락을 정리하는 법을 다룬다.
입력·처리·출력(IPO) 관점
테스트 케이스를 짤 때 입력(Input)만 보고 끝내는 경우가 실무에서 가장 흔한 누락이다. 세 관점을 모두 확인하는 습관이 필요하다.
| 관점 | 확인할 것 | 예시 질문 |
|---|---|---|
| 입력 | 어떤 값이 들어오는가 | 유효한 값, 경계값, 비유효값을 다 다뤘는가? |
| 처리 | 시스템 내부에서 무슨 일이 일어나는가 | 계산 로직, 상태 변경, 외부 시스템 호출이 있는가? |
| 출력 | 결과가 어떻게 나타나는가 | 화면 표시, 알림, 로그, DB 저장까지 확인했는가? |
입력만 테스트하고 "정상적으로 처리됐겠지"라고 넘어가면, 계산이 틀렸거나 DB에 잘못 저장되는 결함을 놓친다. 반대로 출력(화면)만 보고 처리 로직을 안 보면, 화면엔 맞게 보이지만 실제 저장된 데이터는 틀린 경우(예: 화면엔 할인가가 보이지만 실제 결제 금액은 정가로 청구)를 놓친다.
기법 조합해보기: "쿠폰 적용" 예시
"주문 금액이 3만원 이상이고 쿠폰이 있으면 10% 할인, 쿠폰이 만료됐으면 적용 안 됨" 기능에 여러 기법을 조합해 테스트 케이스를 짜본다.
| TC | 조건 | 기대 결과 | 사용한 기법 |
|---|---|---|---|
| TC-1 | 29,999원, 쿠폰 있음(유효) | 할인 미적용 | 경계값 |
| TC-2 | 30,000원, 쿠폰 있음(유효) | 10% 할인 적용 | 경계값 |
| TC-3 | 30,000원, 쿠폰 만료됨 | 할인 미적용, 만료 안내 표시 | 결정 테이블 |
| TC-4 | 30,000원, 쿠폰 없음 | 할인 미적용 | 동등분할 |
| TC-5 | 할인 적용 후 실제 결제 금액이 DB에 정확히 기록되는가 | 정가가 아닌 할인가로 기록 | IPO(처리·출력) 관점 |
| TC-6 | 쿠폰 코드에 특수문자 입력 | 에러 없이 "유효하지 않은 쿠폰" 처리 | 오류 추정 |
이 표에서 각 케이스가 왜 존재하는지, 어떤 기법에서 나왔는지를 태그로 달아두면 리뷰에서 "왜 이 케이스가 있나요?"에 바로 답할 수 있다 — 이게 모듈 1(레슨 5)에서 강조한 "설명 가능성"이다.
중복 줄이기
케이스를 여러 기법으로 만들다 보면 같은 걸 다른 이름으로 두 번 확인하는 경우가 생긴다. 예를 들어 "30,000원, 쿠폰 있음"이 경계값 분석에서도 나오고 결정 테이블에서도 똑같이 나올 수 있다. 이럴 땐 무엇을 검증하는지가 완전히 같다면 하나로 합친다. 검증 목적이 조금이라도 다르다면(예: 하나는 화면 표시, 하나는 DB 저장 확인) 남겨둔다 — 이름이 비슷해 보여도 목적이 다르면 중복이 아니다.
누락 줄이기
케이스 목록을 다 만든 뒤, 아래 질문으로 스스로 점검한다.
- 입력·처리·출력 세 관점을 모두 다뤘는가?
- 정상 케이스뿐 아니라 예외·비정상 케이스도 있는가?
- 경계값을 챙겼는가?
- 이 모듈에서 배운 기법 중 아예 안 쓴 갈래(명세/구조/경험)가 있다면, 정말 필요 없어서인지 확인했는가?
실무에서 왜 필요한가
"이 기능 테스트 케이스 짜보세요"는 면접과 실무 모두에서 QA에게 가장 자주 요구되는 실전 능력이다. 이때 평가받는 건 케이스의 개수가 아니라, 여러 기법을 목적에 맞게 조합했는지, 그리고 각 케이스의 존재 이유를 설명할 수 있는지다. 이 레슨에서 연습한 조합 방식은 이 모듈 전체의 최종 결과물이자, 이후 스테이지 4(자동화)에서 어떤 케이스부터 자동화할지 고를 때도 그대로 재사용된다.
실습 과제
과제 1 — 기법 조합해서 TC 작성하기 (20분)
"게시글 신고" 기능을 테스트한다고 하자 — "사용자는 게시글을 신고할 수 있고, 같은 게시글은 한 사용자당 한 번만 신고 가능하다. 신고가 5회 누적되면 게시글이 자동으로 숨김 처리된다." 이 기능에 대해 최소 3가지 다른 기법을 사용한 테스트 케이스를 6개 이상 작성하고, 각 케이스에 사용한 기법을 태그로 단다. 입력·처리·출력 세 관점을 모두 포함시킨다.
과제 2 — 중복 찾기 (8분)
다음 테스트 케이스 목록에서 중복(같은 것을 두 번 확인하는 케이스)을 찾아 표시한다.
- 재고 1개 남은 상품을 주문 → 성공
- 재고 1개 남은 상품을 주문 → 재고가 0으로 줄어드는지 DB 확인
- 재고 0개 상품을 주문 시도 → 실패
- 재고 1개 남은 상품을 정상 주문 → 주문 완료 화면 표시
자가 체크리스트
- 입력·처리·출력(IPO) 세 관점을 구분하고, 각 관점에서 놓치기 쉬운 결함 유형을 설명할 수 있다
- 한 기능에 여러 테스트 설계 기법을 조합해 테스트 케이스를 만들 수 있다
- 각 테스트 케이스가 어떤 기법에서 나왔는지 태그를 달아 설명할 수 있다
- 목적이 같은 중복 케이스를 찾아 정리할 수 있다
- 케이스 목록의 누락 여부를 스스로 점검하는 질문 목록을 적용할 수 있다
흔한 실수
- 입력값 검증에만 집중하고 처리·출력을 놓친다. 계산이 맞는지, 결과가 화면과 DB에 일관되게 반영되는지까지 봐야 완전한 테스트다.
- 케이스 개수를 늘리는 것 자체를 목표로 삼는다. 이 모듈 전체에서 반복 강조했듯, 중요한 건 각 케이스가 서로 다른 것을 검증한다는 근거이지 개수가 아니다.
- 기법 태그 없이 케이스만 나열한다. 태그가 없으면 나중에 리뷰하거나 유지보수할 때 "이 케이스, 왜 있었지?"를 다시 처음부터 고민해야 한다.
참고 자료
- Lee Copeland, A Practitioner's Guide to Software Test Design — 여러 기법을 조합하는 실무 전략을 다룬 챕터
- ISTQB Foundation Level Syllabus — 이 모듈 전체에서 다룬 기법들의 공식 출처, 복습용으로 다시 참고