QA 아웃소싱 의뢰 전, 꼭 알아야 할 필수 용어 10가지

“QA는 외주로 맡기면 되겠지?”

많은 기업이 서비스 출시를 앞두고 QA 아웃소싱을 고려합니다.

하지만 막상 의뢰를 진행하려고 하면 예상보다 많은 질문을 받게 됩니다.

​

​

​

“테스트 범위는 어디까지인가요?”

“어떤 테스트 유형이 필요한가요?”

“테스트 결과는 어떤 형태로 받으실 건가요?”

​

이 질문들에 명확하게 답하지 못하면

프로젝트는 생각보다 쉽게 흔들리기 시작합니다.

​

👉 테스트 범위가 불명확하면 비용이 늘어나고

👉 일정 기준이 없으면 출시 일정이 밀리고

👉 결과물 기준이 없으면 테스트 품질을 평가하기 어렵습니다.

​

그래서 QA 아웃소싱을 진행하기 전, 기본적으로 알고 있어야 할 핵심 용어들이 있습니다.

오늘은 실제 프로젝트에서 가장 많이 등장하는 QA 아웃소싱 필수 용어 10가지를 정리해보겠습니다.

​

​

​

 

1. 테스트 범위 (Test Scope)

테스트 범위는 말 그대로 어디까지 검증할 것인지 정하는 기준​입니다.

예를 들어 같은 서비스라도 테스트 범위는 크게 달라질 수 있습니다.

• 로그인 / 결제 / 관리자 기능 포함 여부
• 웹 서비스만 테스트할지 모바일까지 진행할지
• 신규 기능만 검증할지 전체 시스템을 확인할지

이 범위가 명확하지 않으면 프로젝트 중간에

“이 기능은 테스트 대상이 아니었습니다.”

같은 문제가 발생할 수 있습니다. 그래서 QA 프로젝트의 첫 단계는 항상 범위 정의입니다.

 

 

2. 테스트 유형 (Test Type)

많은 분들이 QA를 “기능 테스트”라고만 생각하지만 실제로는 다양한 테스트 유형이 존재합니다.

대표적인 테스트 유형은 다음과 같습니다.

• 기능 테스트
• 성능 테스트
• 보안 테스트
• 사용성 테스트
• 호환성 테스트

예를 들어 쇼핑몰 서비스라면 기능 테스트뿐 아니라 결제 안정성이나 트래픽 대응 성능도 중요합니다.

어떤 테스트 유형을 포함하느냐에 따라 프로젝트 비용과 일정이 크게 달라집니다.

 

 

3. 테스트 케이스 (Test Case)

테스트 케이스는 테스트 절차와 검증 기준을 문서로 정리한 것입니다.

예를 들어 로그인 기능을 테스트한다면 다음과 같은 흐름이 됩니다.

1. 로그인 화면 진입
2. 아이디 / 비밀번호 입력
3. 로그인 버튼 클릭
4. 정상 로그인 여부 확인

이처럼 테스트 절차를 체계적으로 정리해야

누가 테스트를 수행하더라도 같은 기준으로 검증​할 수 있습니다.

​

 

4. 결함 관리 (Defect Management)

테스트의 핵심은 버그를 발견하는 것이 아니라

버그를 제대로 관리하는 것입니다.

보통 다음과 같은 협업 도구를 활용합니다.

• Jira
• Redmine
• Notion
• 자체 버그 관리 시스템

일반적인 결함 관리 흐름은 다음과 같습니다.

버그 등록 → 개발 수정 → 재테스트 → 종료

이 과정이 명확해야 프로젝트 품질이 안정적으로 관리됩니다.

​

 

5. 테스트 환경 (Test Environment)

테스트는 실제 서비스 환경과 최대한 비슷한 조건에서 진행해야 합니다.

예를 들어 다음과 같은 요소들이 포함됩니다.

• 개발 / 운영 / 검증 서버 구분
• 브라우저 종류 (Chrome, Safari 등)
• OS 버전
• 모바일 기종

테스트 환경이 실제 사용자 환경과 다르면

실제 서비스에서 발생할 장애를 놓칠 수도 있습니다.

​

​

 

6. 투입 인력 / 리소스 (Resource)

QA 프로젝트에서 누가 테스트를 수행하는지​도 매우 중요합니다.

확인해야 할 대표적인 항목은 다음과 같습니다.

• 투입 인원 수
• 경력 수준
• 전담 여부
• 유사 프로젝트 경험

단순히 인원 수보다

경험 있는 QA 인력이 투입되는지가 품질에 큰 영향을 미칩니다.

​

​

7. 산출물 (Deliverables)

QA 아웃소싱을 진행했다면 프로젝트 종료 후 어떤 결과물을 받을지도 중요합니다.

대표적인 QA 산출물은 다음과 같습니다.

• 테스트 결과 보고서
• 결함 목록
• 테스트 요약 리포트
• 품질 개선 제안

산출물이 명확해야 테스트 품질을 객관적으로 확인할 수 있습니다.

​

 

8. SLA (Service Level Agreement)

SLA는 서비스 품질에 대한 약속 기준입니다.

예를 들어 다음과 같은 내용이 포함됩니다.

• 버그 대응 시간
• 긴급 이슈 처리 기준
• 주간 / 일일 보고 주기

SLA가 명확하면 프로젝트 운영 과정에서

대응 속도와 책임 범위가 분명해집니다.

​

 

9. 테스트 일정 (Test Schedule)

QA 일정은 개발 일정과 매우 밀접하게 연결됩니다.

일반적으로 다음과 같은 단계로 구성됩니다.

• 테스트 시작일
• 중간 점검 일정
• 테스트 종료일
• 재테스트 기간

일정이 명확하지 않으면 출시 일정 전체가 흔들릴 수 있습니다.

​

 

10. 검수 기준 (Acceptance Criteria)

QA 프로젝트에서 마지막으로 중요한 것은 언제 테스트를 종료할 것인지에 대한 기준입니다.

예를 들어 다음과 같은 기준을 설정할 수 있습니다.

• 치명적 버그 0건
• 주요 버그 3건 이하
• 전체 테스트 케이스 통과율 95% 이상

이 기준이 없으면 테스트가 끝없이 반복되는 상황이 발생할 수 있습니다.

​

​​

QA 아웃소싱이 실패하는 가장 큰 이유는 대부분 준비 부족입니다.

하지만 아래 네 가지만 명확히 정리해도 프로젝트 성공 확률은 크게 높아집니다.

​

​

 

✔ 테스트 범위 ✔ 테스트 방식 ✔ 결과 산출물 ✔ 완료 기준

​

이 네 가지가 명확하면 불필요한 비용 증가나 일정 지연을 크게 줄일 수 있습니다.