qa-note

테스트 조건(Test Condition)이란 무엇인가? QA 테스트 설계의 핵심 개념 정리

qa-note — Fri, 22 May 2026 10:00:49 +0900

테스트 조건(Test Condition)이란 무엇인가?

소프트웨어 테스트를 공부하다 보면 테스트 조건(Test Condition) 이라는 용어를 자주 보게 됩니다.
처음 보면 조금 어려워 보일 수 있지만, 개념 자체는 생각보다 단순합니다.

간단하게 정리하면 다음과 같습니다.

테스트해야 할 대상이나 항목을 정의한 것

즉, 테스트를 진행하기 전에

무엇을 테스트해야 하는지
어떤 부분을 확인해야 하는지

를 정리해 둔 것이 테스트 조건(Test Condition) 입니다.

테스트 조건을 쉽게 이해해보기

예를 들어 로그인 기능을 테스트한다고 가정해보겠습니다.

로그인 기능에서 확인해야 할 것들은 여러 가지가 있습니다.

예시

아이디 입력 기능
비밀번호 입력 기능
로그인 버튼 동작
로그인 성공 여부
로그인 실패 메시지

이처럼 테스트해야 할 항목들을 정리한 것이 바로 테스트 조건입니다.

즉,

로그인 기능 → 테스트 조건 예시

아이디 입력 가능 여부
비밀번호 입력 가능 여부
로그인 성공 처리
로그인 실패 처리

이런 식으로 테스트해야 할 포인트를 정의하는 단계라고 이해하면 됩니다.

테스트 조건은 왜 중요한가?

테스트 조건을 정리하는 이유는 테스트 범위를 명확하게 하기 위해서입니다.

테스트 조건이 없으면

테스트 범위가 애매해지고
테스트 누락이 발생할 수 있으며
테스트 설계가 체계적으로 진행되기 어렵습니다.

그래서 보통 테스트를 설계할 때는

1️⃣ 테스트 조건 정의
2️⃣ 테스트 케이스 작성
3️⃣ 테스트 수행

이런 흐름으로 진행되는 경우가 많습니다.

테스트 조건과 테스트 케이스의 차이

테스트를 공부하다 보면 테스트 조건과 테스트 케이스를 헷갈리는 경우가 많습니다.

간단히 정리하면 다음과 같습니다.

테스트 조건

무엇을 테스트할 것인가

테스트 케이스

어떻게 테스트할 것인가

예시를 보면 더 쉽게 이해할 수 있습니다.

테스트 조건

로그인 성공 여부 확인

테스트 케이스

아이디: test123 입력
비밀번호: 1234 입력
로그인 버튼 클릭
로그인 성공 화면 확인

이처럼 테스트 조건은 큰 테스트 항목이고
테스트 케이스는 실제 테스트 절차라고 볼 수 있습니다.

테스트 조건은 어디에서 도출할까?

테스트 조건은 보통 테스트 베이시스(Test Basis) 를 기반으로 도출합니다.

테스트 베이시스란 테스트 설계를 위한 기준 자료를 의미합니다.

예시

요구사항 명세서
기획서
기능 명세
사용자 스토리
설계 문서

이러한 문서를 기반으로

어떤 기능을 테스트해야 하는지
어떤 상황을 확인해야 하는지

를 정리하면서 테스트 조건을 만들게 됩니다.

실무에서 느낀 테스트 조건의 의미

실무에서는 "테스트 조건"이라는 용어를 항상 명확하게 사용하지는 않는 경우도 있습니다.
하지만 실제 테스트를 설계하다 보면 자연스럽게 이 개념을 사용하게 됩니다.

예를 들어

어떤 기능을 테스트해야 하는지 정리하거나
테스트 범위를 정하거나
테스트 시나리오를 만들 때

결국 테스트해야 할 항목을 먼저 정리하게 되는데,
이 과정이 바로 테스트 조건을 정의하는 과정이라고 볼 수 있습니다.

그래서 테스트 조건은 테스트 설계의 출발점이라고도 할 수 있습니다.

정리

테스트 조건(Test Condition)을 간단히 정리하면 다음과 같습니다.

테스트해야 할 항목이나 기능을 정의한 것
테스트 설계 단계에서 먼저 정리되는 개념
테스트 케이스 작성을 위한 기준이 되는 요소

즉,

무엇을 테스트할 것인지 정의하는 단계

라고 이해하면 가장 쉽게 기억할 수 있습니다.

테스트 전략(Test Strategy) vs 테스트 계획(Test Plan) 차이 정리 (QA 이론 쉽게 이해하기)

qa-note — Wed, 20 May 2026 10:00:53 +0900

테스트 전략(Test Strategy) vs 테스트 계획(Test Plan)

소프트웨어 테스트 관련 문서를 보다 보면 테스트 전략(Test Strategy) 과 테스트 계획(Test Plan) 이라는 용어를 자주 보게 됩니다.

두 용어는 비슷하게 들리지만 실제로는 역할과 목적이 서로 다른 문서입니다.

처음에는 두 개념이 헷갈릴 수 있기 때문에 이 글에서는 QA 관점에서 이해하기 쉽게 정리해보려고 합니다.

먼저 간단하게 정리하면

두 개념의 차이는 다음과 같이 이해하면 편합니다.

✔ 테스트 전략(Test Strategy)
→ 테스트를 어떤 방향과 원칙으로 진행할 것인지에 대한 큰 틀

✔ 테스트 계획(Test Plan)
→ 실제 프로젝트에서 테스트를 어떻게 수행할 것인지에 대한 구체적인 계획

즉,

전략 = 방향
계획 = 실행 방법

이렇게 생각하면 이해하기 쉽습니다.

테스트 전략(Test Strategy)이란?

테스트 전략은 테스트를 수행할 때의 전체적인 접근 방식과 원칙을 정의하는 문서입니다.

조금 더 쉽게 말하면

테스트를 어떤 방식으로 진행할 것인지에 대한 기준을 정하는 것입니다.

보통 테스트 전략에는 다음과 같은 내용이 포함됩니다.

테스트 접근 방식
테스트 범위
테스트 레벨
테스트 유형
테스트 환경
테스트 도구 사용 여부
리스크 관리 방식

이 문서는 보통 조직이나 프로젝트에서 테스트를 어떤 방식으로 수행할지에 대한 큰 방향을 정할 때 사용됩니다.

예를 들어

어떤 테스트 기법을 사용할지
자동화 테스트를 적용할지
어떤 환경에서 테스트할지

같은 큰 틀의 기준을 정하는 문서라고 볼 수 있습니다.

테스트 계획(Test Plan)이란?

테스트 계획은 실제 프로젝트에서 테스트를 어떻게 수행할지 구체적으로 정리한 문서입니다.

즉,

