완벽한 품질 보증 테스트 – 사용자 흐름 자습서

제품과 서비스가 점점 더 빠르게 배포됨에 따라 품질 보증(QA)은 진화하는 환경에 적응해야 하며 때로는 더 짧은 기간에 동일한 수준의 적용 범위를 달성해야 합니다. 품질보다 수량 이라는 실수를 피하려면 어떻게 해야 합니까? 우리는 어떻게 더 많은 것을 다루고 효율성을 높이며 여전히 우리의 작업에서 효과적입니까?

테스트 케이스를 만드는 데 시간이 오래 걸린다는 것은 모두 알고 있습니다. 다양한 기술, 테스트 유형을 적용하고 사전 조건, 단계 및 예상 결과를 문서화해야 합니다. 또한 테스트 계획을 작성해야 합니다.

품질 보증 전문가는 특히 QA 프로세스의 모든 단계를 완료하려고 할 때 시간이 부족하다는 것을 알게 됩니다. 가장 큰 골칫거리는 테스트 케이스 생성 및 테스트 문서화를 중심으로 하는 테스트 계획 및 설계 단계입니다. 모든 작업을 완료하는 데 몇 시간, 때로는 며칠이 걸릴 수 있으며 일반적으로 특정 결과물을 건너뛰고 대신 요약을 선택하여 테스트를 잊어버릴 수 있는 중요한 정보를 생략합니다. 이는 또한 지식 공유의 이점을 잃게 됩니다.

기존의 QA 테스트와 사용자 흐름의 만남

저는 전통적인 테스트 케이스와 테스트 계획의 열렬한 팬입니다. 그들은 수많은 테스트 사례를 식별하는 데 도움이 될 뿐만 아니라 제품을 정말 잘 문서화합니다. 교육에 사용할 수 있으며 팀의 모든 사람이 이를 이해합니다. 누군가가 테스트를 시작하기 위해 경험에 지나치게 의존할 필요는 없습니다. 테스트 계획에는 범위, 테스트 항목, 테스트 중인 기능 및 테스트하지 않는 기능과 같은 추가 정보가 있습니다. 테스트 계획에 포함되는 위험 분석도 있습니다. 이는 일부 이점에 불과하지만 많은 경우에 소요되는 전체 시간이 너무 깁니다.

테스트 계획의 목적은 프로젝트 이해 관계자 간의 의사 소통 및 합의 방법입니다. 목표, 필요한 리소스, 제품 테스트를 위한 접근 방식 또는 전략을 자세히 설명하는 데 도움이 됩니다. 이 계획은 모든 것이 고려되고 있는지 확인하고 이해 관계자에게 품질 보증 프로세스가 전략적으로 투자되었다는 확신을 제공합니다. 이 계획의 길이가 10페이지여야 한다는 구체적인 규칙은 없습니다. 빠르게 진행되는 팀에 맞게 재정의할 수 있습니다.

대안은 필요한 시간 투자를 줄이는 방식으로 기존 테스트 사례와 테스트 계획을 간소화하는 동시에 모든 이해 관계자에게 의미가 있는 범위와 문서를 제공하는 것입니다. 여기에는 진실의 단일 소스, 비틀림이 있는 사용자 흐름이 포함됩니다. 사용자 흐름을 구조화하고 유지함으로써 테스트 케이스 디자인의 대부분이 이미 완료되었습니다. 이것은 모든 제품이나 팀에 적용할 수 있으며 세부 사항 및 구조 방식에서 다재다능합니다.

흐름 방법을 사용하면 테스트 문서에서 더 빠른 처리 시간을 달성하는 데 도움이 됩니다. 이는 수동 QA뿐만 아니라 자동화에도 해당됩니다. 흐름은 테스트 계획의 일부 섹션에 기여할 수도 있습니다.

흐름과 함께 가다

더 이상 지체하지 않고 간단한 메시징 웹 사이트에 대한 사용자 흐름을 구축하는 데 바로 뛰어들어 보겠습니다.

먼저 무료 마인드 매핑 도구가 필요합니다. 저는 개인적으로 XMind를 사용합니다. 편리한 도구를 자유롭게 다운로드하세요. 흐름도 그리기, 일부 주제에 "메모" 추가, 다양한 조건에 색상 지정, 레이블 사용과 같은 기본 기능만 사용할 것입니다.

