what is acceptance testing
수락 테스트 소개 (1 부) :
이 튜토리얼 시리즈에서는 다음을 학습합니다.
시스템 테스트를 마쳤습니까? 대부분의 버그가 수정 되었습니까? 버그가 확인되고 종료 되었습니까? 그럼 다음은 뭐죠?
다음 목록에는 소프트웨어 테스트 프로세스의 마지막 단계 인 수락 테스트가 있습니다. . 고객이 결정하는 단계입니다. GO / No-GO 제품을 시장에 출시하기 전에 반드시 따라야합니다. 개발 및 테스트 팀의 공동 노력은 개발 된 제품을 수락하거나 거부함으로써 고객이 수여합니다.
수락 테스트에 대한이 고유 한 자습서는 더 나은 이해를 위해 간단하고 쉬운 방식으로 수락 테스트와 관련된 의미, 유형, 용도 및 다양한 기타 요소에 대한 전체 개요를 제공합니다.
학습 내용 :
- 수락 테스트 란 무엇입니까?
- 승인 테스트를하는 이유
- 종류
- 수락 테스트는 누구입니까?
- 합격 테스터의 자질
- 사용하다
- 시스템 테스트, 수락 테스트 및 사용자 수락 테스트의 차이점
- 수락 테스트
- 수용 테스트 베드
- AT 입출국 기준
- 수락 테스트 프로세스
- 이 테스트의 성공 요인
- 결론
- 추천 도서
수락 테스트 란 무엇입니까?
일단 시스템 테스트 프로세스 테스트 팀에 의해 완료되고 승인되면 전체 제품 / 애플리케이션이 고객 / 고객의 소수 사용자 / 둘 다에게 넘겨져 수용 가능성을 테스트합니다. 즉, 제품 / 애플리케이션이 중요 및 주요 비즈니스 요구 사항. 또한 종단 간 비즈니스 흐름은 실시간 시나리오와 유사하게 확인됩니다.
프로덕션과 유사한 환경은 테스트 수락을위한 테스트 환경이 될 것입니다 (일반적으로 스테이징, 프리 프로덕션, 장애 조치, UAT 환경이라고 함).
이것은 블랙 박스 테스트 기술 제품이 지정된 허용 기준을 충족하는지 확인하기 위해 기능 만 검증되는 경우 (설계 / 구현 지식이 필요 없음)
승인 테스트를하는 이유
시스템 테스트가 성공적으로 완료되었지만 고객이 수락 테스트를 요구합니다. 여기서 수행되는 테스트는 시스템 테스트에서 다루었으므로 반복적입니다.
그렇다면이 테스트는 왜 고객이 수행합니까?
이 때문입니다:
- 시장에 출시되는 제품에 대한 자신감을 얻기 위해.
- 제품이 필요한 방식으로 작동하는지 확인합니다.
- 제품이 현재 시장 표준과 일치하고 시장의 다른 유사한 제품과 충분히 경쟁력이 있는지 확인합니다.
종류
이 테스트에는 여러 유형이 있습니다.
그 중 몇 가지가 아래에 나열되어 있습니다.
# 1) 사용자 수락 테스트 (UAT)
UAT는 제품이 사용자를 위해 올바르게 작동하는지 여부를 평가하는 것입니다. 최종 사용자가 자주 사용하는 특정 요구 사항은 주로 테스트 목적으로 선택됩니다. 이를 최종 사용자 테스트라고도합니다.
여기에서 '사용자'라는 용어는 제품 / 애플리케이션을 대상으로하는 최종 사용자를 의미하므로 최종 사용자의 관점과 관점에서 테스트가 수행됩니다.
=> 또한 읽다: 사용자 수락 테스트 (UAT) 란 무엇입니까?
# 2) 비즈니스 수락 테스트 (BAT)
이는 제품이 비즈니스 목표 및 목적을 충족하는지 여부를 평가하기위한 것입니다.
BAT는 주로 변화하는 시장 조건 / 발전 기술로 인해 상당히 어려운 비즈니스 이점 (금융)에 초점을 맞추고 있으므로 현재 구현이 변경되어 추가 예산이 발생해야 할 수 있습니다.
최고의 맬웨어 제거 소프트웨어는 무엇입니까
기술 요구 사항을 통과 한 제품조차도 이러한 이유로 인해 BAT에 실패 할 수 있습니다.
# 3) 계약 수락 테스트 (CAT)
이것은 제품이 출시되면 미리 정해진 기간 내에 승인 테스트를 수행하고 모든 승인 사용 사례를 통과해야 함을 지정하는 계약입니다.
여기에 서명 된 계약은 서비스 수준 계약 (SLA)이라고하며 여기에는 제품 서비스가 모든 요구 사항과 일치하여 계약이 이행 된 경우에만 결제가 이루어지는 조건이 포함됩니다.
때때로이 계약은 제품이 출시되기 전에 발생할 수 있습니다. 어느 쪽이든 테스트 기간, 테스트 영역, 이후 단계에서 발생하는 문제에 대한 조건, 지불 등의 측면에서 계약을 잘 정의해야합니다.
# 4) 규정 /응낙수락 테스트 (RAT)
이는 제품이 출시되는 국가의 정부에서 정한 규칙 및 규정을 위반하는지 여부를 평가하기위한 것입니다. 이는 의도하지 않았을 수 있지만 비즈니스에 부정적인 영향을 미칩니다.
일반적으로 전 세계에 출시 될 예정인 개발 된 제품 / 애플리케이션은 RAT를 거쳐야합니다. 국가 / 지역마다 관리 기관에서 정의한 규칙과 규정이 다르기 때문입니다.
특정 국가의 규칙 및 규정을 위반하는 경우 해당 국가 또는 해당 국가의 특정 지역은 제품 사용이 허용되지 않으며 실패로 간주됩니다. 위반 사항이 있더라도 제품이 출시되는 경우 제품 공급 업체는 직접 책임을집니다.
# 5) 운영 승인 테스트 (OAT)
이는 제품의 작동 준비 상태를 평가하기위한 것이며 비 기능 테스트입니다. 주로 복구, 호환성, 유지 관리 가능성, 기술 지원 가용성, 안정성, 장애 조치, 현지화 등에 대한 테스트가 포함됩니다.
OAT는 주로 제품을 생산에 출시하기 전에 제품의 안정성을 보장합니다.
# 6) 알파 테스트
이는 일반적으로 알파 테스터라고하는 전문 테스터 팀이 개발 / 테스트 환경에서 제품을 평가하기위한 것입니다. 여기에서 테스터 피드백, 제안은 제품 사용을 개선하고 특정 버그를 수정하는 데 도움이됩니다.
여기서 테스트는 통제 된 방식으로 이루어집니다.
=> 또한 읽으십시오 : 알파 테스트 란 무엇입니까?
# 7) 베타 테스트 / 현장 테스트
이는 일반적으로 베타 테스터 / 베타 사용자라고하는 실제 최종 사용자에게 제품을 노출하여 제품을 평가하는 것입니다. 사용자의 지속적인 피드백을 수집하고 문제를 해결합니다. 또한 풍부한 사용자 경험을 제공하기 위해 제품을 향상 / 개선하는 데 도움이됩니다.
테스트는 통제되지 않은 방식으로 이루어집니다. 즉, 사용자는 제품 사용 방식에 제한이 없습니다.
=> 또한 읽으십시오 : 베타 테스트 란 무엇입니까?
이러한 모든 유형에는 공통된 목표가 있습니다.
- 제품에 대한 신뢰를 얻거나 강화하십시오.
- 실제 사용자가 제품을 사용할 준비가되었는지 확인하십시오.
수락 테스트는 누구입니까?
Alpha 유형의 경우 조직의 구성원 (제품을 개발 한 사람) 만 테스트를 수행합니다. 이러한 구성원은 프로젝트 (프로젝트 관리자 / 리드, 개발자, 테스터)의 직접적인 일부가 아닙니다. 관리, 영업, 지원 팀은 일반적으로 테스트를 수행하고 그에 따라 피드백을 제공합니다.
알파 유형을 제외하고 다른 모든 승인 유형은 일반적으로 서로 다른 이해 관계자가 수행합니다. 고객, 고객의 고객, 조직의 전문 테스터 (항상 그런 것은 아님).
유형에 따라이 테스트를 수행하는 동안 비즈니스 분석가 및 주제 전문 지식을 참여시키는 것도 좋습니다.
합격 테스터의 자질
아래 자질을 가진 테스터는 합격 테스터로 자격이 있습니다.
- 논리적이고 분석적으로 생각하는 능력.
- 좋은 도메인 지식.
- 시장에서 경쟁 제품을 연구하고 개발 된 제품에 대해 분석 할 수 있습니다.
- 테스트하는 동안 최종 사용자 인식.
- 각 요구 사항에 대한 비즈니스 요구 사항을 이해하고 그에 따라 테스트합니다.
이 테스트 중에 발견 된 문제의 영향
수락 테스트 단계에서 발생하는 모든 문제는 우선 순위가 높은 문제로 간주하고 즉시 수정해야합니다. 또한 발견 된 모든 문제에 대해 근본 원인 분석을 수행해야합니다.
테스트 팀은 수락 문제에 대한 RCA를 제공하는 데 중요한 역할을합니다. 또한 테스트가 얼마나 효율적으로 수행되는지 결정하는 데 도움이됩니다.
또한 수용 테스트의 유효한 문제는 인상, 평가, 고객 설문 조사 등의 측면에서 테스트 및 개발 팀의 노력에 모두 영향을 미칩니다. 때로는 유효성 검사에 대한 테스트 팀의 무지가 발견되면 에스컬레이션으로 이어집니다.
사용하다
이 테스트는 여러 측면에서 유용합니다.
그중 일부는 다음과 같습니다.
- 기능 테스트 단계에서 놓친 문제를 파악합니다.
- 제품이 얼마나 잘 개발되었는지.
- 제품은 실제로 고객이 필요로하는 것입니다.
- 피드백 / 설문 조사는 제품 성능 및 사용자 경험을 개선하는 데 도움이됩니다.
- RCA를 입력으로 사용하여 프로세스를 개선하십시오.
- 생산 제품에서 발생하는 문제를 최소화하거나 제거합니다.
시스템 테스트, 수락 테스트 및 사용자 수락 테스트의 차이점
이 세 가지 유형의 수락 테스트 간의 주요 차이점은 다음과 같습니다.
| 시스템 테스트 | 수락 테스트 | 사용자 수락 테스트 |
|---|---|---|
| 양성 및 음성 테스트가 수행됩니다. | 일반적으로 양성 검사가 수행됩니다. | 양성 테스트 만 수행됩니다. |
| 제품이 지정된 모든 요구 사항을 충족하는지 확인하기 위해 종단 간 테스트가 수행됩니다. | 제품이 고객의 수용 요건을 충족하는지 확인하기 위해 테스트가 수행됩니다. | 최종 사용자 요구 사항이 수용 가능성을 충족하는지 확인하기 위해 테스트가 수행됩니다. |
| 제품은 기능적 및 비 기능적 요구에만 집중하여 전체적으로 테스트됩니다. | 제품은 사용자 수용 가능성, 비즈니스 목표, 규칙 및 규정, 운영 등 비즈니스 요구 사항에 대해 테스트됩니다. | 제품은 사용자 허용 여부에 대해서만 테스트되었습니다. |
| 테스트 팀은 시스템 테스트를 수행합니다. | 고객, 고객 고객, 테스터 (드물게), 관리, 영업, 지원팀은 수행되는 테스트 유형에 따라 인수 테스트를 수행합니다. | 고객, 고객의 고객, 테스터 (드물게) 사용자 승인 테스트 수행 |
| 테스트 케이스 작성 및 실행 | 수락 테스트가 작성되고 실행됩니다. | 사용자 수락 테스트가 작성되고 실행됩니다. |
| 작동 및 비 작동 가능 | 일반적으로 기능적이지만 RAT, OAT 등의 경우 작동하지 않습니다. | 기능 만 |
| 테스트에는 테스트 데이터 만 사용됩니다. | 실시간 데이터 / 생산 데이터는 테스트에 사용됩니다. | 실시간 데이터 / 생산 데이터를 테스트에 사용 |
| 발견 된 문제는 버그로 간주되며 심각도와 우선 순위에 따라 수정됩니다. | 발견 된 문제는 제품을 실패로 표시하고 즉시 수정 된 것으로 간주됩니다. | 발견 된 문제는 제품을 실패로 표시하고 즉시 수정 된 것으로 간주됩니다. |
| 통제 된 테스트 방식 | 테스트 유형에 따라 제어 또는 비 제어 가능 | 통제되지 않은 테스트 방식 |
| 개발 환경에서 테스트 | 유형에 따라 개발 환경 또는 사전 프로덕션 환경 또는 프로덕션 환경에서 테스트 | 테스트는 항상 프로덕션 전 환경에서 진행됩니다. |
| 가정은 없지만 전달할 수있는 경우 | 가정 없음 | 가정 없음 |
수락 테스트
제품 테스트 케이스와 마찬가지로 승인 테스트가 있습니다. 수락 테스트는 사용자 스토리의 수락 기준에서 파생됩니다. 이는 일반적으로 제품이 서로 다른 조건에서 수행해야하는 작업에 대한 높은 수준의 세부 정보로 작성된 시나리오입니다.
테스트 케이스에서와 같이 테스트 수행 방법에 대한 명확한 그림을 제공하지 않습니다. 합격 테스트는 일반적으로 주제별 전문성 인 제품을 완전히 파악한 테스터가 작성합니다. 작성된 모든 테스트는 고객 및 / 또는 비즈니스 분석가가 검토합니다.
이러한 테스트는 수락 테스트 중에 실행되었습니다. 승인 테스트와 함께 수행 할 설정에 대한 자세한 문서를 준비해야합니다. 적절한 스크린 샷, 설정 값, 조건 등과 함께 모든 분 세부 정보를 포함해야합니다.
수용 테스트 베드
이 테스트를위한 테스트 베드는 일반 테스트 베드와 유사하지만 별도의 베드입니다. 필요한 모든 하드웨어, 소프트웨어, 운영 제품, 네트워크 설정 및 구성, 서버 설정 및 구성, 데이터베이스 설정 및 구성, 라이센스, 플러그인 등이있는 플랫폼은 매우 비슷하게 설정되어야합니다. 생산 환경.
수락 테스트 베드는 설계된 수락 테스트가 실행되는 플랫폼 / 환경입니다. 수락 테스트 환경을 고객에게 넘기기 전에 제품의 환경 문제와 안정성을 확인하는 것이 좋습니다.
승인 테스트를위한 별도의 환경이 설정되지 않은 경우 해당 목적을 위해 정기적 인 테스트 환경을 사용할 수 있습니다. 하지만 여기서는 정기 시스템 테스트의 테스트 데이터와 인수 테스트의 실시간 데이터가 단일 환경에서 유지되기 때문에 지저분해질 것입니다.
승인 테스트 베드는 일반적으로 고객 측 (즉, 실험실)에 설치되며 개발 및 테스트 팀에 대한 액세스가 제한됩니다.
팀은 VM / 또는 특수 액세스 자격 증명을 사용하여 특별히 설계된 URL을 통해이 환경에 액세스해야하며 이에 대한 모든 액세스가 추적됩니다. 이 환경의 어떤 것도 고객의 허가없이 추가 / 수정 / 삭제할 필요가 없으며 변경 사항을 고객에게 알려야합니다.
AT 입출국 기준
STLC의 다른 단계와 마찬가지로 수락 테스트에는 수락 테스트 계획 (이 자습서의 뒷부분에서 다룹니다)에 잘 정의 된 진입 및 종료 기준 세트가 있습니다.
이 단계는 시스템 테스트 직후에 시작되어 프로덕션 출시 전에 끝나는 단계입니다. 따라서 시스템 테스트의 종료 기준은 AT의 진입 기준의 일부가됩니다. 마찬가지로 AT의 종료 기준은 프로덕션 출시를위한 진입 기준의 일부가됩니다.
입력 기준
시작하기 전에 충족해야 할 조건은 다음과 같습니다.
- 비즈니스 요구 사항은 명확하고 사용 가능해야합니다.
- 시스템 및 회귀 테스트 단계를 완료해야합니다.
- 모든 Critical, Major 및 Normal 버그를 수정하고 닫아야합니다 (주로 허용되는 사소한 버그는 제품 사용을 방해하지 않는 외관 버그입니다).
- 알려진 문제 목록을 준비하고 이해 관계자와 공유해야합니다.
- Acceptance Test Bed를 설치하고 환경 문제가 없는지 높은 수준의 검사를 수행해야합니다.
- 시스템 테스트 단계는 제품이 AT 단계로 이동할 수 있도록 사인 오프되어야합니다 (보통 이메일 통신을 통해 수행됨).
종료 기준
제품 출시를 위해 AT가 충족해야 할 특정 조건이 있습니다.
다음과 같습니다.
- 수락 테스트를 실행하고 모든 테스트를 통과해야합니다.
- 중대 / 중대 결함이 열려 있지 않습니다. 모든 결함은 즉시 수정되고 확인되어야합니다.
- AT는 포함 된 모든 이해 관계자의 서명을 받아야합니다. Go / No-Go 제품에 대한 결정.
수락 테스트 프로세스
에 V- 모델 , AT 단계는 요구 사항 단계와 병행합니다.
실제 AT 프로세스는 다음과 같이 진행됩니다.
비즈니스 요구 사항 분석
프로젝트 내에서 사용 가능한 모든 문서를 참조하여 비즈니스 요구 사항을 분석합니다.
그중 일부는 다음과 같습니다.
- 시스템 요구 사항 사양
- 비즈니스 요구 사항 문서
- 사용 사례
- 워크 플로 다이어그램
- 설계된 데이터 매트릭스
디자인 수락 테스트 계획
수락 테스트 계획에 문서화해야 할 특정 항목이 있습니다.
그중 몇 가지를 살펴 보겠습니다.
- 수용 테스트 전략 및 접근 방식.
- 진입 및 퇴장 기준은 잘 정의되어야합니다.
- AT의 범위는 잘 언급되어야하며 비즈니스 요구 사항 만 포함해야합니다.
- 수용 테스트 설계 접근 방식은 테스트를 작성하는 사람이 작성 방식을 쉽게 이해할 수 있도록 상세해야합니다.
- 테스트 베드 설정, 실제 테스트 일정 / 타임 라인을 언급해야합니다.
- 다양한 이해 관계자가 테스트를 수행하므로 이해 관계자가 따라야 할 절차를 알지 못할 수 있으므로 버그 로깅에 대한 세부 정보를 언급해야합니다.
수락 테스트 설계 및 검토
수락 테스트는 수행해야 할 작업을 언급하는 시나리오 수준에서 작성해야합니다 (수행 방법을 자세히 설명하지 않음). 이는 비즈니스 요구 사항에 대해 식별 된 범위 영역에 대해서만 작성되어야하며 각 테스트는 참조 요구 사항에 매핑되어야합니다.
모든 서면 승인 테스트는 비즈니스 요구 사항에 대한 높은 범위를 달성하기 위해 검토되어야합니다.
이는 언급 된 범위 이외의 다른 테스트가 관련되지 않도록하여 테스트가 예정된 일정 내에 있도록하기 위함입니다.
합격 테스트 베드 설정
테스트 베드는 프로덕션 환경과 유사하게 설정되어야합니다. 환경 안정성 및 사용 여부를 확인하려면 매우 높은 수준의 점검이 필요합니다. 이 테스트를 수행하는 이해 관계자와 만 환경을 사용하려면 자격 증명을 공유하십시오.
합격 테스트 데이터 설정
생산 데이터는 시스템에서 테스트 데이터로 준비 / 채워 져야합니다. 또한 데이터를 테스트에 사용해야하는 자세한 문서가 있어야합니다.
TestName1, TestCity1 등과 같은 테스트 데이터가 없습니다. 대신 Albert, Mexico 등이 있습니다. 이것은 실시간 데이터에 대한 풍부한 경험을 제공하며 테스트는 최신 상태가됩니다.
수락 테스트 실행
이 단계에서 환경에 대해 설계된 수락 테스트를 실행해야합니다. 이상적으로 모든 테스트는 첫 번째 시도 자체에서 통과해야합니다. 수락 테스트에서 발생하는 기능적 버그가 없어야합니다. 문제가있는 경우 높은 우선 순위로보고하여 수정해야합니다.
다시 말하지만, 수정 된 버그는 우선 순위가 높은 작업으로 확인되고 종료되어야합니다. 테스트 실행 보고서는 매일 공유해야합니다.
이 단계에서 기록 된 버그는 버그 선별 회의에서 논의되어야하며 근본 원인 분석 절차를 거쳐야합니다. 이것은 수락 테스트가 모든 비즈니스 요구 사항이 실제로 제품에 의해 충족되는지 여부를 평가하는 유일한 지점입니다.
비즈니스 결정
나옵니다 Go / No-Go 프로덕션에서 출시 될 제품에 대한 결정. 가다 결정을 내리면 제품이 시장에 출시 될 수 있습니다. No-Go 결정은 제품을 실패로 표시합니다.
No-Go 결정의 몇 가지 요소 :
- 제품의 품질이 나쁩니다.
- 열려있는 기능 버그가 너무 많습니다.
- 비즈니스 요구 사항에서 벗어남.
- 시장 표준에 미치지 못하며 현재 시장 표준과 일치하도록 개선이 필요합니다.
이 테스트의 성공 요인
이 테스트가 계획되면 성공률을 높이는 체크리스트를 준비하십시오. 수락 테스트가 시작되기 전에 따라야 할 몇 가지 작업 항목이 있습니다.
그들은:
- 잘 정의 된 범위를 가지고이 테스트를 위해 식별 된 범위에 대한 비즈니스 요구가 있는지 확인하십시오.
- 시스템 테스트 단계에서 승인 테스트를 한 번 이상 실행합니다.
- 광범위한 수행 임시 테스트 각 수용 테스트 시나리오에 대해.
결론
간단히 말해서 수락 테스트는 개발 및 테스트 팀의 효율성을 파악하는 데 도움이됩니다.
숙련 된 PDF에 대한 SQL 인터뷰 질문 및 답변
이 활동을 수행하기위한 몇 가지 도구가 있지만 일반적으로 실제 사용자와 기술적 배경이 아닌 다른 이해 관계자가 참여하고 있으며 실행 가능하지 않을 수 있으므로 수동으로 수행하는 것이 좋습니다.
무엇 향후 계획?
다음 튜토리얼에서는 아래 주제로 이동합니다.
- 수락 테스트 기준 예.
- 수락 테스트 계획을 작성하는 방법.
- 합격 시험 작성에 적합한 템플릿입니다.
- 예제로 수락 테스트를 작성하는 방법.
- 수락 테스트 시나리오 식별.
- 수락 테스트 보고서.
- 애자일 및 테스트 주도 개발의 수용 테스트.
수락 테스트를 수행 했습니까? 우리는 당신의 경험을 듣고 기쁩니다 !!