전략이 정해져 있다면
그 전략을 기반으로 실제 테스트를 어떻게 진행할지 계획을 세우는 것입니다.

테스트 계획에는 보통 다음과 같은 내용이 포함됩니다.

테스트 범위
테스트 일정
테스트 대상 기능
테스트 담당자
테스트 환경
테스트 결과 보고 방식

쉽게 말하면 실제 테스트 실행을 위한 계획 문서라고 볼 수 있습니다.

예시로 이해해보기

예를 들어 하나의 웹 서비스를 테스트한다고 가정해보겠습니다.

테스트 전략

웹 서비스는 기능 테스트 중심으로 진행한다
핵심 기능은 회귀 테스트를 수행한다
API 테스트 도구를 활용한다
일부 기능은 자동화 테스트를 적용한다

이런 내용은 테스트 전략에 해당합니다.

테스트 계획

같은 프로젝트에서 실제 테스트를 진행할 때는

테스트 기간: 3월 1일 ~ 3월 10일
테스트 대상: 회원가입, 로그인, 결제 기능
테스트 담당자: QA 2명
테스트 환경: Stage 환경

이처럼 구체적인 실행 계획을 작성하게 됩니다.

이런 내용이 바로 테스트 계획(Test Plan) 입니다.

테스트 전략 vs 테스트 계획 차이 정리

정리하면 두 문서의 차이는 다음과 같습니다.

테스트 전략(Test Strategy)

테스트의 전체 방향을 정의
테스트 접근 방식 결정
조직 또는 프로젝트 기준 문서
비교적 상위 개념

테스트 계획(Test Plan)

실제 테스트 수행 계획
일정, 범위, 담당자 정의
프로젝트 단위 문서
실행 중심 문서

즉,

전략은 방향을 정하고
계획은 실제 실행을 준비하는 것이라고 볼 수 있습니다.

개인적으로 정리한 개념

테스트 관련 문서를 공부하다 보면 여러 용어가 등장해서 처음에는 조금 헷갈릴 수 있습니다.

개인적으로는 두 개념을 이렇게 이해하고 있습니다.

Test Strategy
테스트를 어떤 방식으로 진행할지 정하는 큰 틀

Test Plan
실제 프로젝트에서 테스트를 어떻게 진행할지 정리한 실행 계획

실무에서는 회사나 프로젝트마다 문서 형태가 조금씩 다르기도 하기 때문에 이 두 개념이 하나의 문서로 합쳐지는 경우도 있습니다.

그래서 중요한 것은 문서 이름보다는 테스트를 어떤 방식으로 준비하고 관리하는지 이해하는 것이라고 생각합니다.

테스트 커버리지(Test Coverage)란 무엇인가? QA에서 중요한 이유 쉽게 정리

qa-note — Mon, 18 May 2026 10:00:08 +0900

테스트 커버리지(Test Coverage)란 무엇인가?

소프트웨어 테스트를 진행하다 보면 이런 고민을 하게 됩니다.

테스트를 충분히 했을까?
혹시 놓친 기능이 있는 건 아닐까?
테스트 범위가 충분한 걸까?

이때 중요한 개념이 바로 테스트 커버리지(Test Coverage) 입니다.

테스트 커버리지는 간단하게 말하면

테스트가 얼마나 많은 범위를 확인했는지를 나타내는 지표입니다.

즉,

전체 기능 중에서
테스트가 어느 정도까지 수행되었는지

를 확인하기 위한 개념입니다.

테스트 커버리지 예시

예를 들어 간단한 회원가입 기능이 있다고 가정해보겠습니다.

회원가입 기능에는 다음과 같은 요소가 있을 수 있습니다.

아이디 입력
비밀번호 입력
이메일 입력
회원가입 버튼
회원가입 성공 처리

이 기능들에 대해 테스트를 진행했다고 해보겠습니다.

테스트 항목

정상 회원가입 테스트
비밀번호 오류 테스트
이메일 형식 오류 테스트

만약 이 테스트만 수행했다면 회원가입 기능의 일부만 테스트한 것입니다.

예를 들어

아이디 중복 체크
필수값 미입력
입력 길이 제한

이런 부분은 아직 테스트하지 않았을 수도 있습니다.

이처럼 전체 테스트 대상 중 어느 정도까지 테스트가 진행되었는지를 확인하는 것이 테스트 커버리지입니다.

왜 테스트 커버리지가 중요한가

테스트를 진행할 때 단순히 많이 테스트하는 것이 중요한 것이 아니라
어떤 범위를 테스트했는지가 중요합니다.

테스트 커버리지를 확인하면 다음과 같은 장점이 있습니다.

✔ 테스트 누락을 줄일 수 있습니다
✔ 테스트 범위를 명확하게 관리할 수 있습니다
✔ 릴리즈 전에 테스트 상태를 판단할 수 있습니다
✔ 테스트 품질을 객관적으로 확인할 수 있습니다

특히 프로젝트 규모가 커질수록 테스트 범위 관리가 중요해지기 때문에 테스트 커버리지 개념이 많이 사용됩니다.

테스트 커버리지의 종류

테스트 커버리지는 여러 기준으로 측정할 수 있습니다.

대표적인 예는 다음과 같습니다.

기능 커버리지 (Feature Coverage)

전체 기능 중에서 얼마나 많은 기능을 테스트했는지를 의미합니다.

예시

전체 기능 20개
테스트 수행 기능 15개

이 경우 기능 커버리지는 75%가 됩니다.

요구사항 커버리지 (Requirement Coverage)

프로젝트 요구사항 중 테스트가 수행된 요구사항 비율을 의미합니다.

예를 들어

요구사항 50개
테스트 케이스로 검증된 요구사항 40개

이 경우 요구사항 커버리지는 80%입니다.

코드 커버리지 (Code Coverage)

코드 기준으로 테스트 범위를 측정하는 방식입니다.

예를 들어

코드의 실행된 라인
조건 분기 실행 여부

등을 기준으로 측정합니다.

이 방식은 주로 개발 단계 테스트나 자동화 테스트에서 많이 사용됩니다.

QA 관점에서의 테스트 커버리지

QA 업무에서는 보통 요구사항 기반 커버리지나 기능 기반 커버리지를 많이 사용합니다.

예를 들어

기능 목록 기준 테스트 진행
테스트 케이스 기준 테스트 진행
요구사항 기준 테스트 진행

이런 방식으로 테스트 범위를 관리하는 경우가 많습니다.

특히 테스트 케이스를 작성할 때
어떤 기능을 검증하는 테스트인지 명확하게 작성하면 커버리지 관리에 도움이 됩니다.

테스트 커버리지가 높다고 항상 좋은 것은 아니다

테스트 커버리지가 높다고 해서
반드시 테스트 품질이 좋은 것은 아닙니다.

예를 들어