우리의 첫 번째 단계는 제품을 이해하는 것입니다. 일반적으로 모형 이미지나 와이어프레임을 참조합니다. 이들 중 어느 것도 사용할 수 없는 경우 개발자와의 빠른 후속 전화를 통해 정확히 어떤 화면이 예상되는지 알 수 있습니다. 진행하면서 자유롭게 따라하고 연습하세요. 이 흐름은 사용자 인터페이스에 국한되지 않고 API 간 호출, 데이터베이스 다이어그램, 종속성 구조 등을 매핑하는 데 사용할 수도 있습니다. 동일한 원칙이 적용됩니다.

조건, 상태, 조치

3명의 액터만 사용하여 흐름을 제한합니다. 특정 역할을 가진 사용자, 지워진 캐시 또는 처음으로 로그인하는 사용자와 같은 Condition 이 있습니다. 둘째, 홈페이지나 로그인 창과 같은 실제 GUI 구성 요소인 State/Page 가 있습니다. 다음은 상태를 변경하는 물리적 사용자 상호 작용인 Action 입니다. 이것을 실제로 보도록 합시다.

요구 사항 분석

이것은 국가인 우리의 홈페이지입니다. 등록 및 로그인의 두 가지 가능한 작업이 있습니다.

그런 다음 다른 상태인 로그인 창이 있습니다. 여기에서의 작업은 뒤로 및 로그인입니다. 입력 필드를 작업으로 분류하지 않습니다. 이 작업을 수행하는 것을 환영합니다. 내 경험에 따르면 수십 분의 1 깊이로 실행되는 복잡한 시스템에서 작업할 때 유지 관리가 약간 어려워 지지만 간단한 응용 프로그램의 경우 매우 적합할 수 있습니다.

마지막으로 사용자가 성공적으로 로그인했을 때 연결되는 대시보드가 ​​표시됩니다. 여기에서 메시지 생성, 편집 또는 삭제라는 세 가지 작업이 있습니다.

이제 사용자 흐름을 시작하기에 충분한 정보가 있습니다. 우리가 가진 것을 요약해 봅시다. 우리는 제품의 상태를 기록합니다. 우리가 볼 수 있는 것에는 4개의 페이지가 있습니다:

1. 홈페이지
2. 로그인 창
3. 등록 창
4. 계기반

다음과 "상호작용"할 수 있는 각 페이지/상태에 대한 작업을 기록합니다.

1. 홈페이지
   1. 로그인
   2. 등록하다
2. 로그인 창
   1. 로그인
   2. 취소
3. 등록 창
   1. 미정(제품에 따라 다름)
4. 계기반
   1. 만들다
   2. 편집하다
   3. 삭제

환경에 맞게 변경할 수 있는 Product Name 으로 시작하지만 대부분의 팀과 해당 제품에 적합하며 좋은 출발점을 제공합니다. 아래에서 Register 옆에 물음표가 표시됩니다.

많은 경우 Agile에서 아직 범위에 포함되지 않았거나 향후 릴리스로 계획된 구성 요소를 접하게 됩니다. 그 존재를 기록해 두되 더 많은 정보를 얻을 때까지 알려지지 않은 상태로 두십시오.

흐름도 그리기

위의 내용을 XMind에서 다음과 같이 그립니다.

내가 단순히 상태와 동작을 색상으로 구분하고 있음을 알 수 있습니다. 또한 해당 흐름을 정확하게 나타내기 위해 취소 작업의 한 줄을 홈페이지에 추가했습니다. 또한 사용자가 "로그인"을 선택할 때 두 가지 조건이 표시됩니다. 둘 다 대시보드로 이동하지만 여전히 두 가지 가능한 조건을 모두 테스트하려고 합니다.

XMind의 좋은 점은 우리가 크고 복잡한 응용 프로그램에서 작업하는 경우 다이어그램의 다른 수준을 만들 수 있다는 것입니다. 따라서 흐름을 여러 흐름으로 나누지만 연결된 상태를 유지하려는 경우 연결을 사용하면 매우 쉽습니다. 시트를 분리할 주제입니다. 하이퍼링크를 삽입하도록 선택할 수 있으며 마법사 팝업에서 작업으로 이어지는 "상태"를 선택할 수 있습니다. 즉, XMind에서 "로그인"을 선택하고 "대시보드"로 하이퍼링크되면 마우스 커서가 다른 시트에 있더라도 "대시보드"로 이동합니다. 정말 멋진.

