사용자 수락 테스트 (UAT) 란 무엇입니까?

사용자 수락 테스트 (UAT) 란 무엇입니까? , 정의, 유형, 단계 및 예와 함께 :

새로운 개념을 이해하려고 할 때 내 규칙 첫 번째는 다음과 같습니다. 이름은 항상 관련성이 있고 대부분 문자 그대로의 의미입니다. 기술적 인 맥락).

그게 무엇인지 알아 내면 처음부터 이해하고 시작하는 데 도움이됩니다.

= > 전체 테스트 계획 자습서 시리즈를 보려면 여기를 클릭하십시오.

이 개념을 테스트 해 보겠습니다.

= > 수락 테스트 시리즈의 모든 자습서를 읽어보세요.

사용자 수락 테스트 란 무엇인가요?

우리는 테스트가 무엇인지 알고 있으며 수락은 승인 또는 동의를 의미합니다. 소프트웨어 제품의 맥락에서 사용자는 소프트웨어의 소비자이거나 그 / 그녀 (클라이언트)를 위해 빌드를 요청한 사람입니다.

그러므로 제 규칙에 따라 정의는 다음과 같습니다. :

베타 또는 최종 사용자 테스트라고도하는 UAT (User Acceptance Testing)는 사용자 나 클라이언트가 소프트웨어를 수락 할 수 있는지 여부를 결정하기 위해 소프트웨어를 테스트하는 것으로 정의됩니다. 이것은 기능, 시스템 및 회귀 테스트가 완료되면 수행되는 최종 테스트입니다.

이 테스트의 주요 목적은 비즈니스 요구 사항에 대해 소프트웨어를 검증하는 것입니다. 이 유효성 검사는 비즈니스 요구 사항에 익숙한 최종 사용자가 수행합니다.

UAT, 알파 및 베타 테스트는 승인 테스트의 다른 유형입니다.

사용자 승인 테스트는 소프트웨어가 출시되기 전에 수행되는 마지막 테스트이므로 분명히 이것은 고객이 소프트웨어를 테스트하고 목적에 적합한 지 측정 할 수있는 마지막 기회입니다.

언제 수행됩니까?

이것은 일반적으로 제품이 출시되기 전 마지막 단계입니다. 제품의 배송이 수락되기 전에. 이는 제품 자체를 철저히 테스트 한 후 (즉, 시스템 테스트 후) 수행됩니다.

UAT를 수행하는 사람

사용자 또는 클라이언트 – 제품을 구매하는 사람 일 수 있습니다 ( 상용 소프트웨어의 경우) 또는 소프트웨어 서비스 제공 업체 또는 최종 사용자를 통해 소프트웨어를 맞춤 제작 한 사람 또는 소프트웨어가 미리 제공되고 피드백이 필요할 때 최종 사용자에게 제공됩니다.

팀은 베타 테스터로 구성되거나 고객이 조직의 모든 그룹에서 내부적으로 UAT 구성원을 선택하여 각 사용자 역할을 그에 따라 테스트 할 수 있습니다.

Need For User Acceptance Testing

개발자 및 기능 테스터는 기능 사양에 대해 소프트웨어를 검증하는 기술 인력입니다. 그들은 자신의 지식에 따라 요구 사항을 해석하고 소프트웨어를 개발 / 테스트합니다 (여기에 도메인 지식의 중요성이 있습니다).

이 소프트웨어는 기능 사양에 따라 완전하지만 몇 가지 비즈니스 요구 사항과 프로세스가 있습니다. 최종 사용자에게만 알려진 정보는 커뮤니케이션을 놓치거나 잘못 해석됩니다.

이 테스트는 시장 용 소프트웨어를 출시하기 전에 모든 비즈니스 요구 사항이 충족되었는지 여부를 확인하는 데 중요한 역할을합니다. 라이브 데이터와 실제 사용 사례를 사용하면이 테스트가 출시주기의 중요한 부분이됩니다.

출시 후 문제로 인해 큰 손실을 입은 많은 기업은 성공적인 사용자 수락 테스트의 중요성을 알고 있습니다. 릴리스 후 결함을 수정하는 데 드는 비용은 이전 수정보다 몇 배 더 큽니다.

UAT가 정말 필요한가요?