테스트 케이스 수는 많지만
중요한 시나리오가 빠져 있다면

커버리지는 높아 보일 수 있지만 실제 테스트 품질은 낮을 수 있습니다.

그래서 테스트 커버리지는 참고 지표로 활용하는 것이 중요합니다.

개인적으로 정리한 테스트 커버리지 개념

테스트 커버리지를 간단히 정리하면 다음과 같습니다.

테스트가 전체 대상 중 얼마나 많은 범위를 확인했는지를 나타내는 지표

테스트를 진행할 때

기능 누락은 없는지
요구사항이 모두 검증되었는지

이런 부분을 확인하는 데 도움이 되는 개념입니다.

실제 QA 업무에서도
테스트 범위를 관리할 때 이 개념을 기준으로 생각해보면 도움이 됩니다.

리스크 기반 테스트(Risk-Based Testing)란 무엇인가? QA 테스트 우선순위 정하는 방법

qa-note — Fri, 15 May 2026 10:00:51 +0900

리스크 기반 테스트(Risk-Based Testing)란 무엇인가?

소프트웨어 테스트를 하다 보면 모든 기능을 완벽하게 테스트하기 어려운 경우가 많습니다.

테스트 일정이 부족하거나
기능이 너무 많거나
릴리즈 일정이 촉박한 경우

이런 상황에서는 어떤 기능을 먼저 테스트해야 할지 결정하는 것이 중요합니다.

이때 사용하는 방법이 바로 리스크 기반 테스트(Risk-Based Testing) 입니다.

리스크 기반 테스트란
소프트웨어에서 발생할 수 있는 위험(Risk)을 기준으로 테스트 우선순위를 정하는 방법입니다.

즉,

문제가 발생할 가능성이 높거나
문제가 발생했을 때 영향이 큰 기능

이러한 부분을 우선적으로 테스트하는 방식입니다.

리스크(Risk)란 무엇인가?

리스크 기반 테스트를 이해하려면 먼저 리스크의 의미를 알아야 합니다.

소프트웨어 테스트에서 리스크는 보통 다음 두 가지 요소로 판단합니다.

발생 가능성 (Likelihood)
문제가 발생할 가능성이 얼마나 높은지

영향도 (Impact)
문제가 발생했을 때 사용자나 서비스에 미치는 영향

이 두 가지를 함께 고려하여 리스크 수준을 판단하게 됩니다.

간단히 정리하면

리스크 = 발생 가능성 × 영향도

리스크 기반 테스트 예시

예를 들어 이커머스 서비스가 있다고 가정해보겠습니다.

서비스에는 여러 기능이 존재합니다.

로그인
상품 검색
장바구니
결제
마이페이지

이 기능들을 모두 테스트하는 것이 이상적이지만, 일정이 부족한 경우 우선순위를 정해야 합니다.

이때 리스크 관점에서 보면 다음과 같이 판단할 수 있습니다.

리스크가 높은 기능

결제 기능
주문 처리
로그인 기능

이 기능들은 문제가 발생하면 서비스에 큰 영향을 줄 수 있습니다.

예를 들어 결제 기능에 문제가 발생하면

매출 손실
사용자 불만
서비스 신뢰도 하락

등의 문제가 발생할 수 있습니다.

그래서 이런 기능은 우선적으로 테스트해야 합니다.

리스크가 상대적으로 낮은 기능

예를 들어

프로필 이미지 변경
알림 설정
UI 일부 변경

이러한 기능은 문제가 발생하더라도 서비스 전체에 미치는 영향이 상대적으로 적을 수 있습니다.

따라서 테스트 시간이 부족한 상황에서는 핵심 기능 중심으로 테스트 범위를 정하는 것이 중요합니다.

이러한 방식이 바로 리스크 기반 테스트입니다.

리스크 기반 테스트 진행 방법

일반적으로 리스크 기반 테스트는 다음과 같은 과정으로 진행됩니다.

1️⃣ 리스크 식별

먼저 프로젝트에서 발생할 수 있는 리스크를 찾습니다.

예를 들면

결제 오류
로그인 실패
데이터 저장 오류

등이 있을 수 있습니다.

2️⃣ 리스크 분석

각 리스크에 대해

발생 가능성
영향도

를 분석합니다.

예를 들어

기능	발생 가능성	영향도	리스크
결제	높음	매우 높음	매우 높음
로그인	중간	높음	높음
프로필 수정	낮음	낮음	낮음

3️⃣ 테스트 우선순위 결정

리스크가 높은 기능부터 테스트 우선순위를 정합니다.

예를 들어

1️⃣ 결제
2️⃣ 로그인
3️⃣ 주문 처리
4️⃣ 검색
5️⃣ 기타 기능

이런 식으로 테스트 순서를 정할 수 있습니다.

리스크 기반 테스트의 장점

리스크 기반 테스트를 활용하면 다음과 같은 장점이 있습니다.

✔ 테스트 시간을 효율적으로 사용할 수 있음
✔ 중요한 기능을 먼저 검증할 수 있음
✔ 릴리즈 리스크를 줄일 수 있음
✔ 테스트 전략 수립에 도움이 됨

특히 일정이 제한된 프로젝트에서는 리스크 기반 접근이 매우 중요합니다.

개인적으로 정리한 리스크 기반 테스트 개념

리스크 기반 테스트를 간단히 정리하면 다음과 같습니다.

서비스에 가장 큰 영향을 줄 수 있는 기능을 먼저 테스트하는 것

실제 프로젝트에서는

모든 기능을 완벽하게 테스트하기 어렵기 때문에
핵심 기능 중심으로 테스트 범위를 정하는 경우가 많습니다.

그래서 QA 업무에서는 단순히 테스트를 수행하는 것뿐만 아니라

어떤 기능을 먼저 테스트해야 하는지 판단하는 능력도 중요하다고 생각합니다.

에러 추측 테스트(Error Guessing)란 무엇인가? QA 경험 기반 테스트 기법 쉽게 이해하기

qa-note — Wed, 13 May 2026 10:00:43 +0900

에러 추측 테스트(Error Guessing)란 무엇인가?

소프트웨어 테스트에는 여러 가지 테스트 기법이 있습니다.
그중에서 에러 추측 테스트(Error Guessing) 는 이름 그대로 “어디에서 오류가 발생할지 경험을 기반으로 추측해서 테스트하는 방법” 입니다.

즉,

테스트 기법이나 공식적인 규칙을 사용하는 것이 아니라
테스터의 경험과 직관을 기반으로 결함이 발생할 가능성이 높은 부분을 집중적으로 테스트하는 방식입니다.

그래서 보통 경험 기반 테스트 기법(Experience-Based Testing) 중 하나로 분류됩니다.

에러 추측 테스트의 핵심 개념

