소프트웨어 테스팅 프로세스

💡 용어 정리

• 테스트 프로세스: 테스트를 체계적으로 수행하기 위한 전체 활동의 흐름
• 테스트 계획(Test Planning): 무엇을, 어떻게, 언제 테스트할 것인지 결정하는 활동
• 테스트 제어(Test Control): 테스트가 계획대로 진행되는지 확인하고 필요하면 조정하는 활동
• 테스트 분석(Test Analysis): 무엇을 테스트해야 하는지 식별하는 활동
• 테스트 설계(Test Design): 식별한 테스트 항목을 실제로 검증할 수 있는 Test Case로 구체화하는 활동
• 테스트 구현(Test Implementation): 테스트를 실행할 수 있도록 Test Case를 정리하고 Test Suite, Test Procedure, Test Data 등을 구성·준비하여 실행 가능한 상태로 만드는 활동
• 테스트 실행(Test Execution): 실제 테스트를 수행하고 결과를 기록하는 활동
• 완료 조건 평가 및 보고: 정의한 종료 조건을 만족했는지 평가하고 결과와 리스크를 공유하는 활동
• 테스트 마감(Test Closure): 테스트 결과와 산출물을 정리하고 테스트 활동을 종료하는 과정

SW 테스팅 프로세스란?

SW 테스팅 프로세스

① 테스트 계획과 제어
② 테스트 분석과 설계
③ 테스트 구현과 실행
④ 완료 조건의 평가와 보고
⑤ 테스트 마감 활동

프로젝트에서는 시간, 인력, 테스트 환경 등 사용할 수 있는 자원이 제한되어 있다.
따라서 단순히 기능을 처음부터 끝까지 무작정 테스트하는 것이 아니라 다음과 같은 내용을 체계적으로 관리할 필요가 있다.

• 무엇을 테스트할 것인지
• 어떤 기능을 우선적으로 테스트할 것인지
• 어떤 방법으로 테스트할 것인지
• 언제 테스트를 시작하고 종료할 것인지
• 어떤 환경과 데이터가 필요한지
• 테스트가 계획대로 진행되고 있는지

즉, 테스트 프로세스는 제한된 시간과 자원 안에서 테스트를 효율적이고 효과적으로 수행하기 위한 체계적인 활동의 흐름이다.

🧩 여기서 효율적과 효과적은 다음과 같이 구분해서 이해할 수 있다.

• 효율적(Efficient): 제한된 시간과 자원을 적절하게 사용하여 테스트를 수행하는 것
• 효과적(Effective): 테스트를 통해 목표한 품질 및 테스트 목적을 달성하는 것

1. 테스트 계획과 제어

1.1 테스트 계획 (Test Planning)

테스트 계획은 테스트 목표를 달성하기 위해 필요한 활동을 정의하고 프로젝트의 전체적인 테스트 방향을 결정하는 과정이다.

테스트 계획에서는 프로젝트에 따라 다음과 같은 내용을 정의할 수 있다.

• 테스트 목표: 요구사항 충족 여부 확인 / 결함 발견 / 품질 수준 확인 / 리스크 감소 등
• 테스트 범위 (완벽한 테스팅은 불가능 → Risk-based Testing)
• 테스트 레벨: 단위 / 통합 / 시스템 / 인수 등
• 테스트 일정 / 인력 및 역할 / 환경 / 접근 방법 / 시작 · 종료 조건
• 리스크와 우선순위 / 산출물

테스트 계획서는 이번 프로젝트에서 테스트를 어떤 범위와 방법으로 수행할 것인지 정한 지침서라고 볼 수 있다.

또한 테스트 계획은 한 번 작성하고 끝나는 문서가 아니다.
프로젝트 진행 상황이나 고객 요구사항, 개발 일정, 리스크 변화 등에 따라 수정될 수 있다.

1.2 리스크 분석

완벽한 테스팅은 현실적으로 불가능하기 때문에 모든 기능을 같은 수준으로 테스트할 수 없다.
따라서 테스트 계획 단계에서는 리스크를 분석하여 어디에 더 많은 테스트 자원을 투입할 것인지 결정할 필요가 있다.

예를 들어, 결제 기능과 단순 색상 변경 기능이 있다면 서비스에 미치는 영향이 큰 결제 기능에 더 높은 테스트 우선순위를 부여할 수 있다.
이러한 접근을 Risk-based Testing이라고 한다.