시스템로드, 통합 및 회귀 테스트를 수행 한 후 궁금 할 것입니다. 이 테스트의 필요성. 실제로 이것은 시스템을 실제로 사용할 사용자가 시스템이 목적에 맞는지 확인하는 시간이므로 프로젝트에서 가장 중요한 단계입니다.

UAT는 테스트입니다. 최종 사용자의 관점과 최종 사용자를 대표하는 부서의 도메인 지식에 크게 좌우되는 단계입니다.

사실상 비즈니스 팀에 정말 도움이 될 것입니다. 그들은 실제 세계에서 시스템을 효과적으로 사용하는 데 도움이 될 자신의 견해와 기여를 제공 할 수 있도록 프로젝트에 아주 일찍 참여했습니다.

사용자 수락 테스트 프로세스

The 이 프로세스를 이해하는 가장 쉬운 방법은이를 자율 테스트 프로젝트로 생각하는 것입니다. 즉, 계획, 설계 및 실행 단계가있을 것입니다.

다음은 계획 단계 이전의 전제 조건입니다. 시작 :

# 1) 주요 수락 기준 수집

간단히 말하면 수락 기준은 제품을 수락하기 전에 평가 될 ngs.

다음 두 가지 유형이있을 수 있습니다.

(i) 애플리케이션 기능 또는 비즈니스 관련

이상적으로는 모든 주요 비즈니스 기능이 검증되어야하지만 시간을 포함한 여러 가지 이유로 모든 것을하는 것은 실용적이지 않습니다. 따라서이 테스트에 참여할 클라이언트 또는 사용자와의 만남은 얼마나 많은 테스트가 관련되고 어떤 측면이 테스트 될 것인지에 대한 아이디어를 제공 할 수 있습니다.

(ii) 계약 – 우리는 여기에 들어 가지 않을 것이며이 모든 것에 QA 팀의 참여는 거의 아무것도 아닙니다. SDLC가 시작되기 전에 작성되는 초기 계약을 검토하고 계약의 모든 측면이 전달되었는지 여부에 대한 합의가 이루어집니다.

우리는 애플리케이션 기능에만 집중할 것입니다. .

# 2) QA 참여 범위를 정의합니다.

QA 팀의 역할은 다음 중 하나입니다.

(i) 참여 없음 – 매우 드뭅니다.

(ii)이 테스트 지원 – 대부분 흔한. 이 경우, 우리의 참여는 UAT 사용자에게 응용 프로그램 사용 방법을 교육하고이 테스트 중에 대기 상태로 유지하여 어려움이있는 경우 사용자를 도울 수 있는지 확인하는 것입니다. 또는 경우에 따라 사용자가 실제 테스트를 수행하는 동안 대기 상태에서 지원하는 것 외에도 응답을 공유하고 결과를 기록하거나 버그를 기록 할 수 있습니다.

(iii) UAT 수행 및 현재 결과 –이 경우 사용자는 평가하고자하는 AUT 영역을 가리키고 평가 자체는 QA 팀에서 수행합니다. 완료되면 결과가 클라이언트 / 사용자에게 제공되고 AUT를 수락하기 위해 보유한 결과가 충분한 지 여부 및 기대에 따라 결정을 내립니다. 결정은 QA 팀의 결정이 아닙니다.

당사 사례에 따라 어떤 접근 방식이 가장 좋은지 결정합니다.

기본 목표 및 기대 :

일반적으로 UAT는 SME (Subject Matter Expert) 및 / 또는 테스트중인 시스템의 소유자 또는 고객 일 수있는 비즈니스 사용자가 수행합니다. 시스템 테스트 단계와 마찬가지로 UAT 단계는 종료되기 전에 종교 단계도 포함합니다.

각 UAT 단계의 주요 활동은 다음과 같습니다.

UAT 거버넌스

시스템 테스트와 유사하게 UAT에 대해 효과적인 거버넌스가 적용되어 정의 된 진입 및 종료 기준 (** 아래에 제공됨)과 함께 강력한 품질 게이트를 보장합니다.

** 지침 일뿐입니다. 이는 프로젝트 요구 사항 및 요구 사항에 따라 수정할 수 있습니다.

UAT 테스트 계획

프로세스는 시스템 단계의 일반 테스트 계획과 거의 동일합니다.