에러 추측 테스트는 간단하게 이렇게 정리할 수 있습니다.

과거에 문제가 자주 발생했던 영역
사용자가 실수할 가능성이 높은 입력 값
로직이 복잡한 기능

이런 부분에서 문제가 발생할 가능성을 예상하고 테스트를 진행하는 것입니다.

예를 들어

입력값이 비어있는 경우
매우 긴 문자열 입력
특수문자 입력
잘못된 데이터 형식

같은 상황을 테스트하는 것도 에러 추측 테스트의 대표적인 예시입니다.

에러 추측 테스트 예시

예를 들어 회원가입 기능을 테스트한다고 가정해보겠습니다.

일반적인 테스트 케이스는 다음과 같이 작성할 수 있습니다.

정상적인 이메일 입력
정상적인 비밀번호 입력
회원가입 성공 확인

하지만 에러 추측 테스트에서는 조금 다르게 접근합니다.

예를 들어 다음과 같은 상황을 생각해볼 수 있습니다.

이메일 입력란에 공백 입력
이메일 형식이 아닌 값 입력
비밀번호에 특수문자만 입력
매우 긴 문자열 입력
동일한 이메일로 여러 번 가입 시도

이처럼 사용자가 실제로 실수할 수 있는 상황이나 시스템이 처리하기 어려운 입력값을 중심으로 테스트하는 방식이 바로 에러 추측 테스트입니다.

에러 추측 테스트의 특징

에러 추측 테스트는 다른 테스트 기법과 비교했을 때 몇 가지 특징이 있습니다.

1️⃣ 테스터의 경험이 중요합니다

에러 추측 테스트는 명확한 규칙이나 공식이 있는 테스트 기법이 아닙니다.

그래서

테스트 경험
과거 결함 사례
시스템 이해도

이런 요소들이 중요합니다.

2️⃣ 테스트 케이스로 정의하기 어려운 경우도 있습니다

동등 분할이나 경계값 분석 같은 기법은
명확한 기준이 있기 때문에 테스트 케이스로 쉽게 정리할 수 있습니다.

하지만 에러 추측 테스트는

“문제가 생길 것 같은 부분을 테스트한다”

라는 특징이 있기 때문에 테스터의 판단이 크게 작용합니다.

3️⃣ 다른 테스트 기법과 함께 사용됩니다

에러 추측 테스트는 보통 단독으로 사용하기보다는 다른 테스트 기법과 함께 사용되는 경우가 많습니다.

예를 들어

동등 분할 테스트
경계값 분석
상태 전이 테스트

같은 기법으로 기본 테스트를 수행한 후

추가적으로 결함이 발생할 가능성이 높은 부분을 에러 추측 테스트로 확인합니다.

실제 테스트에서 자주 사용하는 에러 추측 사례

실제 테스트를 진행하다 보면 다음과 같은 상황에서 에러 추측 테스트를 많이 사용하게 됩니다.

입력값이 비어 있는 경우
최대 길이를 초과하는 입력
특수문자 입력
잘못된 데이터 형식 입력
동일한 요청을 반복 수행하는 경우

이런 상황은 실제 사용자 환경에서도 자주 발생하기 때문에 결함이 발견되는 경우가 꽤 많습니다.

개인적으로 정리한 에러 추측 테스트

에러 추측 테스트는 복잡한 테스트 기법이라기보다는 테스터의 경험에서 나오는 테스트 방식이라고 생각합니다.

테스트를 많이 진행하다 보면 자연스럽게

어디에서 문제가 자주 발생하는지
어떤 입력값에서 오류가 생기는지
어떤 기능이 취약한지

이런 것들이 보이기 시작합니다.

이때 그 경험을 기반으로 결함이 발생할 가능성이 높은 부분을 추가적으로 테스트하는 것이 에러 추측 테스트라고 볼 수 있습니다.

정리

에러 추측 테스트를 간단히 정리하면 다음과 같습니다.

테스터의 경험을 기반으로
결함이 발생할 가능성이 높은 부분을 추측하고
해당 영역을 집중적으로 테스트하는 방법

소프트웨어 테스트에서는 다양한 테스트 기법이 있지만
실제 프로젝트에서는 이런 경험 기반 테스트도 매우 중요한 역할을 합니다.

페어와이즈 테스트(Pairwise Testing)란 무엇인가? — 테스트 케이스를 줄이는 QA 테스트 기법

qa-note — Mon, 11 May 2026 10:00:42 +0900

페어와이즈 테스트(Pairwise Testing)란 무엇인가?

테스트 케이스를 작성하다 보면 이런 고민이 생깁니다.

모든 경우의 수를 테스트해야 할까?
테스트 케이스가 너무 많아지지 않을까?

실제로 여러 조건이 조합되는 기능에서는 테스트 케이스가 기하급수적으로 증가합니다.

이럴 때 사용하는 테스트 기법이 페어와이즈 테스트(Pairwise Testing) 입니다.

페어와이즈 테스트는
모든 조합을 테스트하지 않고
각 조건의 “쌍(pair)” 조합을 최소 한 번씩 테스트하는 방법입니다.

즉, 적은 테스트 케이스로도 많은 조합을 검증할 수 있는 테스트 기법이라고 이해하면 쉽습니다.

왜 페어와이즈 테스트가 필요한가

테스트 케이스를 작성할 때 조건이 많아지면 경우의 수가 급격히 증가합니다.

예를 들어 이런 상황을 생각해보겠습니다.

어떤 서비스에서 다음과 같은 조건이 있다고 가정합니다.

브라우저

Chrome
Edge
Safari

Windows
macOS

언어

한국어
영어

이 경우 가능한 모든 조합은 다음과 같습니다.

3 × 2 × 2 = 12가지 테스트 케이스

조건이 조금만 더 많아지면 테스트 케이스는 금방 수십 개, 수백 개가 됩니다.

하지만 실제로 많은 결함은 두 가지 조건의 조합에서 발생하는 경우가 많습니다.

그래서 모든 조합을 테스트하기보다는 각 조건의 쌍(pair)을 최소 한 번씩 테스트하는 방식을 사용하는 것이 바로 페어와이즈 테스트입니다.

페어와이즈 테스트의 핵심 개념

페어와이즈 테스트의 핵심은 간단합니다.

모든 조건 조합을 테스트하는 것이 아니라
조건의 "쌍"을 최소 한 번씩 테스트하는 것

예를 들어

브라우저와 OS
브라우저와 언어
OS와 언어

이처럼 각 요소의 조합이 최소 한 번씩 등장하도록 테스트 케이스를 구성합니다.

이 방법을 사용하면 테스트 케이스 수를 크게 줄일 수 있습니다.

페어와이즈 테스트 예시

다시 위 예시를 사용해보겠습니다.

조건

브라우저

Chrome
Edge
Safari

