새로운 테스터는 종종 이 두 용어가 같은 의미인 것처럼 사용되는 것을 듣습니다. 그렇지 않습니다. 테스트 사례와 테스트 시나리오의 차이점은 대부분 세부 수준에 관한 것이며 이를 이해하면 테스트를 시작하기 전에 작성할 내용을 결정하는 데 도움이 됩니다.

이 가이드에서는 각 항목을 설명하고 요구 사항부터 시나리오, 전체 테스트 사례까지 단일 비밀번호 재설정 기능을 통해 작동합니다. 기능과 해당 규칙은 발명된 예입니다. 용어도 팀과 도구에 따라 조금씩 다르므로 팀에서 이러한 단어가 의미하는 바에 동의하세요.

짧은 대답

테스트 시나리오는 “사용자가 잊어버린 비밀번호를 재설정할 수 있는지 확인”과 같이 확인해야 할 상황을 설명합니다. 일반적으로 한 줄이며 세부 사항은 테스터에게 맡깁니다.

테스트 케이스는 해당 상황에서 하나의 조건(전제 조건, 단계, 테스트 데이터 및 예상 결과)을 확인하는 방법을 정확하게 설명합니다. 이를 따르는 두 명의 테스터는 동일한 평결에 도달해야 합니다.

여행을 계획한다고 생각해 보세요. 시나리오는 “푸네에서 델리까지 여행”입니다. 테스트 케이스는 항공편 번호, 출발 시간, 각 단계에서 수행할 작업이 포함된 전체 여정입니다.

테스트 케이스와 테스트 시나리오를 나란히 놓고

테스트 시나리오란 무엇입니까?

테스트 시나리오는 사용자가 수행할 수 있는 작업이나 시스템이 처리해야 하는 상황에 대한 간략한 설명입니다. 이는 외부에서 중요한 것에 초점을 맞추며 일반적으로 요구 사항이나 사용자 스토리에서 바로 나옵니다.

시나리오는 빠르기 때문에 가치가 있습니다. 세 가지 세부 사례를 작성하는 데 걸리는 시간에 30개를 나열할 수 있으므로 제품 소유자와 함께 적용 범위를 검토할 수 있는 좋은 방법이 됩니다. “우리가 모든 것을 생각해 봤나요?” 기술적인 지식이 없는 독자도 문제 없이 시나리오 목록을 따라갈 수 있습니다.

테스트 케이스란 무엇입니까?

테스트 케이스는 한 가지가 작동하는지 확인하는 데 사용되는 일련의 특정 조건 및 단계입니다. 일반적인 테스트 케이스에는 다음이 포함됩니다.

• 고유한 ID 및 명확한 제목
• 전제 조건, 시작하기 전에 충족되어야 하는 사항을 의미합니다.
• 번호가 매겨진 단계
• 특정 테스트 데이터
• 예상되는 결과
• 실행 시 채워지는 실제 결과와 상태

테스트 케이스는 일관성이 중요할 때 빛을 발합니다. 새로운 팀 구성원이 이를 실행할 수 있고 결과를 릴리스 간에 비교할 수 있으며 확인된 내용에 대한 기록이 있습니다. 테스트 사례 작성 방법에 대한 가이드에서 더 자세히 알아보세요.

하나의 기능, 시작부터 끝까지

1단계: 요구사항

비밀번호를 잊어버린 사용자는 이메일로 재설정 링크를 요청할 수 있습니다. 링크는 한 번만 작동하고 30분 후에 만료됩니다. 새 비밀번호는 8자 이상이어야 합니다.

2단계: 테스트 시나리오

TS-02를 보세요. 요구 사항에는 알 수 없는 이메일에 어떤 일이 발생해야 하는지 명시되어 있지 않으며 시나리오를 작성하면 그 격차가 노출됩니다. 페이지에 주소가 등록되지 않았음을 표시해야 합니까? 보안을 위해 일반적으로 공격자가 유효한 계정을 발견할 수 있으므로 그렇게 해서는 안 됩니다. 이러한 질문을 조기에 찾는 것은 시나리오 작성의 가장 큰 이점 중 하나입니다.

3단계: 테스트 사례

이제 TS-05만 테스트 사례로 확장합니다. 하나의 시나리오가 여러 개가 됩니다.