대부분의 프로젝트에서 따르는 가장 일반적인 접근 방식은 시스템 및 UAT 테스트 단계를 함께 계획하는 것입니다. 샘플과 함께 UAT 테스트 계획에 대한 자세한 내용은 첨부 된 테스트 계획 문서의 UAT 섹션을 확인하십시오.

사용자 수락 테스트 계획

(이는 귀하와 동일합니다. QA 교육 시리즈도 저희 사이트에서 찾으십시오).

아래 이미지를 클릭하고 아래로 스크롤하여 다양한 형식의 테스트 계획 문서 샘플을 찾으십시오. 해당 템플릿에서 UAT 섹션을 확인합니다.

날짜, 환경, 행위자 (누가), 통신 프로토콜, 역할 및 책임, 템플릿, 결과 및 분석 프로세스, 진입-종료 기준 – 모두 이것과 관련된 모든 것은 UAT 테스트 계획에서 찾을 수 있습니다.

QA 팀이이 테스트에 참여하는지, 부분적으로 참여하는지 또는 전혀 참여하지 않는지 여부에 관계없이이 단계를 계획하고 모든 사항을 고려하십시오.

= > 다음은 사용자 수락 테스트 계획 샘플 문서입니다.

사용자 수락 테스트 디자인

사용자로부터 수집 된 수락 기준이이 단계에서 사용됩니다. 샘플은 아래와 같이 보일 수 있습니다.

(CSTE CBOK에서 발췌 한 것입니다.이 테스트에 대해 사용할 수있는 가장 좋은 참조 중 하나입니다.)

사용자 수락 테스트 템플릿 :

기준에 따라 우리 (QA 팀)는 사용자에게 UAT 테스트 사례 목록을 제공합니다. 이러한 테스트 사례는 일반 시스템 테스트 사례와 다르지 않습니다. 핵심 기능 영역에 대해서만 반대되는 모든 애플리케이션을 테스트 할 수있는 부분 집합 일뿐입니다.

이 외에도 데이터, 테스트 결과를 기록하는 템플릿, 관리 절차, 결함 로깅 메커니즘, 다음 단계로 넘어 가기 전에 준비해야합니다.

테스트 실행

일반적으로이 테스트는 가능한 한 회의 나 전쟁 실에서 이루어집니다. 사용자, PM, QA 팀 대표가 모두 하루나 이틀 동안 함께 앉아 모든 승인 테스트 케이스를 처리하는 장소를 설정합니다.

또는 테스트를 수행하는 QA 팀의 경우 테스트를 실행합니다. AUT의 경우.

모든 테스트가 실행되고 결과가 준비되면 수락 결정이 내려집니다. 이를 Go / No-Go 결정이라고도합니다. 사용자가 만족한다면 Go 또는 No-Go입니다.

승인 결정에 도달하는 것이 일반적으로이 단계의 끝입니다.

도구 & 방법론

일반적으로이 테스트 단계에서 사용되는 소프트웨어 도구 유형은 기능 테스트를 수행하는 동안 사용되는 도구와 유사합니다.

도구 :

이 단계에는 애플리케이션의 완전한 종단 간 흐름을 검증하는 작업이 포함되므로이 검증을 완전히 자동화하는 하나의 도구를 사용하는 것이 어려울 수 있습니다. 그러나 시스템 테스트 중에 개발 된 자동화 된 스크립트를 어느 정도 활용할 수있을 것입니다.

시스템 테스트와 마찬가지로 사용자는 QC, JIRA 등과 같은 테스트 관리 및 결함 관리 도구를 사용할 수도 있습니다. 도구는 사용자 수락 단계에서 데이터를 누적하도록 구성 할 수 있습니다.

방법론 :

제품의 UAT를 수행하는 특정 비즈니스 사용자와 같은 기존의 방법론은 여전히 관련성이 있지만 진정한 글로벌 오늘날과 같이 사용자 수락 테스트는 제품에 따라 국가의 다양한 고객을 참여시켜야하는 경우가 있습니다.

예를 들어 전 세계 고객이 전자 상거래 웹 사이트를 사용합니다. 이와 같은 시나리오에서는 크라우드 테스트가 가장 실행 가능한 옵션이 될 것입니다.

크라우드 테스트는 전 세계의 사람들이 참여하고 제품 사용을 검증하고 제안 및 권장 사항을 제공 할 수있는 방법론입니다.

p>