Windows
macOS

언어

한국어
영어

모든 조합을 테스트하면 12개 케이스가 필요합니다.

하지만 페어와이즈 테스트를 사용하면 다음처럼 줄일 수 있습니다.

예시 테스트 케이스

Chrome / Windows / 한국어
Chrome / macOS / 영어
Edge / Windows / 영어
Safari / macOS / 한국어

이렇게 구성하면

브라우저 + OS
브라우저 + 언어
OS + 언어

모든 쌍 조합이 최소 한 번씩 등장하게 됩니다.

즉, 12개의 테스트 케이스를 4개 정도로 줄일 수 있는 것입니다.

페어와이즈 테스트의 장점

페어와이즈 테스트의 가장 큰 장점은 효율적인 테스트 케이스 설계입니다.

✔ 테스트 케이스 수를 크게 줄일 수 있음
✔ 제한된 시간 안에 더 많은 조합을 검증 가능
✔ 테스트 효율성 증가

특히

여러 환경 조합 테스트
다양한 설정값 테스트
옵션이 많은 기능 테스트

같은 상황에서 많이 사용됩니다.

페어와이즈 테스트의 한계

페어와이즈 테스트가 항상 완벽한 방법은 아닙니다.

몇 가지 한계도 존재합니다.

✔ 세 가지 이상 조건의 복합 결함은 발견하기 어려울 수 있음
✔ 시스템 특성에 따라 모든 결함을 찾지 못할 수 있음

그래서 실제 프로젝트에서는

중요한 기능 → 모든 조합 테스트
일반 기능 → 페어와이즈 테스트

처럼 테스트 전략을 함께 사용하는 경우가 많습니다.

정리

페어와이즈 테스트는 테스트 케이스를 효율적으로 줄이기 위한 테스트 설계 기법입니다.

핵심은 다음과 같습니다.

모든 조합을 테스트하지 않는다
조건의 쌍(pair)을 최소 한 번씩 테스트한다
테스트 케이스 수를 줄이면서 효율적으로 테스트한다

테스트 케이스를 작성하다 보면 경우의 수가 너무 많아지는 상황이 자주 발생합니다.

이럴 때 페어와이즈 테스트 같은 테스트 설계 기법을 활용하면 테스트 효율을 높일 수 있습니다.

QA 테스트 기법을 공부하면서 이런 개념들도 계속 정리해볼 예정입니다.

QA 테스트 데이터 관리 방법 정리 (실무에서 사용하는 데이터 관리 팁)

qa-note — Fri, 8 May 2026 10:00:33 +0900

QA 테스트 데이터란 무엇인가?

QA 업무를 하다 보면 테스트를 위해 다양한 데이터를 준비해야 합니다.

예를 들면

회원 계정 데이터
상품 데이터
주문 데이터
결제 데이터

이처럼 테스트를 수행하기 위해 사용하는 데이터를 테스트 데이터(Test Data) 라고 합니다.

테스트 데이터는 테스트 결과에 직접적인 영향을 주기 때문에
QA 업무에서 매우 중요한 요소 중 하나입니다.

테스트 데이터 관리가 중요한 이유

처음 QA 업무를 시작하면 테스트 데이터 관리를 크게 신경 쓰지 않을 수도 있습니다.
하지만 프로젝트 규모가 커질수록 테스트 데이터 관리가 매우 중요해집니다.

테스트 데이터를 제대로 관리하지 않으면 다음과 같은 문제가 발생할 수 있습니다.

⚠️ 테스트 중 데이터가 이미 사용된 상태
⚠️ 다른 테스트와 데이터 충돌 발생
⚠️ 테스트 환경 데이터 부족
⚠️ 테스트 결과 재현 어려움

특히 여러 명의 QA가 동시에 테스트를 진행하는 경우
데이터 관리가 제대로 되지 않으면 테스트가 매우 혼란스러워질 수 있습니다.

그래서 실무에서는 테스트 데이터를 일정한 기준으로 관리하는 것이 중요합니다.

QA 테스트 데이터 종류

테스트 데이터는 목적에 따라 여러 종류로 나눌 수 있습니다.

정상 데이터 (Valid Data)

정상적으로 동작해야 하는 데이터를 의미합니다.

예시

정상 회원 계정
정상 결제 정보
정상 상품 데이터

주로 기능이 정상적으로 동작하는지 확인하는 테스트에 사용됩니다.

비정상 데이터 (Invalid Data)

오류 상황을 테스트하기 위한 데이터입니다.

예시

잘못된 이메일 형식
비밀번호 길이 초과
존재하지 않는 상품 ID

이러한 데이터는 예외 처리나 오류 메시지를 확인하는 테스트에 사용됩니다.

경계 데이터 (Boundary Data)

입력 값의 경계 조건을 테스트하기 위한 데이터입니다.

예시

최소 글자 수
최대 글자 수
허용 가능한 최대 금액

경계값 테스트에서 자주 사용됩니다.

테스트 데이터 관리 방법

실무에서 테스트 데이터를 관리하는 방법은 여러 가지가 있습니다.
프로젝트 환경에 따라 조금씩 다르지만 보통 다음과 같은 방법을 사용합니다.

1️⃣ 테스트 전용 계정 관리

테스트 환경에서는 보통 테스트 전용 계정을 따로 만들어 사용합니다.

예시

일반 회원 계정
관리자 계정
특정 권한 계정

테스트 계정을 미리 준비해 두면 테스트를 훨씬 빠르게 진행할 수 있습니다.

2️⃣ 테스트 데이터 목록 정리

테스트 데이터를 엑셀이나 문서로 정리해두는 것도 중요합니다.

예시

구분	데이터	설명
일반 회원	test_user01	기본 로그인 테스트
관리자 계정	admin_test	관리자 기능 테스트
테스트 상품	product_test01	상품 테스트용

이렇게 정리해 두면 여러 QA가 데이터를 함께 사용할 때 편리합니다.

3️⃣ 테스트 데이터 재사용

테스트 데이터를 매번 새로 만들기보다는
재사용 가능한 데이터 세트를 만들어 관리하는 경우도 많습니다.

예를 들면

로그인 테스트용 계정
결제 테스트용 계정
특정 상태의 주문 데이터

이렇게 준비된 데이터가 있으면 테스트 속도가 훨씬 빨라집니다.

4️⃣ 테스트 데이터 초기화

일부 테스트는 특정 상태의 데이터가 필요한 경우도 있습니다.

예를 들어

주문 완료 상태
결제 실패 상태
배송 진행 상태

이런 데이터는 테스트 후에 상태가 바뀔 수 있기 때문에
테스트 환경에서 데이터를 초기화하거나 새로 생성하는 방식으로 관리하기도 합니다.

테스트 데이터 관리 시 주의할 점

