SW 테스팅 기초: 테스트 프로세스의 5단계와 실무 적용법

SW 테스팅의 기초를 제대로 이해하려면 단순히 테스트 케이스를 작성하고 실행하는 활동만 보면 안 됩니다. 이 글에서는 ISTQB에서 다루는 테스트 프로세스의 흐름을 바탕으로, 기획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 단계가 실제 QA 업무에서 어떻게 연결되는지 설명합니다.

초보 QA 엔지니어, 개발자, PM이 이 글을 읽으면 테스트를 “언제, 무엇을, 어떻게, 왜” 수행해야 하는지 정리할 수 있습니다. 또한 테스트자동화나 품질보증 활동을 시작하기 전에 반드시 잡아야 할 기본 프로세스의 틀을 실무 관점에서 이해할 수 있습니다.

테스트 프로세스가 중요한 이유

많은 초보자는 테스팅을 “화면을 눌러보고 버그를 찾는 일” 정도로 생각합니다. 하지만 실제 품질보증 활동에서 테스트는 제품 개발의 일부이며, 요구사항 확인부터 결함 보고, 릴리스 판단까지 이어지는 체계적인 프로세스입니다.

테스트 프로세스가 중요한 이유는 다음과 같습니다.

• 테스트 범위를 명확히 정할 수 있다.
• 일정과 리소스를 현실적으로 관리할 수 있다.
• 중요한 기능부터 우선 검증할 수 있다.
• 결함을 단순 발견이 아니라 품질 개선 데이터로 활용할 수 있다.
• 릴리스 가능 여부를 근거 있게 판단할 수 있다.
• 테스트자동화 적용 대상을 선별할 수 있다.

특히 애자일, DevOps, CI/CD 환경에서는 테스트가 개발 마지막 단계에서 몰아서 수행되는 활동이 아닙니다. 요구사항이 작성되는 순간부터 테스트 관점이 개입되어야 하며, 기능 개발과 함께 반복적으로 수행되어야 합니다.

전체 테스트 프로세스 한눈에 보기

ISTQB 관점에서 테스트 프로세스는 일반적으로 여러 활동으로 구성됩니다. 실무에서는 조직이나 프로젝트 특성에 따라 명칭은 조금씩 달라질 수 있지만, 핵심 흐름은 크게 다음과 같이 정리할 수 있습니다.

1. 기획/제어 2. 분석/설계 3. 구현/실행 4. 완료/리포팅 5. 마감

이 단계들은 반드시 한 번씩만 순서대로 끝나는 선형 활동은 아닙니다. 실제 프로젝트에서는 요구사항 변경, 결함 수정, 일정 조정, 릴리스 전략 변경에 따라 여러 단계가 반복됩니다.

예를 들어 분석/설계 단계에서 테스트 조건을 도출했는데 요구사항이 모호하다면 다시 기획 단계로 돌아가 범위나 우선순위를 조정해야 합니다. 구현/실행 중 치명적인 결함이 발견되면 리포팅 이후 추가 테스트 설계가 필요할 수 있습니다.

즉, 테스트 프로세스는 문서상 절차가 아니라 품질을 통제하기 위한 반복적인 의사결정 구조라고 보는 것이 실무에 더 가깝습니다.

1단계: 기획/제어 — 무엇을 어디까지 테스트할 것인가

기획/제어 단계는 테스트 프로세스의 출발점입니다. 이 단계에서는 테스트의 목적, 범위, 일정, 인력, 환경, 위험 요소, 완료 기준을 정합니다.

초보자가 가장 많이 놓치는 부분은 “테스트를 많이 하면 품질이 좋아진다”는 생각입니다. 하지만 현실에서는 시간과 인력이 제한되어 있기 때문에 모든 것을 동일한 깊이로 검증할 수 없습니다. 그래서 기획 단계에서는 리스크 기반 접근이 중요합니다.

예를 들어 결제, 로그인, 회원가입, 개인정보 처리, 데이터 삭제 기능은 장애 발생 시 비즈니스 영향이 큽니다. 반면 단순 문구 표시나 낮은 사용 빈도의 설정 화면은 상대적으로 우선순위가 낮을 수 있습니다. 따라서 테스트 기획에서는 기능의 중요도와 실패 시 영향을 함께 고려해야 합니다.