크라우드 테스트 플랫폼이 구축되어 현재 많은 조직에서 사용되고 있습니다. 크라우드 테스트가 필요한 웹 사이트 또는 제품이 플랫폼에서 호스팅되며 고객은 검증을 수행 할 자신을 지명 할 수 있습니다. 그런 다음 제공된 피드백을 분석하고 우선 순위를 지정합니다.

전 세계 고객의 맥박을 쉽게 이해할 수 있기 때문에 군중 테스트 방법론이 더 효과적인 것으로 입증되었습니다.

UAT In Agile Environment

애자일 환경은 본질적으로 더 역동적입니다. 애자일 세계에서 비즈니스 사용자는 프로젝트 스프린트 전체에 참여하고 프로젝트는 피드백 루프를 기반으로 향상됩니다.

프로젝트 시작시 비즈니스 사용자는 주요 이해 관계자가됩니다. 요구 사항을 제공하여 제품 백 로그를 업데이트합니다. 각 스프린트가 끝날 때 비즈니스 사용자는 스프린트 데모에 참여하고 피드백을 제공 할 수 있습니다.

또한 비즈니스 사용자가 작업을 수행하는 스프린트 완료 전에 UAT 단계가 계획됩니다. 검증.

스프린트 데모 및 스프린트 UAT 중에 수신 된 피드백이 수집되어 지속적으로 검토되고 우선 순위가 지정된 제품 백 로그에 다시 추가됩니다. 따라서 민첩한 세상에서 비즈니스 사용자는 프로젝트에 더 가깝고 기존 폭포수 프로젝트와 달리 사용에 대해 동일하게 평가합니다.

UAT 팀 – 역할 & 책임

일반적인 UAT 조직은 다음과 같은 역할과 책임이 있습니다. UAT 팀은 필요에 따라 프로젝트 관리자, 개발 및 테스트 팀의 지원을받습니다.

UAT의 7 가지 과제 완화 계획

10 억 달러 규모의 릴리스에 속해 있든 스타트 업 팀에 속해 있든 상관없이 최종 사용자에게 성공적인 소프트웨어를 제공하려면 이러한 모든 문제를 극복해야합니다.

# 1) 환경 설정 및 배포 프로세스 :

기능 테스트 팀이 사용하는 것과 동일한 환경에서이 테스트를 수행하면 실제 사용 사례를 간과하게 될 것입니다. 또한 성능 테스트와 같은 중요한 테스트 활동은 테스트 데이터가 불완전한 테스트 환경에서 수행 할 수 없습니다.

이 테스트를 위해 별도의 프로덕션 환경을 설정해야합니다.

UAT 환경이 테스트 환경에서 분리되면 릴리스주기를 효과적으로 제어해야합니다. 제어되지 않은 릴리스주기는 테스트 및 UAT 환경에서 다른 소프트웨어 버전으로 이어질 수 있습니다. 소프트웨어가 최신 버전에서 테스트되지 않으면 귀중한 승인 테스트 시간이 낭비됩니다.

반면 잘못된 소프트웨어 버전에서 문제를 추적하는 데 필요한 시간이 깁니다.

# 2) 테스트 계획 :

이 테스트는 요구 사항 분석 및 설계 단계에서 명확한 승인 테스트 계획으로 계획되어야합니다.

전략 계획에서 실제 사용 사례 세트를 식별해야합니다. 실행을 위해. 이 테스트 단계에서는 대규모 애플리케이션에 대해 완전한 테스트 실행이 불가능하므로이 테스트에 대한 테스트 목표를 정의하는 것이 매우 중요합니다. 테스트는 중요한 비즈니스 목표의 우선 순위를 먼저 지정하여 수행해야합니다.

이 테스트는 테스트주기가 끝날 때 수행됩니다. 분명히 그것은 소프트웨어 릴리스에서 가장 중요한 기간입니다. 이전 개발 및 테스트 단계의 지연은 UAT 시간을 소모합니다.

부적절한 테스트 계획은 최악의 경우 시스템 테스트와 UAT가 겹치게합니다. 기한을 맞추기위한 시간과 부담이 적기 때문에 기능 테스트가 완료되지 않은 경우에도 소프트웨어가이 환경에 배포됩니다. 이러한 상황에서는이 테스트의 핵심 목표를 달성 할 수 없습니다.