테스트 데이터를 관리할 때 몇 가지 주의해야 할 점이 있습니다.

테스트 데이터와 실제 서비스 데이터를 혼동하지 않기
여러 QA가 동시에 사용할 경우 데이터 충돌 방지
테스트 후 데이터 상태 확인
테스트 환경 데이터 주기적으로 정리

특히 이커머스 서비스처럼 데이터 흐름이 복잡한 경우
테스트 데이터 관리가 테스트 효율에 큰 영향을 줄 수 있습니다.

개인적으로 느낀 테스트 데이터 관리 중요성

QA 업무를 하다 보면 테스트 케이스나 테스트 환경도 중요하지만
테스트 데이터 관리도 생각보다 중요한 요소라고 느끼게 됩니다.

테스트 데이터가 제대로 준비되지 않으면

테스트 진행이 지연되거나
테스트 결과 확인이 어려워지거나
같은 테스트를 다시 수행해야 하는 상황이 생길 수 있습니다.

그래서 테스트를 시작하기 전에
어떤 테스트 데이터가 필요한지 미리 정리해두는 것이 중요하다고 생각합니다.

마무리

테스트 데이터는 QA 테스트 과정에서 매우 중요한 요소입니다.

간단히 정리하면

✔ 테스트 목적에 맞는 데이터 준비
✔ 테스트 데이터 목록 정리
✔ 재사용 가능한 데이터 관리
✔ 테스트 환경 데이터 상태 관리

이러한 방식으로 테스트 데이터를 관리하면
테스트 효율을 높이는 데 도움이 됩니다.

QA 테스트 데이터 준비 방법 정리 (실무에서 사용하는 데이터 만들기 가이드)

qa-note — Wed, 6 May 2026 10:00:58 +0900

QA 테스트 데이터 준비 방법 정리

QA 업무를 하다 보면 테스트 케이스만큼이나 중요한 것이 바로 테스트 데이터(Test Data) 입니다.

테스트 데이터란 간단하게 말하면 기능을 테스트하기 위해 사용하는 입력 값이나 정보를 의미합니다.

예를 들어 로그인 기능을 테스트한다고 하면 다음과 같은 것들이 테스트 데이터가 됩니다.

정상 아이디 / 비밀번호
잘못된 아이디
잘못된 비밀번호
비어있는 입력값

이처럼 다양한 상황을 테스트하기 위해 여러 종류의 데이터를 미리 준비해야 합니다.

테스트 데이터가 중요한 이유

테스트는 단순히 기능을 실행해 보는 것이 아니라 다양한 상황을 검증하는 과정입니다.

하지만 테스트 데이터가 제대로 준비되지 않으면 다음과 같은 문제가 발생할 수 있습니다.

특정 상황 테스트를 하지 못함
버그 재현이 어려움
테스트 결과 신뢰도가 떨어짐

그래서 실제 QA 업무에서는 테스트 데이터 관리도 중요한 업무 중 하나입니다.

테스트 데이터 예시

예를 들어 회원가입 기능을 테스트한다고 가정해 보겠습니다.

이 경우 다음과 같은 데이터를 준비할 수 있습니다.

정상 데이터

정상 이메일
정상 비밀번호
정상 전화번호

정상적으로 가입이 되는지 확인하기 위한 데이터입니다.

비정상 데이터

이메일 형식이 아닌 값
비밀번호 조건을 만족하지 않는 값
이미 사용 중인 이메일

입력값 검증이 제대로 동작하는지 확인하기 위한 데이터입니다.

경계값 데이터

예를 들어 비밀번호 길이가 8자 이상이라고 하면

7자
8자
9자

이처럼 조건의 경계에 있는 데이터를 테스트할 수 있습니다.

QA가 테스트 데이터를 준비하는 방법

실무에서는 보통 다음과 같은 방법으로 테스트 데이터를 준비합니다.

1️⃣ 테스트 케이스 기반으로 준비하기

가장 기본적인 방법입니다.

테스트 케이스를 작성하면서 필요한 데이터를 함께 정리합니다.

예시

테스트 케이스	테스트 데이터
정상 로그인	정상 계정
비밀번호 오류	잘못된 비밀번호
아이디 오류	존재하지 않는 계정

이렇게 정리해 두면 테스트 진행할 때 바로 사용할 수 있습니다.

2️⃣ 다양한 입력값 미리 정리하기

테스트를 하다 보면 비슷한 데이터가 계속 필요해지는 경우가 많습니다.

예를 들어

테스트용 이메일
테스트용 전화번호
테스트용 계정

이런 데이터를 미리 만들어 두면 테스트를 훨씬 편하게 진행할 수 있습니다.

3️⃣ 테스트 전용 계정 만들기

실제 서비스에서는 테스트 전용 계정을 만들어 사용하는 경우도 많습니다.

예시

일반 사용자 계정
관리자 계정
특정 권한이 있는 계정

이런 계정을 미리 준비해 두면 권한 관련 테스트를 쉽게 진행할 수 있습니다.

4️⃣ 반복 테스트를 위한 데이터 준비

테스트를 하다 보면 같은 데이터를 여러 번 사용하는 경우도 있습니다.

예를 들어

결제 테스트
주문 테스트
포인트 테스트

이런 기능들은 테스트 이후 데이터 상태가 변경될 수 있기 때문에
여러 개의 테스트 데이터를 준비해 두는 것이 좋습니다.

테스트 데이터를 준비할 때 주의할 점

테스트 데이터를 준비할 때 몇 가지 주의해야 할 점도 있습니다.

실제 사용자 데이터 사용 주의

실제 서비스 데이터에는 개인정보가 포함될 수 있기 때문에
테스트 데이터로 사용하는 것은 주의가 필요합니다.

가능하면 테스트용 데이터를 별도로 만들어 사용하는 것이 좋습니다.

데이터 상태 관리

테스트를 진행하면서 데이터 상태가 변경되는 경우도 있습니다.

예를 들어

주문 상태 변경
계정 상태 변경
포인트 사용

이런 경우에는 테스트 전에 데이터 상태를 다시 확인하는 과정도 필요합니다.

정리

QA 테스트에서 테스트 데이터는 생각보다 중요한 요소입니다.

간단히 정리하면

✔ 다양한 상황을 테스트하기 위해 필요함
✔ 테스트 케이스와 함께 준비하는 것이 좋음
✔ 반복 테스트를 고려해서 여러 데이터를 준비하면 좋음

실제 QA 업무를 하다 보면 테스트 데이터 준비도 테스트 품질에 영향을 주는 요소라는 것을 느끼게 됩니다.

앞으로 QA 실무 가이드에서는 실무에서 사용하는 테스트 방법이나 QA 업무 정리도 계속 작성해 볼 예정입니다.

