what is user acceptance testing
정의, 유형, 단계 및 예와 함께 UAT (User Acceptance Testing)가 무엇인지 알아보세요.
새로운 개념을 이해하려고 할 때 가장 중요한 규칙은 다음과 같습니다. 이름은 항상 관련성이 있으며 대부분 문자 그대로의 의미입니다. (기술적 맥락에서).
그것이 무엇인지 알아내는 것은 그것에 대한 초기 이해를 제공하고 시작하는 데 도움이 될 것입니다.
SQL과 SQL Server의 차이점은 무엇입니까
=> 전체 테스트 계획 튜토리얼 시리즈를 보려면 여기를 클릭하십시오.
이 개념을 테스트 해 보겠습니다.
=> 모든 튜토리얼 읽기 수락 테스트 시리즈에서.
학습 내용 :
사용자 수락 테스트 란 무엇입니까?
우리는 테스트가 무엇인지 알고 있으며, 수락은 승인 또는 동의를 의미합니다. 소프트웨어 제품의 맥락에서 사용자는 소프트웨어의 소비자이거나 소프트웨어를 구축하도록 요청한 사람 (클라이언트)입니다.
따라서 내 규칙에 따라 정의는 다음과 같습니다.
베타 또는 최종 사용자 테스트라고도하는 UAT (사용자 수락 테스트)는 사용자 또는 클라이언트가 소프트웨어를 수락 할 수 있는지 여부를 결정하기 위해 소프트웨어를 테스트하는 것으로 정의됩니다. 이것은 기능, 시스템 및 회귀 테스트가 완료되면 수행되는 최종 테스트입니다.
이 테스트의 주요 목적은 비즈니스 요구 사항에 대해 소프트웨어를 검증하는 것입니다. 이 유효성 검사는 비즈니스 요구 사항에 익숙한 최종 사용자가 수행합니다.
UAT, 알파 및 베타 테스트 다른 유형의 승인 테스트입니다.
사용자 승인 테스트는 소프트웨어가 출시되기 전에 수행되는 마지막 테스트이므로 분명히 고객이 소프트웨어를 테스트하고 목적에 맞는지 측정 할 수있는 마지막 기회입니다.
언제 수행됩니까?
이는 일반적으로 제품이 출시되기 전 또는 제품 배송이 수락되기 전 마지막 단계입니다. 이는 제품 자체를 철저히 테스트 한 후에 수행됩니다 (예 : 시스템 테스트 후 ).
누가 UAT를 수행합니까?
사용자 또는 클라이언트 – 제품을 구매하는 사람 (상용 소프트웨어의 경우) 또는 소프트웨어 서비스 제공 업체를 통해 맞춤 제작 된 소프트웨어를 보유한 사람 또는 소프트웨어가 제공되는 경우 최종 사용자가 될 수 있습니다. 미리 그리고 그들의 피드백을 구할 때.
팀은 베타 테스터로 구성되거나 고객이 조직의 모든 그룹에서 내부적으로 UAT 구성원을 선택하여 각 사용자 역할을 그에 따라 테스트 할 수 있도록해야합니다.
사용자 수락 테스트 필요
개발자 및 기능 테스터는 소프트웨어를 검증하는 기술 인력입니다. 기능 사양 . 지식에 따라 요구 사항을 해석하고 소프트웨어를 개발 / 테스트합니다 (여기에 도메인 지식의 중요성이 있습니다).
이 소프트웨어는 기능 사양에 따라 완전하지만 최종 사용자에게만 알려진 일부 비즈니스 요구 사항 및 프로세스가 통신을 놓치거나 잘못 해석됩니다.
이 테스트는 시장 용 소프트웨어를 출시하기 전에 모든 비즈니스 요구 사항이 충족되었는지 여부를 확인하는 데 중요한 역할을합니다. 라이브 데이터와 실제 사용 사례를 사용하면이 테스트가 릴리스주기의 중요한 부분이됩니다.
출시 후 문제로 인해 큰 손실을 입은 많은 기업은 성공적인 사용자 수락 테스트의 중요성을 알고 있습니다. 출시 후 결함을 수정하는 비용은 이전 수정보다 몇 배 더 큽니다.
UAT가 정말 필요한가요?
많은 시스템, 통합 및 회귀 테스트를 수행 한 후이 테스트의 필요성에 대해 궁금해 할 것입니다. 실제로 이것은 시스템을 실제로 사용할 사용자가 시스템이 목적에 맞는지 확인하는 시간이기 때문에 프로젝트에서 가장 중요한 단계입니다.
UAT는 최종 사용자의 관점과 최종 사용자를 대표하는 부서의 도메인 지식에 크게 좌우되는 테스트 단계입니다.
사실, 비즈니스 팀이 프로젝트에 아주 일찍 참여했다면 실제로 시스템을 효과적으로 사용하는 데 도움이되는 견해와 기여를 제공 할 수 있다면 정말 도움이 될 것입니다.
사용자 수락 테스트 프로세스
이 프로세스를 이해하는 가장 쉬운 방법은이를 자율 테스트 프로젝트로 생각하는 것입니다. 즉, 계획, 설계 및 실행 단계를 갖게됩니다.
다음은 계획 단계가 시작되기 전의 전제 조건입니다.
# 1) 주요 수락 기준 수집
간단히 말해서, 수락 기준은 제품을 수락하기 전에 평가 될 항목의 목록입니다.
두 가지 유형이 있습니다.
(i) 애플리케이션 기능 또는 비즈니스 관련
이상적으로는 모든 주요 비즈니스 기능의 유효성을 검사해야하지만 시간을 포함한 다양한 이유로 인해 모든 작업을 수행하는 것은 실용적이지 않습니다. 따라서이 테스트에 참여할 클라이언트 또는 사용자와의 만남은 얼마나 많은 테스트가 관련되고 어떤 측면이 테스트 될 것인지에 대한 아이디어를 제공 할 수 있습니다.
(ii) 계약 – 우리는 이것에 대해 다루지 않을 것이며이 모든 것에 QA 팀의 참여는 거의 아무것도 아닙니다. SDLC가 시작되기 전에 작성된 초기 계약이 검토되고 계약의 모든 측면이 전달되었는지 여부에 대한 합의가 이루어집니다.
응용 프로그램 기능에만 초점을 맞출 것입니다.
# 2) 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를 수행하는 특정 비즈니스 사용자와 같은 기존의 방법론은 여전히 관련이 있지만 오늘날과 같은 진정한 글로벌 세계에서 사용자 수락 테스트는 때때로 제품을 기반으로 국가의 다양한 고객을 참여시켜야합니다.
예를 들어, 전자 상거래 웹 사이트는 전 세계 고객이 사용할 것입니다. 이와 같은 시나리오에서는 군중 테스트가 가장 실행 가능한 옵션이 될 것입니다.
군중 테스트 전 세계의 사람들이 참여하여 제품 사용을 검증하고 제안 및 권장 사항을 제공 할 수있는 방법론입니다.
크라우드 테스트 플랫폼이 구축되어 현재 많은 조직에서 사용되고 있습니다. 크라우드 테스트가 필요한 웹 사이트 또는 제품이 플랫폼에서 호스팅되며 고객은 검증을 수행 할 자신을 지명 할 수 있습니다. 그런 다음 제공된 피드백을 분석하고 우선 순위를 지정합니다.
크라우드 테스트 방법론은 전 세계 고객의 맥박을 쉽게 이해할 수 있기 때문에 더 효과적인 것으로 입증되었습니다.
애자일 환경의 UAT
애자일 환경은 본질적으로 더 역동적입니다. 애자일 세계에서 비즈니스 사용자는 프로젝트 스프린트 전체에 참여하고 이들의 피드백 루프를 기반으로 프로젝트가 향상됩니다.
애니메이션을 무료로 시청할 수있는 애니메이션 웹 사이트
프로젝트를 시작할 때 비즈니스 사용자는 요구 사항을 제공하여 제품 백 로그를 업데이트하는 주요 이해 관계자가됩니다. 각 스프린트가 끝날 때 비즈니스 사용자는 스프린트 데모에 참여하고 피드백을 제공 할 수 있습니다.
또한 비즈니스 사용자가 검증을 수행하는 스프린트 완료 전에 UAT 단계가 계획됩니다.
스프린트 데모 및 스프린트 UAT 중에 수신 된 피드백은 수집되어 지속적으로 검토되고 우선 순위가 지정된 제품 백 로그에 다시 추가됩니다. 따라서 민첩한 세계에서 비즈니스 사용자는 프로젝트에 더 가깝고 기존 폭포 프로젝트와 달리 사용에 대해 동일하게 평가합니다.
UAT 팀 – 역할 및 책임
일반적인 UAT 조직에는 다음과 같은 역할과 책임이 있습니다. UAT 팀은 필요에 따라 프로젝트 관리자, 개발 및 테스트 팀의 지원을받습니다.
| 역할 | 책임 | 결과물 |
|---|---|---|
| 비즈니스 프로그램 관리자 | • 프로그램 제공 계획 생성 및 유지 • UAT 테스트 전략 및 계획 검토 및 승인 • 일정과 예산에 따라 프로그램을 성공적으로 완료합니다. • IT 프로그램 관리자와 연락하고 프로그램 진행 상황을 모니터링합니다. • 비즈니스 운영 팀과 긴밀히 협력하고 1 일차 운영에 대비 • 사인 오프 비즈니스 요구 사항 문서 • e- 러닝 코스 내용 검토 | • 프로그램 진행 보고서 • 주간 상태 보고서 |
| UAT 테스트 관리자 | • Crete UAT 전략 • IT와 비즈니스 BA 및 PMO 간의 효과적인 협업 보장 • 요구 사항 연습 회의에 참여 • 노력 추정, 테스트 계획 검토 • 요구 사항 추적 성 보장 • 업데이트 된 테스트 방법, 도구 및 환경 사용에서 파생 된 이점을 정량화하기 위해 메트릭 수집을 추진합니다. | • 마스터 테스트 전략 • 테스트 시나리오 검토 및 승인 • 테스트 사례 검토 및 승인 • 요구 사항 추적 성 매트릭스 검토 및 승인 • 주간 현황 보고서 |
| UAT 테스트 리드 및 팀 | • 비즈니스 프로세스에 대한 비즈니스 요구 사항 확인 및 검증 • UAT 추정 • UAT 테스트 계획 생성 및 실행 • 요구 사항 JAD 세션에 참여 • 비즈니스 프로세스를 기반으로 테스트 시나리오, 테스트 사례 및 테스트 데이터 준비 • 추적 성 유지 • 테스트 케이스 실행 및 테스트 로그 준비 • 테스트 관리 도구에서 결함을보고하고 수명주기 동안 관리 • 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를 수행하도록 요청하는 것보다 더 나쁜 상황은 없습니다.
고객은 리소스 부족으로 인해 자신의 책임을 테스트 팀에 맡깁니다. 이러한 경우이 테스트의 전체 목적이 손상됩니다. 소프트웨어가 활성화되면 최종 사용자는 기능 테스터가 실제 시나리오로 간주하지 않는 문제를 신속하게 발견 할 수 있습니다.
이에 대한 해결책은이 테스트를 비즈니스 지식이있는 전문적이고 숙련 된 테스터에게 할당하는 것입니다.
YouTube를 mp4 고품질로 변환
# 7) 비난 게임
때때로 비즈니스 사용자는 소프트웨어를 거부 할 이유를 찾으려고합니다. 자신이 얼마나 우월한 지 보여 주거나 비즈니스 팀에서 존경을 받기 위해 개발 및 테스트 팀을 비난하는 것이 자신의 자아 일 수 있습니다. 이것은 매우 드물지만 내부 정치가있는 팀에서 발생합니다.
그런 상황에 대처하는 것은 매우 어렵습니다. 그러나 비즈니스 팀과 긍정적 인 관계를 구축하는 것은 비난 게임을 피하는 데 확실히 도움이 될 것입니다.
이 지침이 다양한 문제를 극복하여 성공적인 사용자 수용 계획을 실행하는 데 확실히 도움이되기를 바랍니다. 적절한 계획, 의사 소통, 실행 및 동기 부여 된 팀은 성공적인 사용자 승인 테스트의 핵심입니다.
시스템 테스트 대 사용자 수락 테스트
테스트 팀의 참여는 요구 사항 분석 단계에서 바로 프로젝트 초기에 시작됩니다.
프로젝트 수명주기 전반에 걸쳐 프로젝트에 대해 일종의 유효성 검사가 수행됩니다. 정적 테스트 , 단위 테스트, 시스템 테스트, 통합 테스트, 종단 간 테스트 또는 회귀 테스트. 따라서 UAT 단계에서 수행 한 테스트와 이전에 수행 한 다른 테스트와의 차이점을 더 잘 이해할 수 있습니다.
SIT와 UAT의 차이를 보았지만 시너지를 활용하면서도 시장 출시 시간을 단축 할 수있는 두 단계 사이의 독립성을 유지하는 것이 중요합니다.
결론
#1) UAT는 페이지, 필드 또는 버튼에 관한 것이 아닙니다. 기본 인수 이 테스트가 시작되기 전에도 모든 기본 사항이 테스트되고 잘 작동합니다. 사용자는 버그를 기본적으로 발견합니다. 이것은 QA 팀에게 매우 나쁜 소식입니다. :(
#두) 이 테스트는 비즈니스의 기본 요소 인 엔터티에 대한 것입니다.
예를 들어 보겠습니다. AUT가 발권 시스템 인 경우 UAT는 페이지를 여는 메뉴를 검색하는 등의 작업이 아닙니다. 티켓 및 예약, 걸릴 수있는 상태, 시스템을 통한 여정, 기타
다른 예, 사이트가 자동차 대리점 사이트 인 경우 초점은 실제 사이트가 아닌 '자동차 및 판매'에 있습니다. 따라서 핵심 비즈니스는 검증되고 검증 된 것이며 비즈니스 소유자보다 더 나은 사람입니다. 그렇기 때문에이 테스트는 고객이 어느 정도 관여 할 때 가장 합리적입니다.
#삼) UAT는 또한 핵심 테스트의 한 형태입니다. 이 단계에서도 일부 버그를 식별 할 수있는 좋은 기회가 있습니다. . 때때로 발생합니다. QA 팀의 주요 에스컬레이션이라는 사실을 제외하고 UAT 버그는 일반적으로 회의를 의미하며이 테스트 이후에 문제를 처리하는 방법을 논의하는 회의를 의미하며 일반적으로 수정하고 다시 테스트 할 시간이 없습니다.
결정은 다음 중 하나입니다.
- 가동 날짜를 푸시하고 먼저 문제를 수정 한 다음 계속 진행하십시오.
- 버그는 그대로 둡니다.
- 향후 릴리스에 대한 변경 요청의 일부로 고려하십시오.
# 4) UAT는 알파 및 베타 테스트로 분류되지만 서비스 기반 산업의 일반적인 소프트웨어 개발 프로젝트에서 그 분류는 그다지 중요하지 않습니다.
- 알파 테스트 UAT가 소프트웨어 빌더의 환경에서 수행되는 경우이며 상용 소프트웨어의 맥락에서 더 중요합니다.
- 베타 테스트 UAT가 프로덕션 환경 또는 클라이언트 환경에서 수행되는 경우입니다. 이는 고객 대면 애플리케이션에서 더 일반적입니다. 여기의 사용자는이 맥락에서 당신과 저와 같은 실제 고객입니다.
# 5) 정규 소프트웨어 개발 프로젝트에서 대부분의 경우 UAT는 QA 환경 스테이징 또는 UAT 환경이없는 경우.
요컨대 제품이 허용되고 목적에 적합한 지 확인하는 가장 좋은 방법은 실제로 사용자에게 제품을 배치하는 것입니다.
조직은 민첩한 전달 방식을 사용하고 있으며 비즈니스 사용자는 더 많이 참여하고 있으며 프로젝트는 피드백 루프를 통해 향상되고 전달되고 있습니다. 모든 작업이 완료되면 사용자 수락 단계가 구현 및 생산에 들어가는 관문으로 간주됩니다.
UAT 경험은 어땠습니까? 대기 중 이었습니까 아니면 사용자를 위해 테스트 했습니까? 사용자가 문제를 발견 했습니까? 그렇다면 어떻게 처리 했습니까?
=> 이 시리즈의 모든 튜토리얼도 여기에서 읽으십시오.
=> 전체 테스트 계획 자습서 시리즈를 보려면 여기를 방문하십시오.