이 테스트를 시작하기 훨씬 전에 UAT 테스트 계획을 준비하고 팀에 전달해야합니다. 이를 통해 테스트 계획, 테스트 사례 작성 및 UAT 환경 생성에 도움이됩니다.

# 3) 새로운 비즈니스 요구 사항을 사고 / 결함으로 처리 :

요구 사항의 모호성은 UAT 단계에서 포착됩니다. UAT 테스터는 모호한 요구 사항으로 인해 발생하는 문제를 찾아 내고 (요구 사항 수집 단계에서 사용할 수 없었던 완전한 UI를 확인하여) 결함으로 기록합니다.

고객은 변경 요청 시간을 고려하지 않고 현재 릴리스에서 수정 될 것으로 기대합니다. 이러한 최종 변경 사항에 대해 프로젝트 관리자가 적시에 결정을 내리지 않으면 릴리스 실패로 이어질 수 있습니다.

# 4) 비 숙련 테스터 또는 비즈니스 지식이없는 테스터 :

상근 팀이없는 경우 회사는 다양한 내부 부서에서 UAT 직원을 선발합니다.

직원이 비즈니스 요구 사항을 잘 알고 있거나 새로운 요구 사항에 대한 교육을받지 않은 경우에도 개발 중에는 효과적인 UAT를 수행 할 수 없습니다. 또한 비 기술적 인 비즈니스 팀은 테스트 사례를 실행하는 데 많은 기술적 어려움에 직면 할 수 있습니다.

반면 UAT주기가 끝날 때 테스터를 할당한다고해서 프로젝트에 가치가 추가되지는 않습니다. UAT 직원을 교육 할 시간이 거의 없으면 UAT 성공 가능성이 크게 높아질 수 있습니다.

# 5) 부적절한 커뮤니케이션 채널 :

원격 개발, 테스트 및 UAT 팀 간의 커뮤니케이션이 더 어렵습니다. . 해외 기술 팀이있는 경우 이메일 커뮤니케이션은 종종 매우 어렵습니다. 사고 보고서의 사소한 모호함으로 인해 하루 동안 수정이 지연 될 수 있습니다.

적절한 계획과 효과적인 커뮤니케이션은 효과적인 팀 협업에 매우 중요합니다. 프로젝트 팀은 웹 기반 도구를 사용하여 결함과 질문을 기록해야합니다. 이렇게하면 작업 부하를 균등하게 분산하고 중복 문제보고를 방지하는 데 도움이됩니다.

# 6) 기능 테스트 팀에이 테스트를 수행하도록 요청 :

기능 테스트를 요청하는 것보다 더 나쁜 상황은 없습니다. 팀이 UAT를 수행합니다.

고객은 리소스 부족으로 인해 자신의 책임을 테스트 팀에 넘깁니다. 이러한 경우이 테스트의 전체 목적이 손상됩니다. 소프트웨어가 출시되면 최종 사용자는 기능 테스터가 실제 시나리오로 간주하지 않는 문제를 신속하게 발견 할 수 있습니다.

이에 대한 해결책은이 테스트를 숙련 된 전담자에게 할당하는 것입니다. 비즈니스 지식이있는 테스터.

# 7) 비난 게임

때때로 비즈니스 사용자는 소프트웨어를 거부 할 이유를 찾으려고합니다. 자신이 얼마나 우월한 지 보여 주거나 비즈니스 팀에서 존경심을 얻기 위해 개발 및 테스트 팀을 비난하는 것은 그들의 자아 일 수 있습니다. 매우 드물지만 내부 정치가있는 팀에서 발생합니다.

이러한 상황을 처리하기가 매우 어렵습니다. 그러나 비즈니스 팀과 긍정적 인 관계를 구축하면 비난을 피하는 데 확실히 도움이 될 것입니다.

이 지침이 다양한 문제를 극복하여 성공적인 사용자 수용 계획을 실행하는 데 확실히 도움이되기를 바랍니다. 적절한 계획, 의사 소통, 실행 및 동기 부여 된 팀은 성공적인 사용자 수용 테스트의 핵심입니다.

시스템 테스트 대 사용자 수용 테스트

테스트 팀의 참여는 초기에 시작됩니다. 요구 사항 분석 단계에서 바로 프로젝트.