실무에서 기획/제어 단계에 확인할 내용은 다음과 같습니다.

• 테스트 대상 기능은 무엇인가?
• 테스트에서 제외할 범위는 무엇인가?
• 테스트 환경은 운영 환경과 얼마나 유사한가?
• 테스트 데이터는 어떻게 준비할 것인가?
• 어떤 결함을 릴리스 차단 이슈로 볼 것인가?
• 테스트 완료 기준은 무엇인가?
• 회귀 테스트 범위는 어디까지인가?
• 테스트자동화 적용 가능 영역은 어디인가?

제어 활동은 기획 후에도 계속됩니다. 테스트 진행률, 결함 추이, 일정 지연, 환경 장애 등을 모니터링하고 필요하면 계획을 수정해야 합니다. QA 실무에서는 계획을 세우는 능력만큼이나 계획을 조정하는 능력이 중요합니다.

2단계: 분석/설계 — 테스트할 조건을 찾아내는 과정

분석/설계 단계에서는 요구사항, 사용자 스토리, 화면 설계서, API 명세서, 정책 문서 등을 검토하여 테스트할 조건을 도출합니다. 이 단계의 핵심은 단순히 문서를 읽는 것이 아니라 “이 기능이 어떤 조건에서 실패할 수 있는가”를 생각하는 것입니다.

예를 들어 회원가입 기능을 테스트한다고 가정해 보겠습니다. 단순히 정상 가입만 확인하면 충분하지 않습니다. 이메일 형식, 중복 계정, 비밀번호 정책, 약관 동의, 인증번호 만료, 네트워크 오류, 다국어 입력, 특수문자 처리 등 다양한 조건을 고려해야 합니다.

분석/설계 단계에서 자주 사용하는 질문은 다음과 같습니다.

• 정상 흐름은 무엇인가?
• 예외 흐름은 무엇인가?
• 입력값의 경계는 어디인가?
• 사용자 권한에 따라 결과가 달라지는가?
• 기존 데이터와 충돌할 가능성이 있는가?
• 외부 시스템 연동 실패 시 어떻게 동작해야 하는가?
• 보안이나 개인정보 관점에서 위험한 부분은 없는가?

이 단계에서 테스트 조건을 잘 도출하면 이후 테스트 케이스 작성과 실행 품질이 크게 좋아집니다. 반대로 분석이 부족하면 테스트 케이스는 많지만 중요한 결함을 놓치는 상황이 발생합니다.

테스팅에서 “많이 실행했다”보다 중요한 것은 “중요한 위험을 검증했는가”입니다. 분석/설계 단계는 바로 그 위험을 찾아내는 작업입니다.

3단계: 구현/실행 — 테스트 케이스를 만들고 검증하는 단계

구현/실행 단계에서는 분석/설계 결과를 바탕으로 테스트 케이스, 테스트 절차, 테스트 데이터, 자동화 스크립트 등을 준비하고 실제로 테스트를 수행합니다.

테스트 케이스는 일반적으로 다음 요소를 포함합니다.

• 테스트 ID
• 테스트 목적
• 사전 조건
• 입력 데이터
• 수행 절차
• 기대 결과
• 실제 결과
• 테스트 상태
• 결함 ID

초보 QA가 자주 실수하는 부분은 기대 결과를 모호하게 작성하는 것입니다. 예를 들어 “정상적으로 동작해야 한다”는 좋은 기대 결과가 아닙니다. “비밀번호가 8자 미만이면 ‘비밀번호는 8자 이상 입력해야 합니다’ 메시지가 표시되고 가입 요청은 서버로 전송되지 않는다”처럼 관찰 가능한 결과로 작성해야 합니다.

실행 단계에서는 결함 보고 품질도 중요합니다. 결함 리포트에는 재현 절차, 발생 환경, 기대 결과, 실제 결과, 스크린샷 또는 로그, 발생 빈도, 영향도를 포함하는 것이 좋습니다. 좋은 결함 보고는 개발자가 빠르게 원인을 파악하고 수정할 수 있게 도와줍니다.