QA 릴리즈 전 체크리스트 정리 (배포 전에 QA가 꼭 확인해야 할 것)

qa-note — Mon, 4 May 2026 10:00:46 +0900

QA 릴리즈 전 체크리스트 정리

서비스를 개발하고 테스트를 마친 뒤에는 릴리즈(배포) 단계가 진행됩니다.
이때 QA는 마지막으로 서비스 상태를 확인하고 릴리즈가 가능한지 검증하는 역할을 하게 됩니다.

테스트가 대부분 끝난 상태라고 하더라도
릴리즈 직전에 확인해야 할 항목들이 있습니다.

이번 글에서는 QA가 릴리즈 전에 확인하면 좋은 체크리스트를 정리해보려고 합니다.

1️⃣ 주요 기능 정상 동작 확인

릴리즈 전에 가장 먼저 확인해야 할 것은 핵심 기능이 정상적으로 동작하는지입니다.

보통 다음과 같은 기능들이 포함됩니다.

로그인 / 로그아웃
회원가입
주요 서비스 기능
데이터 저장 / 조회
주요 사용자 흐름

모든 기능을 다시 테스트하기보다는 서비스에서 가장 중요한 기능 위주로 확인하는 것이 좋습니다.

이 과정은 흔히 Smoke Test 또는 간단한 회귀 테스트 형태로 진행됩니다.

2️⃣ 주요 버그 해결 여부 확인

테스트 과정에서 발견된 버그 중에서 릴리즈 전에 반드시 해결되어야 하는 버그들이 있습니다.

예를 들면

서비스 이용이 불가능한 버그
데이터 오류
결제 오류
로그인 문제

이러한 버그가 남아 있는 상태라면 릴리즈 진행 여부를 다시 검토해야 할 수 있습니다.

그래서 릴리즈 전에

✔ Critical / Major 버그가 남아있는지
✔ 해결된 버그가 정상적으로 수정되었는지

다시 한번 확인하는 과정이 필요합니다.

3️⃣ 최근 수정 기능 영향 확인

개발 막바지에는 버그 수정이나 기능 수정이 여러 번 발생하는 경우가 많습니다.

이때 주의해야 할 것은

수정한 기능이 다른 기능에 영향을 주지 않았는지 입니다.

예를 들어

로그인 수정 → 회원 정보 조회 오류 발생
결제 수정 → 주문 생성 오류 발생

이처럼 예상하지 못한 사이드 이펙트가 발생할 수 있습니다.

그래서 최근 수정된 기능 주변 영역은 간단하게라도 다시 테스트하는 것이 좋습니다.

4️⃣ 테스트 환경과 실제 환경 차이 확인

테스트는 보통 개발 환경 / 스테이징 환경 등에서 진행됩니다.

하지만 실제 릴리즈 환경에서는

설정값
서버 환경
외부 연동

등이 다를 수 있습니다.

그래서 가능하다면

✔ 환경 설정
✔ 외부 API 연동
✔ 주요 서비스 흐름

이 정상적으로 동작하는지 확인하는 과정이 필요합니다.

5️⃣ 테스트 범위 누락 여부 확인

프로젝트를 진행하다 보면

기획 변경
기능 추가
일정 압박

등으로 인해 테스트가 누락되는 경우도 발생할 수 있습니다.

그래서 릴리즈 전에는

테스트 케이스 수행 여부
테스트 범위 누락 여부

를 한번 정리해보는 것이 좋습니다.

이 과정은 QA 입장에서 테스트 품질을 다시 점검하는 단계라고 볼 수 있습니다.

6️⃣ 릴리즈 가능 여부 정리

마지막으로 QA는 릴리즈 가능 여부를 정리하게 됩니다.

보통 다음과 같은 기준으로 판단합니다.

✔ 주요 기능 정상 동작
✔ 치명적인 버그 없음
✔ 테스트 범위 수행 완료

이 조건이 충족되면 릴리즈 진행 가능으로 판단하게 됩니다.

물론 실제 프로젝트에서는

일정
서비스 상황
비즈니스 판단

등 여러 요소가 함께 고려되기도 합니다.

개인적으로 정리한 릴리즈 전 QA 체크 포인트

QA 입장에서 릴리즈 직전에 확인하는 것은
새로운 테스트를 하는 것이라기보다 마지막으로 서비스 상태를 점검하는 과정이라고 생각합니다.

정리해보면 다음과 같습니다.

✔ 핵심 기능 정상 동작 확인
✔ 주요 버그 해결 여부 확인
✔ 최근 수정 기능 영향 확인
✔ 테스트 범위 누락 여부 확인

이 정도만 잘 확인해도 릴리즈 전에 큰 문제를 줄이는 데 도움이 됩니다.

QA 신입이 가장 많이 하는 실수 5가지 (첫 직장에서 배운 것들)

qa-note — Fri, 1 May 2026 10:00:44 +0900

QA 신입 시절 가장 많이 했던 실수들

처음 QA로 일을 시작했을 때는 테스트라는 일이 생각보다 단순하다고 생각했습니다.
기능이 잘 동작하는지 확인하고 문제가 있으면 버그를 등록하는 일이라고만 생각했기 때문입니다.

하지만 실제로 일을 해보니 QA 업무는 생각보다 훨씬 다양한 요소가 필요했습니다.

테스트 범위를 이해하는 것,
기획 의도를 파악하는 것,
개발자와 소통하는 것 등 단순히 테스트만 하는 일이 아니었습니다.

돌이켜보면 신입 시절에는 여러 가지 실수를 했던 것 같습니다.
지금 생각해보면 당연한 것들이지만, 당시에는 몰랐던 것들이 많았습니다.

오늘은 QA 신입 시절 가장 많이 했던 실수들을 정리해보려고 합니다.

1️⃣ 테스트를 너무 단순하게 생각했던 것

처음 QA 일을 시작했을 때는 테스트를 이렇게 생각했습니다.

기능이 동작하면 OK
동작하지 않으면 버그

하지만 실제 테스트는 훨씬 더 많은 것을 확인해야 했습니다.

예를 들면

예외 상황 처리
입력값 검증
UI 동작
데이터 처리
다른 기능과의 연동

단순히 "정상 동작 여부"만 보는 것이 아니라
다양한 상황을 고려하면서 테스트해야 한다는 것을 나중에야 알게 되었습니다.

신입 시절에는 이런 부분을 놓치는 경우가 많았습니다.

2️⃣ 기획서를 충분히 이해하지 않고 테스트했던 것

초반에는 기획서를 대충 읽고 바로 테스트를 시작했던 적도 있었습니다.

하지만 테스트를 하다 보면 이런 상황이 자주 발생했습니다.

이게 버그인지
원래 기획인지
변경된 기능인지

판단하기 어려운 경우가 많았습니다.

이 경험을 통해 느낀 것은

