개념
두 활동의 큰 그림
테스트 절차 ─→ [테스트 실행] ─→ 테스트 실행 로그
절차 선정 → 절차 실행 → 결과 비교 → 실행 기록
│
테스트 실행 로그 ─→ [결함 보고] ▼
결과 분석(구체화·고립화·일반화) → 결함 기록 ─→ 결함 보고서
└──→ 결함 추적 보고서| 활동 | 산출물 | 담는 내용 |
|---|---|---|
| 테스트 실행 | 테스트 실행 로그 | 설명, 수행된 테스트 작업과 이벤트 목록 |
| 결함 보고 | 결함 보고서 | 결함 컨텍스트, 결함 설명, 심각도, 우선순위, 위험 분석, 결함 상태 |
| 결함 보고 | 결함 추적 보고서 | 결함 검토 정보, 결함 해결 정보, 결함 해결 검증 정보 |
1단계 — 테스트 절차 선정
설계 활동에서는 수많은 케이스와 절차가 만들어진다. 무엇부터 실행할지를 정하는 방법은 두 가지다.
우선순위 전략 은 설계 단계에서 이미 매겨 둔 우선순위를 쓴다. 피처 집합 우선순위, 테스트 케이스 우선순위, 테스트 절차 우선순위가 높은 것부터 고른다.
테스트 완료 기준 전략 은 계획서에 정의한 완료 기준을 가장 빨리 달성하게 해 주는 절차를 먼저 고른다.
| 완료 기준 | 먼저 고를 절차 |
|---|---|
| 모듈의 90% 이상이 통과해야 한다 | 아직 통과하지 않은 모듈 을 대상으로 하는 절차 |
| 특정 케이스(TCS-10, TCS-20)가 통과해야 한다 | 그 케이스를 포함 하는 절차 |
| 문장 커버리지 95%를 충족해야 한다 | 문장 커버리지를 높일 수 있는 절차 |
| 심각한 결함이 없어야 한다 | 심각한 결함과 관련된 절차 |
2단계 — 테스트 절차 실행과 실행 주체
선택한 절차를 구축된 환경에서 실행한다. 누가 실행하는지는 레벨마다 다르다.
| 레벨 | 개발자 | 테스터 | 사용자 |
|---|---|---|---|
| 컴포넌트 | ⊙ (주로) | ⊙ (중요 모듈) | |
| 통합 | ⊙ | ⊙ | |
| 시스템 | ⊙ (개발자 환경) | ⊙ (주도) | ⊙ (참여 가능) |
| 인수 | ⊙ | ⊙ (원칙적으로 사용자 환경에서 사용자가) |
컴포넌트 테스트를 개발자가 하는 이유는 개발자 환경에서 하면 환경 구축 비용이 줄고, 결과를 정확하고 빨리 이해 할 수 있기 때문이다. 시스템 테스트는 테스터가 요구사항 명세서를 바탕으로 명세 기반 케이스를 만들어 주도 하는 레벨이다.
3단계 — 테스트 결과 비교
각 케이스의 예상 결과와 실제 결과를 비교한다. 예상 결과는 케이스 명세서에 있거나, 스크립트에 내장되어 있거나, 관련 파일에 있을 수 있다. 탐색적 테스트라면 문서화되어 있지 않을 수도 있다.
비교를 객관적이고 명확하게 하려면 예상 결과를 구체적으로 써야 한다.
- 실숫값이라면 비교할 유효 숫자의 자리 를 정한다.
- 화면이라면 항목 배치, 색상, 표시 메시지 내용까지 정한다.
- 비교 대상은 화면뿐 아니라 소리, 진동, 파일, DB 테이블, 네트워크일 수 있으니 형태에 맞게 예상 결과를 정의한다.
- 출력이 매우 빠르거나, 양이 많거나, 아주 정밀한 비교가 필요하면 비교 자동화 도구 를 쓴다.
4단계 — 테스트 실행 기록
테스터는 실제로 한 작업과 목격한 이벤트를 시간대별로 실행 로그에 남긴다.
테스트 실행 로그 식별자: TL-02
설명 — 테스트 대상: TI-1 / 환경: Windows, 메모리 16GB …
작업과 이벤트
09:00 테스터 A 테스트 시작, 시스템 부팅
09:03 TI-1 실행, TCS-01을 TP-01에 따라 적용
09:05 실행 결과가 TCS-01 예상 결과와 다름 → DR-01
09:10 TI-1 재실행, TCS-02를 TP-02에 따라 적용
09:12 결과는 TCS-02 예상 결과와 같음
그러나 예상치 않게 파일-1이 삭제됨 → DR-02로그의 설명 에는 대상·수행 케이스·적용 절차를 간단히, 작업과 이벤트 에는 실행 준비, 입력, 실행, 결과 관찰을 적는다. 기존 케이스·절차를 그대로 쓴 경우엔 그 식별자 를 적고, 예상과 다른 결과나 예상치 못한 이벤트 는 구체적으로 적는다. 결함 보고서를 썼다면 그 결함 식별자 를 로그에 연결한다.
위 예에서 TCS-02는 결과가 예상과 같았는데도 결함(DR-02)이 등록되었다. 예상 결과 비교만이 결함의 유일한 출처가 아니라는 점을 보여 주는 장면이다. 관찰된 부작용도 결함이다.
결함 보고 — 왜 "인시던트"인가
실행 중 조치가 필요한 이슈를 발견하면 보고한다. 엄밀히는 결함만이 아니라 다양한 이슈가 나오므로 인시던트(Incident) 가 더 맞는 말이고, 29119-2는 이 활동을 테스트 인시던트 보고 라고 부른다. 가이드는 테스트 결과라는 측면에서 "결함 보고"라고 쓴다. 결함 보고서는 버그 보고서, 테스트 사건 보고서, 문제(Anomaly) 보고서라고도 불린다.
테스트 결과 분석 — 구체화 · 고립화 · 일반화
개발자가 결함을 효율적으로 고치려면 결함 상황이 분명해야 한다. 그래서 기록 전에 세 단계로 분석한다.
| 단계 | 질문 | 하는 일 | 예 |
|---|---|---|---|
| 구체화 | 다시 만들 수 있는가? | 재현 가능할 만큼 데이터·절차·환경을 명확히 한다. 여러 번 반복해 보고, 간헐적이면 시도 횟수 대비 발생 횟수 를 적는다 | "10회 중 3회 발생" |
| 고립화 | 무엇 때문인가? | 데이터·절차·환경 중 어느 요소 가 영향을 주는지, 의심 요소 하나만 바꿔 가며 확인한다 | 데이터·절차는 같게, 환경만 바꿨더니 사라짐 → 환경 요인 |
| 일반화 | 어디까지 해당되는가? | 영향을 주는 요소를 최대한 일반적으로 기술한다 | X=-1, -2에서 발생 → 추가 테스트로 "음의 정수 전체"에서 발생 확인 |
고립화는 범위를 좁히는 것이고, 일반화는 범위를 넓혀서 정확히 말하는 것이다. 방향이 반대라서 둘을 섞어 묻는 문제가 나온다. 윈도우 8에서 발견했는데 7과 10에서도 같은 결함이 나면 "윈도우 8에서 발생"이 아니라 "확인한 모든 윈도우 버전에서 발생"이라고 쓰는 것이 일반화다.
결함 보고서의 여섯 항목
| 항목 | 내용 |
|---|---|
| 결함 컨텍스트 | 어떤 상황에서 식별됐나 — 개별 테스트(컴포넌트·통합 중 어디서), 테스트 대상, 환경, 절차와 케이스, 구체적 데이터 |
| 결함 설명 | 실제 결과(화면 캡처·파일), 이상 상황(실제와 예상의 차이 분석, 예상치 못한 오동작) |
| 심각도 | 발견자 관점에서 기술적·비즈니스적 영향의 범위와 크기. 해결 예상 시간, 임시 우회 방법(Workaround)도 적을 수 있다 |
| 우선순위 | 해결의 긴급성. 보통 3~5단계 (즉시 해결, 다음 릴리스 해결 …) |
| 위험 분석 | 이 결함으로 생긴 새 위험, 기존 위험의 발생 가능성·영향도 변화 |
| 결함 상태 | Open, Assigned, Resolved … 현재 조치 상태 |
보고서 머리에는 결함 식별자, 발견한 테스터, 발견 일시가 들어간다. 심각도는 영향, 우선순위는 긴급성 이다. 심각도가 높아도 우선순위는 낮을 수 있고(드물게 쓰는 관리 기능의 데이터 손상 결함인데 다음 달 개편 예정), 그 반대도 있다(첫 화면 로고 오타는 영향은 작지만 내일 언론 발표라 긴급하다).
결함 생명 주기
개발자는 소프트웨어를 만들어 넘기고, 테스터는 테스트하고 결함을 통보하고, 개발자는 고쳐서 다시 넘기고, 테스터는 다시 테스트한다. 이 왕복을 결함 입장에서 보면 상태가 바뀌어 가는 생명 주기가 된다.
Open
│
Review ──────────────┬──────────────┐
│ 이번에 고친다 │ 다음에 │ 무시
Assigned ←─ Reopen ←─ Deferred │
│ ▲ ▲ │
Resolved │ │ │
(Fixed / Duplicated / Won't Fix / Invalid) │
│ │ │ │
Verified ──────┴────────┘ │
│ │
Closed ←──────────────────────────────┘| 상태 | 뜻 |
|---|---|
| Open | 분석(구체화·고립화·일반화)을 거쳐 결함 보고서에 기록되어 추적 대상 이 됨 |
| Review | 처리 방안 검토. 위험성(발생 가능성·심각성·긴급성)을 보고 이번에 수정(→ Assigned), 다음 릴리스(→ Deferred), 무시(→ Closed) |
| Deferred | 다음 릴리스로 연기. 적절한 때 Reopen되어 처리가 다시 시작됨 |
| Assigned | 수정할 개발자가 정해지고 해결이 요구됨 |
| Resolved | 개발자가 처리 결과만 제시함. 아직 검증 전 |
| Verified | 개발자 처리가 합당하고 정확한지 검증됨 |
| Reopen | 다시 처리가 필요함 |
| Closed | 종결 |
Resolved의 네 가지 유형
| 유형 | 뜻 | 테스터의 검증 방법 |
|---|---|---|
| Fixed | 수정함 | 재테스팅 으로 정확히 고쳐졌는지 확인 |
| Duplicated | 기존 결함과 중복 | 정말 같은 결함인지, 그 이전 결함은 제대로 처리됐는지 확인 |
| Won't Fix | 지금 고칠 만큼 중요·긴급하지 않아 안 고침 | 테스트 관리자가 정말 중요·긴급하지 않은지 확인 |
| Invalid | 프로그램이 아니라 결함 보고(케이스·절차) 자체가 문제 | 결함 보고에 정말 문제가 있는지 확인 |
Resolved와 Verified가 따로 있는 이유 가 핵심이다. 개발자가 "고쳤다(Fixed)", "결함 아니다(Invalid)"라고 말한 것은 주장 이고, 테스터가 확인해야 사실 이 된다.
Verified 이후의 상태 (표 14.7) — 시험에 그대로 나온다.
| 처리 유형 | 검증 결과 정확 | 부정확 |
|---|---|---|
| Fixed | Closed | Reopen |
| Duplicated | Closed | Reopen |
| Won't Fix | Deferred | Reopen |
| Invalid | Closed | Reopen |
넷 중 Won't Fix만 정확해도 Closed가 아니라 Deferred 로 간다. 지금은 안 고치는 게 맞다는 뜻이지, 결함이 없어진 것이 아니기 때문이다. 부정확하면 넷 모두 Reopen이다.
세 가지 처리 시나리오
| 시나리오 | 상태 흐름 |
|---|---|
| 경미한 결함을 무시 | Open → Review → Closed |
| 차후 릴리스에서 처리 | Open → Review → Deferred → (다음 릴리스) Reopen → Assigned → Resolved → Verified → Closed 또는 다시 Deferred |
| 이번 릴리스에서 처리 | Open → Review → Assigned → Resolved → Verified → Closed (또는 Reopen) |
두 번째와 세 번째의 차이는 Review 다음에 Deferred로 가느냐, 바로 Assigned로 가느냐 뿐이다. 옛 판 본문에는 두 번째 시나리오 설명에서 "표 11.7에서 볼 수 있듯이"라는 잘못된 참조가 있었고 정오표로 고쳐졌다. 내용상 참고할 곳은 Verified 이후 상태를 정리한 위의 표 14.7이다.
결함 추적 보고서
결함이 등록된 순간부터 종결까지, 개발자와 테스터가 한 일을 남긴다.
| 부분 | 기록하는 것 |
|---|---|
| 결함 검토 정보 | 검토자, 검토 일자, 처리 유형(담당자 할당 / 처리 연기 / 결함 무시), 검토 설명(할당이면 담당 개발자) |
| 결함 해결 정보 | 해결자, 해결 일자, 해결 유형(Fixed / Duplicated / Won't Fix / Invalid), 해결 설명 |
| 결함 해결 검증 정보 | 검증자, 검증 일자, 검증 결과, 검증 설명(Fixed면 재테스팅 결과) |
검토 정보의 세 처리 유형은 그대로 Assigned·Deferred·Closed에 대응한다. 그리고 가이드는 결함 추적 보고서가 ISO/IEC/IEEE 29119-3 표준에는 들어 있지 않다 고 밝힌다. 표준 문서 목록을 묻는 문제에 주의한다.
여러 이해관계자가 함께 봐야 하므로 문서 대신 결함 추적 지원 도구 를 쓰는 것이 효과적이다. 도구는 기록뿐 아니라 처리 상황을 여러 기준으로 분석한 보고서도 만들어 현재 테스트 상황을 종합적으로 보여 준다.
실무에서 왜 필요한가
Jira 같은 도구의 결함 워크플로는 회사마다 상태 이름이 조금씩 다르지만 뼈대는 이 생명 주기와 같다. 도구에 "Resolved"와 "Closed" 사이에 단계가 없으면 개발자의 주장이 검증 없이 종결되는 구조라는 뜻이고, 그런 팀에서는 "고쳤다고 했는데 안 고쳐진" 결함이 운영으로 샌다. 생명 주기를 알면 워크플로 설계의 빈틈을 지적할 수 있다.
구체화·고립화·일반화는 좋은 결함 리포트의 세 조건이다. "가끔 결제가 안 돼요"(구체화 안 됨)는 재현 불가로 닫힌다. "크롬에서 결제가 안 돼요"(고립화 안 됨, 사파리는 확인 안 함)는 개발자가 엉뚱한 곳을 뒤진다. "쿠폰 A를 쓰면 안 돼요"(일반화 안 됨)는 쿠폰 A만 고치고 같은 유형의 쿠폰 B, C는 그대로 남는다.
실행 로그를 시간순으로 남기는 습관은 간헐적 결함에서 빛난다. "오전 10시 이후에만 났다"는 사실을 로그에서 발견하면 배치 작업과의 충돌 같은 원인을 추적할 수 있다.
채용시장에서의 위치
신입 테스터 채용 과제의 단골이 "이 앱에서 결함을 찾아 결함 보고서를 쓰라"다. 평가자는 결함 개수보다 보고서의 질 을 본다. 재현 절차가 구체적인가(구체화), 원인 범위를 좁혔는가(고립화), 영향 범위를 말했는가(일반화), 심각도와 우선순위를 구분해 근거를 댔는가. 면접에서 "Resolved와 Closed 사이에 무엇이 있어야 하나요?", "Won't Fix 처리된 결함은 어디로 가나요?" 같은 질문도 자주 나오는데, 이 레슨의 표가 그대로 답이다.