테스트자동화도 이 단계와 밀접하게 연결됩니다. 다만 모든 테스트를 자동화해야 하는 것은 아닙니다. 반복 실행이 많고 결과가 명확하며 변경 빈도가 낮은 영역부터 자동화하는 것이 효과적입니다. 반면 UI가 자주 바뀌거나 탐색적 판단이 필요한 영역은 수동 테스트가 더 효율적일 수 있습니다.

4단계: 완료/리포팅 — 품질 상태를 의사결정 가능한 정보로 바꾸기

테스트 완료/리포팅 단계는 단순히 “테스트가 끝났다”고 알리는 단계가 아닙니다. 테스트 결과를 정리하여 제품 출시, 추가 수정, 일정 조정 같은 의사결정에 사용할 수 있는 정보로 만드는 과정입니다.

좋은 테스트 리포트는 다음 질문에 답할 수 있어야 합니다.

• 계획한 테스트 중 얼마나 수행했는가?
• 통과, 실패, 보류된 테스트는 각각 몇 개인가?
• 주요 결함은 무엇이며 현재 상태는 어떤가?
• 미해결 결함 중 릴리스에 영향을 주는 항목은 무엇인가?
• 테스트 범위에서 제외된 부분은 무엇인가?
• 테스트 환경이나 데이터 제약은 없었는가?
• 현재 품질 수준으로 릴리스 가능한가?

QA 실무에서 리포팅은 매우 중요합니다. 테스트를 열심히 수행했더라도 결과가 정리되지 않으면 조직은 품질 상태를 정확히 알 수 없습니다. 특히 경영진, PO, PM, 개발 리더는 모든 테스트 케이스를 직접 보지 않습니다. 따라서 QA는 테스트 결과를 핵심 지표와 리스크 중심으로 요약해야 합니다.

예를 들어 “테스트 120건 중 110건 통과”라는 정보만으로는 부족합니다. 10건의 실패 중 결제 실패 1건이 포함되어 있다면 릴리스 판단은 달라집니다. 수량뿐 아니라 결함의 심각도와 비즈니스 영향을 함께 설명해야 합니다.

5단계: 마감 — 다음 프로젝트를 위한 학습과 개선

마감 단계는 테스트 활동을 공식적으로 종료하고 산출물을 정리하는 단계입니다. 많은 조직에서 이 단계를 생략하거나 형식적으로 처리하지만, 장기적으로 품질보증 역량을 높이려면 매우 중요합니다.

마감 단계에서는 다음을 정리합니다.

• 최종 테스트 결과
• 해결된 결함과 미해결 결함
• 릴리스 후 모니터링이 필요한 위험
• 테스트 케이스와 테스트 데이터
• 자동화 스크립트 유지보수 사항
• 테스트 환경 이슈
• 일정 지연 원인
• 개선이 필요한 프로세스

특히 회고가 중요합니다. 이번 프로젝트에서 요구사항 변경이 잦아 테스트 설계가 흔들렸는지, 테스트 환경 준비가 늦어 실행이 지연되었는지, 결함 보고 형식이 불명확했는지 등을 살펴봐야 합니다.

마감 단계의 목적은 책임 추궁이 아니라 학습입니다. 잘된 점은 표준화하고, 반복된 문제는 프로세스 개선 항목으로 남겨야 합니다. 이런 축적이 있어야 다음 릴리스에서 더 빠르고 안정적인 테스팅이 가능합니다.

실전 적용 방법: 작은 프로젝트에 테스트 프로세스 적용하기

테스트 프로세스는 대기업이나 대형 프로젝트에만 필요한 것이 아닙니다. 작은 웹서비스, 앱 업데이트, 사내 관리자 페이지 개발에도 충분히 적용할 수 있습니다. 중요한 것은 문서를 많이 만드는 것이 아니라 필요한 의사결정을 빠뜨리지 않는 것입니다.

예를 들어 2주짜리 기능 개발 프로젝트라면 다음과 같이 적용할 수 있습니다.

1. 기획/제어

• 핵심 기능 3~5개를 선정합니다.
• 장애 시 영향이 큰 기능을 우선순위로 둡니다.
• 테스트 완료 기준을 정합니다. 예: 치명도 높은 결함 0건, 주요 시나리오 통과.