1.3 테스트 제어(Test Control)

테스트 계획을 수립했다고 해서 실제 프로젝트가 항상 계획대로 진행되는 것은 아니다.
따라서 테스트가 진행되는 동안 현재 상태를 지속적으로 확인하고 계획과 실제 진행 상황을 비교해야 한다.

• 테스트 일정은 계획대로 진행되고 있는가?
• 개발 일정이 지연되고 있는가?
• 테스트 환경 준비가 늦어지고 있는가?
• 예상보다 많은 결함이 발생하고 있는가?
• 테스트에 필요한 인력이 부족하지 않은가?
• 주요 리스크가 변경되었는가?

계획과 실제 진행 상황에 차이가 있다면 원인을 확인하고, 필요에 따라 테스트 일정이나 범위, 우선순위, 인력, 테스트 환경 또는 접근 방법 등을 조정할 수 있다.

2. 테스트 분석과 설계

테스트 계획에서 전체적인 방향을 정했다면 분석과 설계 단계에서는 실제로 무엇을 테스트할 것인지와 어떻게 검증할 것인지를 구체화한다.

2.1 테스트 분석 (Test Analysis)

테스트 분석에서는 요구사항, 화면설계서, 정책서 등의 Test Basis를 확인하면서 무엇을 테스트해야 하는지 식별한다. 이때 식별한 테스트 대상이나 상황을 Test Condition이라고 한다.

ex. 로그인 기능의 Test Condition
Test Basis에 로그인 요구사항이 있다면 다음과 같은 Test Condition을 도출할 수 있다.

• 정상 계정으로 로그인
• 잘못된 비밀번호 입력
• 존재하지 않는 계정
• 필수 입력값 미입력
• 로그인 반복 실패

즉, 테스트 분석은 "이 기능에서 무엇을 확인해야 하지?" 를 찾아내는 과정이라고 이해하면 쉽다.

2.2 테스트 설계 (Test Design)

테스트 분석에서 식별한 Test Condition을 실제로 실행하고 결과를 판단할 수 있는 Test Case로 구체화한다.

Test Case에는 프로젝트에 따라 다음과 같은 내용이 포함될 수 있다.

• Test Case ID
• 테스트 목적
• 사전 조건(Precondition)
• 입력값 / Test Data
• 테스트 단계
• 예상 결과 (Expected Result)

테스트 케이스를 설계할 때는 필요한 경우 체계적인 테스트 설계 기법을 활용할 수 있다.

• 동등 분할(Equivalence Partitioning)
• 경계값 분석(Boundary Value Analysis)
• 결정 테이블 테스팅(Decision Table Testing)
• 상태 전이 테스팅(State Transition Testing)
• 유즈케이스 테스팅(Use Case Testing)
• 조합 테스팅(Pairwise 등)

🐝 Test Basis -분석-> Test Condition -설계-> Test Case

1. Test Basis 검토

   • 테스트 분석과 설계의 근거 자료
   • ex. 요구사항 명세서 / 화면설계서 / 정책서 / API 명세서 / 사용자 스토리

2. Test Condition

   • Test Basis를 분석해 식별한 테스트 대상이나 상황, 쉽게 말하면 테스트 아이디어
   • 동일한 Test Case만 반복하면 새로운 결함을 발견하기 어려울 수 있다.
   • 따라서 기존 Test Case와 테스트 관점을 지속적으로 검토하고, 필요한 경우 새로운 Test Condition이나 Test Case를 추가하는 것이 중요하다.
   • 이는 테스트의 7가지 원리 중 살충제 패러독스(Pesticide Paradox)와 연결해서 이해할 수 있다.
   • 테스트 아이디어를 도출할 때는 먼저 스스로 생각해보고, 동료와 리뷰한 뒤 필요하다면 AI 등을 활용하여 놓친 관점을 확장할 수도 있다.

3. Test Case

   • Test Condition을 실제로 실행하고 결과를 판단할 수 있도록 구체화한 것

2.3 Test Data 식별

테스트 분석과 설계 과정에서는 실제 테스트 수행에 어떤 Test Data가 필요한지도 식별한다. Test Data는 테스트를 수행하기 위해 필요한 값이나 상태 등의 정보를 의미한다.
필요한 Test Data가 준비되어 있지 않다면 개발자나 관련 담당자에게 요청하여 테스트 전에 준비할 수 있다.

3. 테스트 구현과 실행

3.1 테스트 구현 (Test Implementation)