모든 프로젝트 수명주기 동안 프로젝트에 대해 일종의 유효성 검사 (예 : 정적 테스트, 단위 테스트, 시스템 테스트, 통합 테스트, 엔드 투 엔드 테스트)가 수행됩니다. 또는 회귀 테스트. 이를 통해 UAT 단계에서 수행 된 테스트와 이전에 수행 된 다른 테스트와 얼마나 다른지 더 잘 이해할 수 있습니다.

SIT와 UAT의 차이를 보았지만 시너지를 활용하는 것이 중요합니다. 그러나 시장 출시 시간을 단축 할 수있는 두 단계 간의 독립성을 유지합니다.

결론

# 1) UAT는 페이지, 필드 또는 버튼에 관한 것이 아닙니다. 이 테스트가 시작되기 전에도 기본 가정은 모든 기본 사항이 테스트되고 잘 작동한다는 것입니다. 신 이시여, 사용자는 버그를 기본적으로 발견합니다. 이것은 QA 팀에게 매우 나쁜 소식입니다. : (

# 2)이 테스트는 비즈니스의 주요 요소 인 엔티티에 관한 것입니다.

예를 들어 보겠습니다. AUT가 티켓팅 시스템 인 경우 UAT는 페이지를 여는 메뉴를 검색하는 것이 아니라 티켓과 예약, 소요 가능한 상태, 시스템을 통한 여정 등에 관한 것입니다.

또 다른 예로, 사이트가 자동차 대리점 사이트 인 경우 실제 사이트가 아닌 “자동차 및 판매”에 초점이 맞춰져 있습니다. 따라서 핵심 비즈니스는 검증 및 검증 된 사이트보다 누가 더 나은지를 확인하는 것입니다. 그렇기 때문에이 테스트는 고객이 많은 부분에 관여 할 때 가장 합리적입니다.

# 3) UAT는 또한 핵심 테스트의 한 형태이며, 이는 좋은 기회가 있음을 의미합니다. 이 단계에서 일부 버그도 식별합니다. 가끔 발생합니다. QA 팀의 주요 에스컬레이션이라는 사실을 제외하고 UAT 버그는 일반적으로 회의에 앉아서이를 처리하는 방법을 논의하는 것을 의미합니다. 이 테스트에는 일반적으로 수정하고 다시 테스트 할 시간이 없습니다.

결정은 다음 중 하나입니다.

• 실행 날짜를 입력하고 먼저 문제를 수정 한 다음 계속 진행합니다.
• 버그는 그대로 둡니다.
• 향후 릴리스에 대한 변경 요청의 일부로 간주하십시오.

# 4) UAT는 알파 및 베타 테스트로 분류되지만 그 분류는 그다지 중요하지 않습니다. 서비스 기반 산업의 일반적인 소프트웨어 개발 프로젝트의 맥락에서.

• 알파 테스트는 UAT가 소프트웨어 빌더의 환경에서 수행되는 경우이며, 상용 기성품의 맥락에서 더 중요합니다. 소프트웨어.
• 베타 테스트는 UAT가 프로덕션 환경 또는 클라이언트 환경에서 수행되는 경우입니다. 이는 고객 대면 애플리케이션에서 더 일반적입니다. 여기의 사용자는이 맥락에서 당신과 저와 같은 실제 고객입니다.

# 5) 정규 소프트웨어 개발 프로젝트에서 대부분의 경우 UAT는 QA 환경에서 수행됩니다. 스테이징 또는 UAT 환경이 없습니다.

간단히 말해서 제품이 허용되고 목적에 적합한 지 확인하는 가장 좋은 방법은 실제로 사용자 앞에 놓는 것입니다.

조직은 민첩한 전달 방식을 사용하고 있으며 비즈니스 사용자는 더 많이 참여하고 있으며 프로젝트는 피드백 루프를 통해 향상되고 전달됩니다. 모든 작업이 완료되면 사용자 수락 단계가 구현 및 생산에 들어가는 관문으로 간주됩니다.

UAT 경험은 어땠습니까? 대기 중 이었습니까? 아니면 사용자를 위해 테스트 했습니까? 사용자가 문제를 발견 했습니까? 그렇다면 어떻게 처리 했습니까?

= > 또한 여기에서이 시리즈의 모든 자습서를 읽으십시오.

= > 전체 테스트 계획 자습서 시리즈를 보려면 여기를 방문하십시오.