2. 분석/설계

• 사용자 스토리별 정상 흐름과 예외 흐름을 도출합니다.
• API, DB, 권한, 입력값 조건을 확인합니다.
• 테스트 케이스를 너무 세분화하기보다 리스크 중심으로 작성합니다.

3. 구현/실행

• 스모크 테스트, 기능 테스트, 회귀 테스트를 구분합니다.
• 반복 확인이 필요한 로그인, 결제, 검색 등은 자동화 후보로 표시합니다.
• 결함은 재현 가능한 형태로 보고합니다.

4. 완료/리포팅

• 통과율보다 주요 리스크와 미해결 결함을 강조합니다.
• 릴리스 가능 여부를 QA 의견으로 제시합니다.
• 테스트하지 못한 범위를 명확히 알립니다.

5. 마감

• 다음 배포에 재사용할 테스트 케이스를 정리합니다.
• 자동화할 후보를 백로그에 등록합니다.
• 반복된 결함 유형을 팀과 공유합니다.

이렇게 하면 작은 프로젝트에서도 테스트가 단순 확인 작업이 아니라 품질을 관리하는 활동으로 자리 잡을 수 있습니다.

바로 활용할 수 있는 테스트 프로세스 체크리스트

아래 체크리스트는 초보 QA가 프로젝트에 투입되었을 때 바로 사용할 수 있는 기본 항목입니다. 모든 항목을 완벽히 충족해야 하는 것은 아니지만, 체크하지 않은 항목이 많을수록 테스트 리스크가 커질 수 있습니다.

• [ ] 테스트 대상 기능과 제외 범위가 명확한가?
• [ ] 요구사항 또는 사용자 스토리를 QA 관점에서 검토했는가?
• [ ] 비즈니스 영향도가 큰 기능을 우선순위로 정했는가?
• [ ] 정상 흐름뿐 아니라 예외 흐름을 도출했는가?
• [ ] 테스트 데이터와 계정이 준비되어 있는가?
• [ ] 테스트 환경이 운영 환경과 얼마나 다른지 알고 있는가?
• [ ] 기대 결과가 관찰 가능한 형태로 작성되어 있는가?
• [ ] 결함 보고 양식이 팀 내에서 합의되어 있는가?
• [ ] 회귀 테스트 범위가 정해져 있는가?
• [ ] 테스트자동화 후보를 구분했는가?
• [ ] 테스트 완료 기준이 정의되어 있는가?
• [ ] 미해결 결함의 릴리스 영향도를 정리했는가?
• [ ] 테스트 종료 후 회고와 산출물 정리를 수행했는가?

이 체크리스트는 특히 신규 QA, 1인 QA, 스타트업 QA에게 유용합니다. 처음부터 거창한 테스트 전략 문서를 만들기 어렵다면, 이 항목들을 기준으로 최소한의 테스트 프로세스를 운영해도 품질 리스크를 상당히 줄일 수 있습니다.

테스트자동화는 어느 단계에서 고려해야 할까

테스트자동화는 구현/실행 단계에서만 생각하는 활동이 아닙니다. 자동화가 효과를 내려면 기획 단계부터 어떤 테스트를 반복 실행할지, 어떤 환경에서 수행할지, 어떤 기준으로 성공과 실패를 판단할지 정해야 합니다.

자동화에 적합한 테스트는 보통 다음과 같습니다.

• 매 배포마다 반복 수행되는 스모크 테스트
• 로그인, 회원가입, 결제 등 핵심 사용자 흐름
• API 응답 검증처럼 결과가 명확한 테스트
• 다양한 입력값을 반복 검증해야 하는 테스트
• 회귀 결함이 자주 발생하는 기능

반대로 자동화가 비효율적인 경우도 있습니다.

• 화면 구조가 자주 바뀌는 초기 개발 단계
• 사람의 시각적 판단이 중요한 UI/UX 검증
• 한두 번만 실행하면 되는 일회성 테스트
• 기대 결과가 자주 바뀌는 기능
• 테스트 데이터 준비가 지나치게 복잡한 시나리오