테스트 설계가 끝났다면 실제 테스트를 실행할 수 있도록 필요한 요소를 준비한다.
대표적으로 다음과 같은 활동이 있다.

• Test Case 정리
• Test Suite 구성
• Test Data 준비
• 테스트 환경 준비 및 확인
• Test Procedure 작성
• 필요한 경우 자동화 Test Script 작성
• Test Case 실행 순서 구성
• 필요한 테스트 도구 준비

💡 Test Suite

특정 기능, 목적, 테스트 레벨 또는 실행 단위 등을 기준으로 여러 Test Case를 묶어 놓은 집합
예를 들어 로그인 관련 TC를 하나의 Login Test Suite로 묶을 수 있다.

💡 Test Procedure

Test Procedure는 하나 이상의 Test Case를 실행하기 위한 절차와 실행 순서를 정리한 것이다. 이때 각 Test Case의 선행조건과 데이터 상태를 고려하여 효율적인 실행 순서를 구성할 수 있다.

ex. 주소록 기능에 다음 Test Case가 있다고 가정한다.

1. 주소 등록
2. 등록한 주소 수정
3. 일부 주소 삭제
4. 전체 주소 삭제

전체 삭제를 먼저 실행하면 이후 수정이나 부분 삭제를 테스트하기 위해 다시 데이터를 생성해야 한다.
따라서 Test Case를 단순히 나열된 순서대로 실행하기보다 테스트를 효율적으로 수행할 수 있는 실행 순서를 고려할 수 있다.

3.2 테스트 실행(Test Execution)

준비된 Test Case, Test Procedure, Test Data와 테스트 환경을 이용하여 실제 테스트를 수행한다.

Test Case 실행
→ Expected Result와 Actual Result 비교
→ Pass / Fail / Blocked 등의 결과 기록

프로젝트나 테스트 관리 도구에 따라 다음과 같은 상태를 사용할 수 있다.

Pass / Fail / Blocked / Not Run

Fail = 무조건 Defect?

Test Case가 Fail했다고 해서 바로 소프트웨어 결함이라고 단정할 수는 없다.
먼저 다음과 같은 내용을 확인할 수 있다.

• 요구사항을 잘못 이해한 것은 아닌가?
• Test Case 자체가 잘못 작성된 것은 아닌가?
• Test Data가 잘못되었는가?
• 테스트 환경에 문제가 있는가?
• 실제 제품의 결함인가?

소프트웨어 결함으로 판단되면 조직의 결함 관리 프로세스에 따라 BTS 등에 등록한다.

3.3 결함 수정 후 확인

개발자가 결함을 수정하면 다시 테스트를 수행한다.

Confirmation Testing (Retesting)

기존에 실패했던 조건을 다시 실행하여 해당 결함이 실제로 수정되었는지 확인하는 테스트

Defect 발견 → 개발자 수정 → 동일한 조건으로 다시 테스트 → 수정 여부 확인

Regression Testing

변경이나 결함 수정으로 인해 기존에 정상 동작하던 기능에 의도하지 않은 영향이 발생하지 않았는지 확인하는 테스트

• Retest = 그 결함이 고쳐졌는가?
• Regression Test = 그 수정 때문에 다른 곳이 깨지지는 않았는가?

동일한 결함이 다시 발생하거나 수정이 충분하지 않다면 프로젝트의 결함 관리 기준에 따라 Reopen할 수 있다. 별개의 문제라면 새로운 Defect로 등록하는 것이 일반적이다.

3.4 탐색적 테스팅 (Exploratory Testing)

※ 탐색적 테스팅은 별도의 프로세스 단계라기보다 테스트 설계와 실행을 동시에 수행하는 접근 방식이다.

모든 가능한 테스트 상황을 사전에 Test Case로 작성하는 것은 현실적으로 불가능하다.

따라서 테스터가 제품을 사용하고 학습하면서 테스트 설계와 실행을 동시에 수행하는 탐색적 테스팅을 활용할 수 있다.

제품 탐색 → 이상 현상 발견 → 재현 → 증거 자료 확보 → Defect인지 확인 → 필요한 경우 BTS 등록

이상 현상은 일회성으로 발생할 수도 있기 때문에 발견 당시 다음과 같은 증거를 남겨두는 것이 좋다.

• Screenshot
• Screen Recording
• Log
• 테스트 환경
• 입력값
• 발생 시간

4. 완료 조건의 평가와 보고