이 값은 무작위가 아닙니다. TC-051과 TC-052는 경계값 분석을 사용하여 한계의 양쪽에 있고 나머지는 등가 분할에서 나옵니다.

테스트 케이스 템플릿

다음은 전체 내용이 작성된 TC-052입니다. 팀에 아직 표준이 없는 경우 이 레이아웃을 복사하세요.

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

예상 결과는 오류 메시지보다 더 많은 것을 확인합니다. 또한 이전 비밀번호가 여전히 작동하는지, 링크를 계속 사용할 수 있는지 확인합니다. 약한 테스트 케이스는 화면에 보이는 것에서 멈추는 경우가 많습니다.

더 큰 그림에 적합한 위치

전통적으로 시나리오와 사례는 소프트웨어 테스트 수명주기의 테스트 설계 단계에서 작성됩니다.

각각을 사용하는 경우

시나리오는 다음과 같은 경우에 충분합니다.

• 팀은 규모가 작고 경험이 풍부하며 제품을 잘 알고 있습니다.
• 시간이 짧거나 요구 사항이 자주 변경됩니다.
• 이 기능은 위험이 낮습니다.
• 이해관계자와 함께 적용 범위를 신속하게 검토하고 싶습니다.
• 당신은 탐색적 테스트를 안내하고 있습니다.

다음과 같은 경우 세부 테스트 사례를 노력할 가치가 있습니다.

• 결제, 보안 또는 건강 데이터와 마찬가지로 실패하면 비용이 많이 듭니다.
• 규제 기관이나 감사인은 테스트된 내용에 대한 증거가 필요합니다.
• 신규 또는 아웃소싱 테스터가 테스트를 실행해야 합니다.
• 결과는 회귀 분석에서와 같이 정확하게 반복되어야 합니다.
• 단계는 자동화된 테스트가 됩니다.

대부분의 성숙한 팀은 두 가지를 모두 사용합니다. 그들은 모든 것에 대한 시나리오를 나열하고 가장 높은 위험에 대해서만 전체 사례를 작성합니다. 은행 송금과 마찬가지로 저위험 설정 페이지의 모든 단계를 문서화할 필요는 없습니다.

시나리오, 사례 및 자동화

잘 작성된 테스트 사례는 자동화된 테스트에 거의 직접적으로 매핑됩니다. 전제 조건은 설정이 되고, 단계는 작업이 되며, 예상 결과는 어설션이 됩니다. 행동 중심 개발 프레임워크는 실행 가능한 사양에 “시나리오”라는 단어를 사용하기도 합니다.

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

혼란스럽게도 BDD가 시나리오라고 부르는 것은 특정 데이터와 결과가 있기 때문에 테스트 사례에 훨씬 더 가깝습니다. 이는 약관에 동의해야 한다는 점을 상기시켜 주는 좋은 내용입니다. 이러한 검사를 자동화하려면 극작가 튜토리얼 또는 pytest 튜토리얼을 참조하세요.

무엇이 그들을 좋게 만드는가?

일반적인 실수

• 행복한 경로만 작성합니다. 대부분의 버그는 오류 조건에 있으므로 실패해야 하는 사항을 포함합니다.
• 모호한 예상 결과를 사용합니다. “제대로 작동해야 합니다”를 통해 테스터는 무엇이든 결정할 수 있습니다.
• 모든 것을 완벽하게 문서화합니다. 아무도 관리하지 않는 수천 개의 사례는 유용하고 작은 세트보다 더 나쁩니다.
• 시나리오 건너뛰기. 사건에 바로 뛰어들면 전체 영역을 잊어버릴 수 있습니다.
• 케이스를 진부하게 놔두세요. 제품이 바뀌면 오래된 케이스가 사람들을 오도합니다. 정기적으로 검토하십시오.
• 깨지기 쉬운 세부 사항에 단계를 연결합니다. “상단에 있는 파란색 버튼을 클릭하세요”는 어떤 재설계에서도 깨집니다.

마무리

시나리오는 폭을 제공하고 테스트 사례는 깊이를 제공합니다. 다음 기능에 대한 시나리오를 시작하고 개발자 및 제품 소유자와 함께 검토하세요. 그런 다음 위험한 항목만 전체 사례로 확장합니다. 당신은 더 일찍 공백을 발견하게 될 것이고, 당신은 글쓰기 시간을 중요한 곳에 보낼 것입니다.

자주 묻는 질문

계속 학습하세요