초보자는 “자동화 = 좋은 QA”라고 생각하기 쉽지만, 자동화는 목적이 아니라 수단입니다. 잘못 설계된 자동화는 오히려 유지보수 비용만 늘립니다. 따라서 테스트 프로세스의 기초를 이해한 뒤, 반복성과 안정성이 높은 영역부터 자동화하는 것이 바람직합니다.

주의할 점: 초보자가 자주 하는 테스트 프로세스 실수

테스트 프로세스를 처음 적용할 때는 몇 가지 흔한 실수가 있습니다. 이 실수들은 테스트 품질을 떨어뜨리고, QA에 대한 신뢰도에도 영향을 줄 수 있습니다.

첫째, 요구사항을 충분히 이해하지 않고 테스트 케이스부터 작성하는 것입니다. 요구사항이 모호하면 테스트 케이스도 모호해집니다. 반드시 기획자, 개발자와 질문을 주고받으며 기대 동작을 명확히 해야 합니다.

둘째, 정상 케이스에만 집중하는 것입니다. 실제 결함은 예외 상황에서 많이 발생합니다. 입력값 누락, 권한 부족, 네트워크 실패, 중복 요청, 경계값, 데이터 불일치 같은 상황을 반드시 고려해야 합니다.

셋째, 테스트 결과를 숫자로만 보고하는 것입니다. “90% 통과”보다 중요한 것은 실패한 10%가 무엇인지입니다. 치명적인 결함 1건은 사소한 결함 20건보다 릴리스에 더 큰 영향을 줄 수 있습니다.

넷째, 테스트 마감을 하지 않는 것입니다. 테스트가 끝난 뒤 산출물을 정리하지 않으면 다음 프로젝트에서 같은 실수를 반복하게 됩니다. 회고와 정리는 테스트 프로세스의 마지막이 아니라 다음 품질 개선의 시작입니다.

다섯째, 테스트자동화를 무리하게 도입하는 것입니다. 자동화 대상 선정 없이 UI 테스트를 대량으로 만들면 작은 화면 변경에도 스크립트가 계속 깨질 수 있습니다. 자동화는 안정적인 기능과 반복성이 높은 시나리오부터 시작해야 합니다.

품질보증 관점에서 테스트 프로세스를 바라보는 법

테스팅은 품질보증의 일부입니다. 테스트가 결함을 찾는 활동이라면, 품질보증은 결함이 덜 발생하도록 프로세스와 문화를 개선하는 활동까지 포함합니다.

예를 들어 테스트 중 특정 유형의 결함이 반복적으로 발견된다면 QA는 단순히 버그를 등록하는 데서 멈추지 않아야 합니다. 요구사항 작성 방식에 문제가 있는지, 코드 리뷰에서 놓치는 부분이 있는지, 개발 완료 기준이 부족한지, 테스트 환경이 불안정한지 살펴봐야 합니다.

품질보증 관점에서는 다음과 같은 질문이 중요합니다.

• 왜 이 결함이 개발 단계에서 발견되지 않았는가?
• 비슷한 결함이 반복되는 이유는 무엇인가?
• 요구사항 단계에서 예방할 수 있었는가?
• 자동화 테스트로 조기에 탐지할 수 있는가?
• 팀의 Definition of Done에 추가할 기준은 없는가?

이처럼 테스트 프로세스는 단순히 QA팀만의 절차가 아닙니다. 개발팀, 기획팀, 운영팀이 함께 품질을 관리하기 위한 공통 언어입니다. 테스트 프로세스의 기초를 팀 전체가 이해하면 결함 수정 속도뿐 아니라 제품 신뢰도도 높아집니다.

자주 묻는 질문

Q1. 테스트 프로세스는 반드시 순서대로 진행해야 하나요?

항상 고정된 순서로만 진행되지는 않습니다. 기본 흐름은 기획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 순서이지만 실제 프로젝트에서는 반복과 되돌림이 자주 발생합니다. 예를 들어 테스트 실행 중 요구사항 누락이 발견되면 다시 분석/설계 단계로 돌아가야 합니다. 중요한 것은 순서를 기계적으로 지키는 것이 아니라 각 단계에서 필요한 의사결정을 빠뜨리지 않는 것입니다.