QA에게 기획 이해는 생각보다 중요하다는 것입니다.

지금은 테스트를 시작하기 전에

기능 흐름
예외 상황
정책

같은 것들을 먼저 확인하려고 합니다.

3️⃣ 버그 리포트를 너무 간단하게 작성했던 것

신입 시절에는 버그 리포트를 이렇게 작성했던 기억이 있습니다.

예시

로그인 안됨

지금 생각해보면 굉장히 부족한 리포트였습니다.

개발자가 문제를 파악하려면

재현 방법
테스트 환경
발생 조건

같은 정보가 필요합니다.

그래서 지금은 버그 리포트를 작성할 때 다음 내용을 최대한 포함하려고 합니다.

재현 단계
실제 결과
기대 결과
테스트 환경

이런 정보가 있어야 개발자도 문제를 빠르게 파악할 수 있습니다.

4️⃣ 질문을 너무 늦게 했던 것

신입 시절에는 모르는 것이 있어도 바로 질문하지 못했던 경우가 있었습니다.

이게 맞는 테스트인지
기획이 맞는지
버그가 맞는지

혼자 고민하다가 시간을 많이 쓰기도 했습니다.

하지만 일을 하면서 느낀 것은

QA는 혼자 일하는 직무가 아니라는 것입니다.

기획자, 개발자와 계속 소통하면서
기능을 이해하고 테스트를 진행해야 합니다.

지금은 애매한 부분이 있으면
가능한 빨리 확인하려고 합니다.

5️⃣ 테스트 범위를 넓게 보지 못했던 것

신입 시절에는 하나의 기능만 집중해서 테스트하는 경우가 많았습니다.

예를 들어

로그인 기능
회원가입 기능
상품 검색 기능

각 기능을 따로 테스트하는 경우가 많았습니다.

하지만 실제 서비스에서는
기능들이 서로 연결되어 있는 경우가 많습니다.

예를 들어

회원가입 → 로그인
로그인 → 장바구니
장바구니 → 결제

이처럼 여러 기능이 연결되는 흐름을 함께 테스트해야 합니다.

이런 관점은 일을 하면서 조금씩 배우게 되었습니다.

정리하며

돌이켜보면 신입 시절에는 실수도 많았고
모르는 것도 많았습니다.

하지만 그런 경험들이 쌓이면서
조금씩 QA 업무에 대한 이해도도 높아졌던 것 같습니다.

지금도 여전히 배우는 과정이지만
처음 일을 시작했을 때보다는 테스트를 바라보는 시야가 조금 넓어진 것 같습니다.

앞으로도 QA 일을 하면서 느꼈던 점이나 경험들을
이렇게 정리해보려고 합니다.

qa-note

테스트 조건(Test Condition)이란 무엇인가? QA 테스트 설계의 핵심 개념 정리

테스트 조건(Test Condition)이란 무엇인가?

테스트 조건을 쉽게 이해해보기

테스트 조건은 왜 중요한가?

테스트 조건과 테스트 케이스의 차이

테스트 조건은 어디에서 도출할까?

실무에서 느낀 테스트 조건의 의미

정리

테스트 전략(Test Strategy) vs 테스트 계획(Test Plan) 차이 정리 (QA 이론 쉽게 이해하기)

테스트 전략(Test Strategy) vs 테스트 계획(Test Plan)

먼저 간단하게 정리하면

테스트 전략(Test Strategy)이란?

테스트 계획(Test Plan)이란?

예시로 이해해보기

테스트 전략

테스트 계획

테스트 전략 vs 테스트 계획 차이 정리

개인적으로 정리한 개념

테스트 커버리지(Test Coverage)란 무엇인가? QA에서 중요한 이유 쉽게 정리

테스트 커버리지(Test Coverage)란 무엇인가?

테스트 커버리지 예시

왜 테스트 커버리지가 중요한가

테스트 커버리지의 종류

기능 커버리지 (Feature Coverage)

요구사항 커버리지 (Requirement Coverage)

코드 커버리지 (Code Coverage)

QA 관점에서의 테스트 커버리지

테스트 커버리지가 높다고 항상 좋은 것은 아니다

개인적으로 정리한 테스트 커버리지 개념

리스크 기반 테스트(Risk-Based Testing)란 무엇인가? QA 테스트 우선순위 정하는 방법

리스크 기반 테스트(Risk-Based Testing)란 무엇인가?

리스크(Risk)란 무엇인가?

리스크 기반 테스트 예시

리스크가 높은 기능

리스크가 상대적으로 낮은 기능

리스크 기반 테스트 진행 방법

1️⃣ 리스크 식별

2️⃣ 리스크 분석

3️⃣ 테스트 우선순위 결정

리스크 기반 테스트의 장점

개인적으로 정리한 리스크 기반 테스트 개념

함께 보면 좋은 QA 테스트 기법

에러 추측 테스트(Error Guessing)란 무엇인가? QA 경험 기반 테스트 기법 쉽게 이해하기

에러 추측 테스트(Error Guessing)란 무엇인가?

에러 추측 테스트의 핵심 개념

에러 추측 테스트 예시

에러 추측 테스트의 특징

1️⃣ 테스터의 경험이 중요합니다

2️⃣ 테스트 케이스로 정의하기 어려운 경우도 있습니다

3️⃣ 다른 테스트 기법과 함께 사용됩니다

실제 테스트에서 자주 사용하는 에러 추측 사례

개인적으로 정리한 에러 추측 테스트

정리

페어와이즈 테스트(Pairwise Testing)란 무엇인가? — 테스트 케이스를 줄이는 QA 테스트 기법

페어와이즈 테스트(Pairwise Testing)란 무엇인가?

왜 페어와이즈 테스트가 필요한가

페어와이즈 테스트의 핵심 개념

페어와이즈 테스트 예시

페어와이즈 테스트의 장점

페어와이즈 테스트의 한계

정리

QA 테스트 데이터 관리 방법 정리 (실무에서 사용하는 데이터 관리 팁)

QA 테스트 데이터란 무엇인가?

테스트 데이터 관리가 중요한 이유

QA 테스트 데이터 종류

정상 데이터 (Valid Data)

비정상 데이터 (Invalid Data)

경계 데이터 (Boundary Data)

테스트 데이터 관리 방법

1️⃣ 테스트 전용 계정 관리

2️⃣ 테스트 데이터 목록 정리

3️⃣ 테스트 데이터 재사용

4️⃣ 테스트 데이터 초기화

테스트 데이터 관리 시 주의할 점

개인적으로 느낀 테스트 데이터 관리 중요성

마무리

QA 테스트 데이터 준비 방법 정리 (실무에서 사용하는 데이터 만들기 가이드)

QA 테스트 데이터 준비 방법 정리

테스트 데이터가 중요한 이유