팀은 일단 모든 기술 테스트를 통과하는 비용 시스템을 제공합니다. 첫날, 재무팀은 업무의 큰 부분을 차지하는 다중 통화 청구를 처리할 수 없다는 사실을 발견했습니다. “깨진” 것은 없지만 사용할 수는 없었습니다. 사용자 승인 테스트는 출시 전에 이러한 종류의 격차를 정확히 파악하기 위해 존재합니다.

이 가이드에서는 UAT가 다른 테스트와 어떻게 다른지, 단계별로 실행하는 방법, 출시 준비 시기를 결정하는 방법을 다룹니다. 위의 시나리오와 아래의 예는 설명을 위한 것이며 프로젝트에 맞게 프로세스를 확장해야 합니다.

UAT란 무엇입니까?

UAT는 일반적으로 릴리스 전 최종 테스트 단계로, 의도된 사용자가 소프트웨어가 현실적인 조건에서 작업을 수행할 수 있는지 확인합니다. 최종 사용자 테스트 또는 승인 테스트라고도 합니다. 제품이 안정적일 것으로 예상되는 개발 및 시스템 테스트 후에 수행됩니다.

그 목적은 모든 버그를 찾는 것이 아닙니다. 이 단계에서는 대부분의 항목이 이미 사라졌습니다. 목표는 검증입니다. 우리가 올바른 것을 구축했는가? 테스터는 제품이 사양과 일치하는지 확인합니다. UAT는 사양과 제품이 실제로 요구 사항을 충족하는지 검증합니다.

UAT 대 QA 테스트

UAT는 다른 테스트를 대체하지 않습니다. 사용자가 계속해서 기본 버그에 부딪히면 빌드가 준비되지 않았으며 제한된 시간을 낭비하는 것입니다. 이러한 문제는 이전 테스트 수준 및 회귀 테스트에 속합니다.

UAT는 누가 운영하나요?

현재 실제로 작업을 수행하는 테스터를 선택하세요. 숙련된 청구 처리자는 관리자나 대리인이 결코 발견하지 못하는 문제를 발견할 것입니다. 전문가가 눈치채지 못한 채 해결해야 할 혼란스러운 단계를 신입 직원이 드러내는 경우가 많기 때문에 다양한 경험을 포함하십시오. UAT는 전체 작업 부하를 처리할 수 없으므로 관리자가 이를 위한 시간을 확보하도록 하십시오.

UAT 유형

7단계 UAT 프로세스

1. 범위와 목표 정의

무엇이 허용되고, 무엇이 범위를 벗어나며, 어떤 비즈니스 결과가 중요한지 결정하세요. 예: “재무 담당자는 지원되는 모든 통화로 비용 청구서를 제출, 승인 및 지불할 수 있습니다.”

2. 승인 기준에 동의

이상적으로는 출시 일주일 전보다는 프로젝트 시작 시점에 성공이 어떤 모습일지 쉬운 언어로 적어보세요. 모호한 기준은 나중에 논쟁으로 이어집니다.

3. 테스터 선택 및 간략화

실제 사용자를 선택하고, 목적을 설명하고, 피드백을 기록하는 방법을 보여주고, 스스로 테스트하는 것이 아니라 소프트웨어를 테스트하고 있음을 분명히 합니다. 많은 사람들이 뭔가 잘못될까봐 걱정합니다.

4. 환경 및 데이터 준비

UAT 환경은 가능한 한 프로덕션 환경과 유사해야 합니다. 현실적인 데이터를 사용하고, 올바른 사용자 역할을 설정하고, 이메일과 같은 통합을 확인하세요. 생산 데이터를 복사하는 경우 먼저 개인정보를 마스킹하세요. 빠른 스모크 테스트를 실행하여 테스터가 깨진 빌드를 찾기 위해 도착하지 않도록 하세요.

5. 시나리오 작성

개별 버튼이 아닌 실제 작업 흐름을 기반으로 합니다. 소프트웨어처럼 읽어서는 안 되고, 직업처럼 읽어야 합니다. 테스트 사례와 테스트 시나리오에 대한 가이드에서는 필요한 세부 정보를 설명합니다.

6. 테스트 실행 및 피드백 수집

도움을 줄 수 있는 사람과 함께 세션을 진행하세요. 스크린샷을 통해 이슈를 한 곳에 모아보세요. 사람들은 스크립트가 전혀 예상하지 못한 일을 시도하므로 무료 탐색을 위한 시간도 남겨두세요. 탐색적 테스트는 이에 대한 유용한 기술을 제공합니다.

7. 수정, 재테스트 및 승인

피드백을 분류하고, 중요한 사항을 수정하고, 동일한 사용자가 수정 사항을 확인하도록 하세요. 그런 다음 공식적인 결정을 기록하십시오.

UAT 테스트 케이스

