소프트웨어 테스팅의 워크플로 테스팅이란 무엇입니까? 예제와 함께

워크플로 테스트란 무엇입니까?

워크플로 테스트 워크플로우 테스트는 각 소프트웨어 워크플로우가 주어진 비즈니스 프로세스를 정확하게 반영하는지 확인하는 소프트웨어 테스트 유형입니다. 워크플로우는 원하는 결과를 도출하는 일련의 작업으로, 일반적으로 여러 단계 또는 과정을 포함합니다. 모든 비즈니스 프로세스에 대해 이러한 순차적인 단계를 테스트하는 것을 워크플로우 테스트라고 합니다.

중요한 차이점은 범위입니다. 단일 테스트 사례 하나의 함수가 올바른 답을 반환하는지 묻는 테스트와 달리, 워크플로우 테스트는 실제 사용자가 따르는 순서대로 실행되는 10개의 함수가 비즈니스에서 기대하는 결과를 여전히 제공하는지 묻습니다. 이러한 이유로 워크플로우 테스트는 프로세스 중심 테스트 항목에 속합니다. 소프트웨어 테스트 유형 단위 수준 기법보다는 카탈로그를 사용하는 것이 더 적절합니다.

워크플로 테스트 예

예를 들어, 시스템이 사용자의 플랫폼에 설치될 수 있는지, 그리고 올바르게 실행되는지 확인하십시오.

온라인 주문을 예로 들어보겠습니다. 고객은 장바구니에 상품을 담고, 할인 코드를 적용하고, 배송 방법을 선택하고, 결제를 완료한 후 주문 확인 이메일을 받습니다. 동시에 창고는 상품 준비 지시를 받습니다. 이러한 각 단계는 개별적으로는 정상적으로 진행되더라도 전체적인 과정에서 오류가 발생할 수 있습니다. 예를 들어, 할인 코드가 결제 단계에서 제대로 적용되지 않거나, 창고로 전달된 메시지가 처리되지 않고 그대로 전달될 수도 있습니다.

워크플로우 테스트는 단계별로 진행됩니다. 워크플로우 테스트는 다음과 같은 방식으로 수행됩니다.

• 시작 단계이 단계에는 초기 테스트 계획 수립 및 프로토타입 테스트가 포함됩니다.
• 정교화 단계이 단계에는 테스트 아키텍처의 기준선 설정이 포함됩니다.
• 건설 단계이 단계에는 각 빌드마다 상당한 테스트가 포함됩니다.
• 전환 단계이 단계에는 다음이 포함됩니다. 회귀 테스트 수정 사항을 다시 테스트합니다.

워크플로우 테스트 수행 방법

위의 단계별 모델은 작업이 언제 발생하는지를 설명합니다. 아래의 순서는 테스터가 각 단계에서 실제로 수행하는 작업을 설명합니다.

1. 비즈니스 프로세스를 매핑하세요. 실제 비즈니스 운영 방식을 그대로 반영하여 모든 의사 결정 지점, 승인 절차, 부서 간 인수인계 등을 포함한 워크플로를 정확하게 그리세요. 비즈니스 분석가는 일반적으로 정확한 워크플로 지도를 작성하는 데 가장 빠른 길잡이가 될 수 있습니다. 비즈니스 분석가 문서는 지도를 검증하는 데 사용되는 참조 자료입니다.
2. 진입 및 퇴출 기준을 설정하세요. 워크플로가 시작되기 전 시스템이 있어야 하는 상태와 워크플로가 완료되었음을 증명하는 상태를 기록하십시오. 이 두 가지가 없으면 테스터들은 실행이 통과되었는지 여부에 대해 의견이 일치하지 않습니다.
3. 테스트 케이스를 설계하세요. 워크플로의 각 경로마다 하나의 사례를 작성하고, 화면마다 하나씩 작성하지 마십시오. 단계에 번호를 매기고, 각 단계의 예상 결과를 명시하며, 결함을 쉽게 찾을 수 있도록 모든 사례에 고유 식별자를 부여하십시오. trac원래 경로로 돌아왔습니다.
4. 실제와 유사한 테스트 데이터를 준비하세요. 인위적으로 만들어낸 값 대신 익명화된 실제 생산 형태의 기록을 재사용하세요. 할인 코드, 세금 규정, 주소 형식은 합성 데이터에 실제 결함이 숨겨져 있는 일반적인 예입니다.
5. 기본 경로를 먼저 실행하세요. 의도적으로 오류를 발생시키기 전에 워크플로가 처음부터 끝까지 완전히 완료되는지 확인하십시오. 이 단계에서 오류가 발생하면 이후의 모든 부정적인 결과가 무효화됩니다.
6. 일부러 연결 고리를 끊어라. 도중에 취소하거나, 결정 지점에서 잘못된 값을 제출하거나, 세션 시간이 초과되거나, 승인을 거부하는 등의 상황에서 흥미로운 결함이 발견됩니다. 이러한 중단된 경로에 결함이 존재하며, 주요 경로에는 결함이 없습니다.
7. 문제를 보고하고, 수정하고, 다시 테스트하십시오. 각 결함을 해당 결함이 발생한 단계에 기록한 다음, 수정 후 전체 워크플로를 다시 실행하세요. 수정된 단계는 종종 오류 발생 지점을 워크플로의 하위 단계로 이동시킵니다.