흐름에 누락된 것은 레이블입니다. 흐름의 루트이므로 제품에 레이블 0을 지정합니다. 그런 다음 각 상태(파란색)에 대해 S# 레이블을 추가하고 각 작업(녹색)에 대해 A# 레이블을 추가하고 마지막으로 각 조건(청록색)에 대해 C# 레이블을 추가합니다. 각 레이블은 고유해야 합니다. 우리는 아래와 같이 끝납니다.

제품이 성장함에 따라 가장 높은 숫자를 찾는 것이 어려울 수 있으므로 마지막으로 사용한 번호를 추적하기 위해 아래와 같이 흐름의 루트 주제에 저장합니다.

이제 테스트 케이스를 만드는 부분에 도달했습니다. 테스트 케이스에서 아마도 가장 중요한 정보이자 기능의 허용 기준의 일부인 예상 결과에 초점을 맞출 것입니다. 각 섹션 또는 테스트에 제목을 추가한 다음 그 아래에 예상 결과를 나열합니다. 이 기사를 간결하게 유지하기 위해 하위 집합에 대해서만 이 작업을 수행합니다.

그런 다음 로그인 창:

그런 다음 로그인 작업:

정말 모양을 잡아가고 있습니다. 경계 및 보안 테스트가 추가되었습니다. 원하는 대로 제목을 지정할 수 있습니다. 둘 중 가장 쉽게 태그를 지정할 수 있습니다. 보안 – JS 주입 – 이메일 필드와 같은 테스트 유형으로 제목에 태그를 지정한 다음 아래에 예상 결과를 나열합니다.

대부분의 팀에서 요구 사항 변경을 유지 관리하는 데 번거로움이 있습니다. 더 이상은 없어. 모든 최초 사용자에게 T 및 C 창이 표시되어야 하고 대시보드로 이동하기 전에 수락해야 한다는 사실을 방금 배웠다고 가정해 보겠습니다. 문제 없습니다. 아래와 같이 상태와 동작을 비교적 쉽게 추가할 수 있습니다.

이제 새 상태 추가의 영향을 봅니다. 번호 매기기가 처음에는 이상할 수 있지만 우리가 기억하는 한 번호는 데이터베이스의 기본 키와 같이 각 액터를 고유하게 식별하기 위한 것입니다. 사용하는 번호를 추적하기 위해 "마지막 사용" 메모를 업데이트하는 것을 잊지 마십시오.

흐름에서 테스트 사례 만들기

이 모든 과정이 끝나면 이제 더 쉬운 부분인 테스트 케이스 생성으로 넘어갑니다. 몇 가지 중요한 사항을 강조하겠습니다. 모든 액터에 대한 레이블이 있고 모든 테스트에 대한 제목이 있으며 흐름의 일부로 포함된 조건과 함께 모든 테스트에 대한 예상 결과가 있습니다. 이것은 테스트 케이스를 위한 레시피처럼 들리는데, 동의하지 않습니까?

지금 우리가 하는 일은 흐름에 있는 것을 원하는 테스트 사례 관리 도구, Confluence 사이트 또는 Excel 문서에 복사하여 붙여넣는 것뿐입니다. 나는 여전히 오래된 신뢰할 수있는 Excel을 사용합니다. 저는 모든 테스트 사례를 "기준선"이라는 하나의 파일에 기록합니다. 매우 독창적입니다. 복사-붙여넣기가 완료되면 아래와 같이 끝납니다.

필요에 따라 테스트 유형, 테스트 상태 및 테스트 구성에 대한 열을 자유롭게 추가할 수 있습니다. 조건은 "로그인" 작업보다 먼저 배치하는 것이 더 나을 수 있지만, 이를 수행하는 옳고 그른 방법은 없으며 개인 취향과 자신을 구성하는 방법에 달려 있습니다.

강조할 몇 가지 사항이 있습니다. 하나는 동일한 정보를 공유하는 병합된 셀이 있다는 것입니다. 반복적으로 복사하여 붙여넣을 필요가 없고 시간이 낭비되고 유지 관리가 더 어렵습니다. 또 다른 항목은 단계입니다. 두 가지 테스트에 State 및 Action 번호를 통합하는 단계가 있음을 알 수 있습니다. 팀에 SDLC의 일부로 흐름이 있는 경우 사용할 수 있습니다. 그런 다음 모든 이해 관계자는 정보, 모형, 위험 증가 등을 제공하여 흐름에 기여합니다. 즉, 흐름 번호를 지정하면 팀의 모든 사람이 무엇을 해야 하는지 알 수 있고 새 팀원이 있는 경우에도 쉽게 할 수 있습니다. "추적을 따라 메모를 참조하십시오."