테스트가 어느 정도 진행되었다고 해서 임의로 테스트를 종료하는 것은 아니다.
테스트 계획에서 정의한 Exit Criteria를 기준으로 테스트가 충분히 수행되었는지 평가한다.

ex. 다음과 같은 조건을 사용할 수 있다.

• 계획한 Test Case 수행 완료
• 주요 Test Case Pass
• 미해결 Critical 결함 0건 등 프로젝트에서 합의한 결함 기준 충족
• 목표한 요구사항/기능/코드 등 테스트 커버리지 기준 달성
• 주요 리스크에 대한 테스트 완료

완료 조건을 평가한 후 테스트 결과를 정리하여 프로젝트 이해관계자에게 보고한다.

보고 내용에는 다음과 같은 정보가 포함될 수 있다.

• 테스트 수행 현황
• Pass / Fail 결과
• 발견된 결함 수
• 미해결 결함
• 테스트하지 못한 영역
• 남아 있는 리스크
• 테스트 대상의 품질 상태

결과 보고서에서는 테스트 수행 결과와 주요 리스크를 요약하여 이해관계자가 현재 제품의 품질 상태를 빠르게 이해할 수 있도록 하는 것이 중요하다.
단순히 몇 개의 결함을 발견했는지를 보고하는 것이 아니라 현재 제품의 품질 상태와 남아 있는 리스크를 전달하여 배포 여부나 추가 테스트 필요성을 판단할 수 있도록 정보를 제공한다.

5. 테스트 마감 활동

프로젝트나 테스트 단계가 종료되면 테스트 과정에서 생성된 결과와 관련 산출물을 정리한다.
대표적인 활동은 다음과 같다.

• 테스트 결과 정리
• Test Case 및 Testware 보관
• 미해결 결함 정리
• 테스트 환경 정리
• 테스트 데이터 정리
• Lessons Learned 작성
• 향후 테스트에서 활용할 정보 기록

테스트 마감은 단순히 테스트를 끝내는 것이 아니라 이번 테스트에서 얻은 경험과 정보를 이후 프로젝트에서도 사용할 수 있도록 정리하는 과정이다.

5.1 Testware 정리

Testware는 테스트 활동에서 생성하거나 사용하는 테스트 관련 작업 산출물을 의미한다.

ex.

• Test Plan
• Test Case
• Test Data
• Test Condition
• Test Suite
• Test Procedure
• Test Script
• Test Log
• Defect Report
• Test Result / Test Report

Testware를 체계적으로 관리하면 이후 테스트에서 과거의 테스트 결과, 결함, 테스트 케이스 등의 히스토리를 재사용하거나 참고할 수 있다.

5.2 Lessons Learned

테스트가 종료된 후 이번 프로젝트를 통해 얻은 경험과 교훈을 정리한다. 크게 Product와 Project 관점으로 나누어 생각할 수 있다.

• Product 관점 - 제품에서 잘된 점 / 문제점 / 개선이 필요한 기능 / 결함이 집중된 영역 / 향후 추가 테스트가 필요한 영역
• Project 관점 - 일정 관리 / 커뮤니케이션 / 협업 방식 / 테스트 환경 / 테스트 프로세스 / 문서 관리

5.3 PMI

회고 방법 중 하나로 PMI를 활용할 수도 있다.

• Plus: 잘된 점
• Minus: 아쉬웠던 점 또는 개선할 점
• Interesting: 새롭게 알게 된 점이나 흥미로운 점

이러한 교훈을 기록하면 다음 테스트나 프로젝트에서 동일한 문제를 반복하지 않고 기존 경험을 활용할 수 있다.

현업에서의 테스트 프로세스

실제 프로젝트에서는 테스트 분석 → 테스트 설계 → 테스트 구현 활동이 항상 명확하게 분리되어 수행되는 것은 아니다.

프로젝트 규모나 일정에 따라 Test Basis를 검토하면서 바로 Test Case를 작성하거나, Test Case를 작성하면서 필요한 Test Data를 함께 식별하는 등 여러 활동이 동시에 진행될 수 있다.

중요한 것은 각 단계를 형식적으로 구분하는 것이 아니라,
무엇을 테스트할지 분석 → 어떻게 검증할지 설계 → 실행 가능하게 준비 → 실제 테스트 수행 → 결과와 리스크 평가 → 산출물과 경험 정리
이라는 각 활동의 목적을 이해하는 것이다.