매 릴리스마다 반복되는 안정적인 워크플로는 자동화에 가장 적합한 후보입니다. 동일한 순서의 단계가 매번 동일하게 실행되고 스크립트는 몇 주기 내에 투자 비용을 회수할 수 있기 때문입니다.

워크플로 테스트는 누가 수행합니까?

워크플로 테스트는 어느 한 역할이 전체 과정을 볼 수 없기 때문에 여러 역할이 함께 수행하는 작업입니다. 네 명의 역할이 각자의 책임을 가지고 이 작업을 분담합니다.

• 테스트 엔지니어
  • 테스트 목표 및 일정 계획
  • 테스트 케이스 및 절차 정의
  • 테스트 결과 평가
• 부품 엔지니어
  • 테스트 구성 요소 개발
  • 일부 테스트 절차 자동화
• 통합 테스터
  • 공연 통합 테스트 결함 보고
• 시스템 테스터
  • 공연 시스템 테스트 결함 보고

워크플로우에서 테스트할 항목

소프트웨어 워크플로는 비즈니스 요구사항 문서에 문서화되어 있으며, 해당 문서가 테스트 범위에 대한 기준이 됩니다. 워크플로 테스트에는 시스템 및 통합 테스트의 일부도 포함됩니다.

워크플로 전체를 검토할 때는 사용자가 보는 화면뿐만 아니라 더 많은 부분을 살펴봅니다.

• 순서: 절차는 문서에 명시된 순서대로 진행되며, 단계를 건너뛰거나 순서에 맞지 않게 반복할 수 없습니다.
• 데이터 전달: 체인 초기에 입력된 값은 마지막 단계와 하위 시스템까지 그대로 유지됩니다.
• 역할 및 권한: 각 단계는 해당 단계를 수행할 권한이 있는 역할만 이용할 수 있습니다.
• 중단된 경로: 취소, 시간 초과, 거부 및 재시도는 모두 워크플로를 정의된 상태로 유지합니다.
• 아티팩트 : 워크플로우 테스트 모델은 테스트 케이스, 테스트 절차, 테스트 구성 요소 및 테스트 하위 시스템을 포함하므로 이러한 각 요소가 순차적으로 검증됩니다.
• 알림 : 이메일, 알림 및 대기열 메시지는 올바른 내용으로 올바른 단계에서 한 번만 전송됩니다.

워크플로우 테스트 vs 엔드투엔드 테스트 vs 시스템 테스트

이 세 가지 기법은 서로 겹치는 부분이 많아 혼동될 수 있지만, 각각 다른 질문에 대한 답을 제시합니다. 아래 표는 그 경계를 명확히 보여줍니다.

실제로 워크플로우 테스트는 종종 명세와 관련이 있습니다. 엔드투엔드 테스트 는 ~으로 구성되어 있으며, 시스템 테스트 워크플로가 실행되는 안정적인 빌드를 제공합니다.

최고의 사례와 공통 과제

워크플로 테스트를 통해 가치를 얻는 팀은 공통적으로 몇 가지 습관을 따르는 경향이 있습니다.

• 수익 또는 규제 위험이 수반되는 워크플로를 드문 워크플로보다 우선시하십시오.
• 각 단계와 예상 결과를 명확하고 모호하지 않은 언어로 설명하십시오.
• 재사용 가능하고 현실적인 테스트 데이터 세트를 유지하여 환경 간 실행 결과의 비교 가능성을 확보하십시오.
• 각 워크플로를 모든 결정 지점에서 유효한 입력값과 유효하지 않은 입력값으로 테스트하십시오.
• 기본 비즈니스 프로세스가 변경되는 즉시 테스트 케이스를 업데이트하십시오.

반복적으로 발생하는 장애물들은 그만큼 예측 가능합니다.

• 문서화되지 않은 프로세스: 워크플로는 사람들의 머릿속에 존재하므로 테스터는 가정에 비추어 검증하는 것입니다.
• 실행 시간이 오래 걸림: 승인 절차를 포함하는 워크플로는 몇 시간이 걸릴 수 있으므로 수동으로 실행하는 빈도가 제한됩니다.
• 환경 변화: 공급망의 하류 시스템은 제대로 작동하지 않거나 정체되어 있으며, 결함은 생산 단계에서만 나타납니다.
• 취약한 자동화: 화면 레이아웃과 관련된 스크립트는 프로세스가 변경되지 않았더라도 인터페이스가 변경될 때마다 오류가 발생합니다.
• 데이터 충돌: 병렬 실행은 동일한 레코드를 소비하므로 제품 결함처럼 보이는 오류가 발생합니다.

자주 묻는 질문