이는 자동화에도 도움이 됩니다. 각 단계 또는 작업에 고유한 참조를 제공할 수 있습니다. 흐름과 같이 구성된 자동화 팩을 생성하면 구축할 수 있는 자동화 프레임워크가 매우 강력하고 모듈식이며 앱 전체에서 호환될 수 있는 잠재력이 있음을 알게 될 것입니다. 더 큰 규모의 페이징 개체를 활용하여 유지 관리 시간을 줄이고 테스트 기능을 새 기능으로 교체할 수 있습니다.

흐름은 기술 사양, 기능 사양, 테스트 사례, 상태 전환, 데이터 흐름 등을 포함한 모든 제품 문서에 대한 단일 정보 소스가 될 수 있습니다.

간소화된 테스트 계획 접근 방식

테스트 계획은 어떻습니까? 생각해야 합니다. 이것은 간단합니다. 테스트 계획에는 다음과 같은 섹션이 포함됩니다.

1. 소개 및 범위
2. 테스트 항목
3. 테스트할 기능
4. 테스트하지 않는 기능
5. 가정
6. 입학 기준
7. 종료 기준
8. WBS
9. 위험
10. 환경 요구 사항

소개 및 범위는 JIRA 스토리 또는 다른 도구의 작업 또는 스토리입니다. 테스트 항목은 단순히 현재 환경에 배포된 소프트웨어 버전 또는 커밋 번호로, JIRA 티켓에 연결하거나 Confluence 또는 테스트 관리 도구에서 테스트 실행에 연결할 수 있습니다.

테스트할 기능과 테스트하지 않을 기능 은 실제로 테스트 케이스입니다. 이 JIRA 스토리에서 실행하기로 선택한 테스트 케이스는 "테스트할 기능"이고 나열되지 않은 것은 "테스트하지 않는 기능"입니다. 아주 간단하게 이야기 티켓에 테스트할 상태와 작업을 나열하십시오.

가정, 위험, 심지어 환경 요구 사항까지 문서로 편집하거나 JIRA의 주석에 추가할 수 있으며, 때로는 Confluence에 배치하고 스토리에 링크할 수도 있습니다.

WBS는 프로젝트에 따라 스토리 포인트 또는 시간 측면에서 스토리에 할당하는 추정치입니다. 입장 및 퇴장 기준은 이미 이야기의 일부가 될 것입니다.

"전통적인" 테스트 계획에 근접하려면 개발자 또는 기타 이해 관계자에게 예 또는 아니요로 스토리에 대해 의견을 말하여 QA 계획에 동의하는지 여부를 확인하도록 요청할 수 있습니다. 이것은 기술적으로 디지털 서명 역할을 합니다. 이 모든 것이 QA 프로세스에 훨씬 쉽게 포함될 수 있으며 QA 문서를 간소화하는 데 도움이 됩니다.

우리는 무엇을 배웠습니까?

위의 접근 방식과 현재 사용 가능한 도구를 사용하도록 간소화된 테스트 계획을 사용하는 사용자 흐름은 반복적인 작업을 줄이고 품질을 희생하지 않고 더 빠른 처리 시간을 달성할 수 있도록 QA를 지원합니다.

이 접근 방식은 내가 조직을 유지하고 모든 기초를 다루며 전체 팀이 이해할 수 있는 문서를 작성하는 데 도움이 되었습니다. 애자일에서 이것은 정말 유용할 것이고, 그것의 가장 좋은 점은 우리가 여전히 애자일 접근 방식 중 하나인 "문서 단순화"를 고수하고 있다는 것입니다.

정보가 도움이 되었길 진심으로 바랍니다. 그것은 모두 독자로서 당신에게 달려 있습니다. 이것은 따라야 할 구체적인 규칙이 아니며 효율성을 높이고 향상시키기 위한 아이디어를 제공하기 위한 지침일 뿐입니다. 모든 프로젝트, 팀 또는 제품에 맞는 기술은 없지만 또 다른 혁신적인 아이디어를 위한 길을 열 수 있습니다.