Q2. 초보 QA는 테스트 케이스를 얼마나 자세히 작성해야 하나요?

처음에는 다소 자세히 작성하는 것이 좋습니다. 테스트 목적, 사전 조건, 입력값, 수행 절차, 기대 결과를 명확히 적어야 다른 사람이 실행해도 같은 결과를 확인할 수 있습니다. 다만 모든 테스트를 지나치게 세분화하면 유지보수가 어려워질 수 있으므로, 핵심 기능과 리스크가 큰 영역은 상세히 작성하고 단순 확인 항목은 체크리스트 형태로 관리하는 방식이 효율적입니다.

Q3. 테스트자동화는 언제 시작하는 것이 좋나요?

기능이 어느 정도 안정되고 반복 테스트의 필요성이 명확할 때 시작하는 것이 좋습니다. 개발 초기처럼 UI와 요구사항이 자주 바뀌는 시점에 자동화를 무리하게 도입하면 유지보수 비용이 커질 수 있습니다. 먼저 스모크 테스트, API 테스트, 핵심 회귀 테스트처럼 결과가 명확하고 반복 실행 가치가 높은 영역부터 자동화하는 것을 추천합니다.

Q4. 테스트 완료 기준은 어떻게 정해야 하나요?

테스트 완료 기준은 프로젝트 상황에 따라 다르지만, 일반적으로 주요 테스트 케이스 실행 완료, 치명도 높은 결함 해결, 핵심 시나리오 통과, 미해결 결함의 영향도 검토, 테스트 리포트 승인 등을 포함합니다. “시간이 다 됐으니 종료”가 아니라 “어떤 리스크를 감수하고 종료하는지”를 명확히 해야 합니다.

Q5. QA가 테스트 프로세스를 제안하면 개발 속도가 느려지지 않나요?

초기에는 회의나 문서 작업이 늘어난 것처럼 보일 수 있습니다. 하지만 테스트 프로세스가 자리 잡으면 요구사항 누락, 재작업, 릴리스 직전 긴급 수정이 줄어들어 전체 개발 속도는 오히려 안정됩니다. 특히 반복 결함이 많은 팀일수록 테스트 프로세스 정비의 효과가 큽니다.

테스트 프로세스 기초를 실무 역량으로 연결하기

테스트 프로세스의 기초를 안다는 것은 단순히 용어를 외우는 것이 아닙니다. 실제 프로젝트에서 테스트 범위를 정하고, 위험을 분석하고, 테스트 케이스를 설계하고, 결함을 보고하고, 품질 상태를 설명할 수 있어야 합니다.

초보 QA라면 처음부터 완벽한 프로세스를 만들려고 하기보다 작은 단위로 시작하는 것이 좋습니다. 예를 들어 다음 배포부터 테스트 완료 기준을 명확히 정하거나, 결함 보고 양식을 통일하거나, 회귀 테스트 체크리스트를 만드는 방식입니다.

작은 개선이 반복되면 QA 활동은 단순 검수에서 품질보증으로 확장됩니다. 그리고 이 과정에서 테스트자동화, 리스크 기반 테스팅, CI/CD 품질 게이트 같은 고급 주제도 자연스럽게 연결됩니다.

항목	정리
핵심 개념	테스트 프로세스는 기획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감으로 이어지는 품질 관리 흐름입니다.
왜 중요한가	제한된 시간과 인력 안에서 중요한 리스크를 우선 검증하고 릴리스 판단 근거를 제공합니다.
실무 적용	작은 프로젝트라도 범위, 우선순위, 완료 기준, 결함 보고 방식은 반드시 정하는 것이 좋습니다.
테스트자동화	반복성이 높고 결과가 명확한 영역부터 적용해야 하며, 자동화 자체가 목적이 되어서는 안 됩니다.
주의할 점	정상 케이스만 보거나, 리포트를 숫자로만 정리하거나, 마감 회고를 생략하면 품질 개선으로 이어지기 어렵습니다.
초보자 첫걸음	체크리스트 기반으로 테스트 범위와 기대 결과를 명확히 하고, 결함을 재현 가능한 형태로 보고하는 습관부터 시작하세요.