UAT 테스트 케이스는 기술적인 지식이 없는 사람도 쉽게 따라할 수 있어야 합니다. 다음은 비용 시스템의 예입니다.

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

기술적인 세부 사항이 아닌 실제 작업을 설명하며 설명을 위한 여지를 남겨둡니다. “이건 작동하지만 저 버튼은 절대 찾을 수 없어”와 같은 의견이 가장 가치 있는 부분인 경우가 많습니다.

진입 및 퇴장 기준

이는 더 넓은 소프트웨어 테스트 수명 주기에 적합합니다. 이해관계자들과 미리 숫자를 설정하세요. “옳다고 느낄 때 결정하겠습니다”라고 하면 마감 기한에 쫓기면서 성급하게 예라고 대답하는 경향이 있습니다.

피드백 처리

UAT 피드백은 여러 가지가 혼합되어 있으며 모든 것이 버그는 아닙니다. 카테고리별로 정렬하세요.

심각도 대 우선순위에 설명된 대로 릴리스를 차단하는 명확한 규칙을 사용하세요. 그리고 거부한 항목을 포함하여 모든 항목에 응답하세요. 피드백이 사라지는 것 같으면 사람들은 피드백 제공을 중단합니다. 버그 보고서 작성 방법에 대한 가이드는 테스터가 문제를 명확하게 설명하는 데 도움이 될 수 있습니다.

UAT 체크리스트

UAT 이전

• 범위 및 허용 기준은 서면으로 합의됩니다.
• 시스템 및 회귀 테스트가 완료되었습니다.
• 테스터가 선택되고 브리핑을 받고 시간이 주어집니다.
• 환경, 계정, 현실적인 데이터가 준비되어 있습니다.
• 사본에 포함된 개인정보가 마스킹되었습니다.
• 시나리오는 비즈니스에서 검토됩니다.
• 문제를 기록하는 한 곳이 설정되었습니다.
• 사인오프 소유자가 지정됨

UAT 중

• 지원 연락처를 사용할 수 있습니다.
• 문제는 매일 분류됩니다.
• 진행 상황은 이해관계자와 공유됩니다.
• 수정 사항은 통제된 방식으로 배포 및 재테스트됩니다.

UAT 이후

• 종료 기준이 확인되었습니다.
• 알려진 문제는 소유자와 함께 문서화됩니다.
• 공식적인 승인이 기록됩니다.
• 교육 및 릴리스 노트가 업데이트되었습니다.
• 짧은 회고전이 열렸습니다.

Agile 팀의 UAT

전통적인 UAT는 마지막에 하나의 큰 단계로 이루어지며 놀라움에는 비용이 많이 듭니다. 민첩한 팀은 이러한 루프를 단축합니다. 제품 소유자는 스프린트 동안 승인 기준에 따라 각 스토리를 검토하고 사용자는 스프린트 검토에서 작동하는 소프트웨어를 확인합니다. 많은 팀은 주요 릴리스 이전에 여전히 집중적인 UAT를 실행하며, 특히 여러 기능이 하나의 워크플로로 결합되는 경우 더욱 그렇습니다.

빈번한 릴리스를 통해 기능 플래그 및 카나리아 배포와 같은 기술을 통해 실제 사용자는 새로운 작업을 점진적으로 시도할 수 있습니다. 이러한 보완 승인 테스트는 자동으로 대체되지 않으며, 특히 공식 기록이 필요한 규제 산업에서는 더욱 그렇습니다.

일반적인 실수

• 그것을 형식적인 것으로 취급합니다. 실제로 사용하지 않는 승인은 누구도 보호하지 못합니다.
• 잘못된 테스터를 사용합니다. 개발자와 QA는 사용자를 대표하기에는 시스템에 대한 지식이 너무 많습니다.
• 불안정한 빌드로 시작합니다. 테스터는 신뢰와 관심을 빨리 잃습니다.
• 마지막 순간까지 남겨두십시오. 그러면 배운 것을 고칠 시간이 없습니다.
• 비현실적인 데이터 사용. 테스트 데이터에는 실제 작업처럼 지저분한 경우가 거의 없습니다.
• 범위를 확장합니다. 새로운 아이디어가 진정한 방해 요소가 아닌 한 변경 요청으로 간주합니다.

마무리

UAT는 소프트웨어가 실제로 이를 사용할 사람들에게 도움이 되는지 여부를 출시하기 전에 알아볼 수 있는 마지막 기회입니다. 프로젝트 시작부터 계획을 세우고, 실제 사용자를 모집하고, 성공 여부에 대해 합의하세요. 다음 릴리스에서는 한 가지 간단한 변경을 시도해 보십시오. 실제 시나리오에서 한 명의 사용자와 함께 앉아 작업하는 동안 아무 말도 하지 마십시오.

자주 묻는 질문

계속 학습하세요