테스트 시나리오의 단계 수를 작게 유지해야 하는 이유는 무엇인가요?

개요

모든 경우는 아니더라도 대부분의 경우 테스트 시나리오를 짧게 유지하는 것이 좋습니다. 이 문서에서는 짧은 테스트 시나리오의 장점과 시나리오의 크기를 줄이는 방법에 대해 설명합니다.

짧은 테스트 시나리오의 이점은 다음과 같습니다:

• 테스트 시나리오가 짧을수록 덜 복잡하고 읽기/이해하기가 쉽습니다.
• 리플레이에 시간이 많이 걸리지 않습니다. 단계를 더 빠르게 다시 녹화하거나 미세 조정할 수 있어 유지 관리 비용이 절감됩니다.
• 테스트 실행 시간이 더 짧아집니다. 문제를 업데이트하거나 수정한 후 테스트 시나리오를 다시 시도하고 결과를 빠르게 확인할 수 있습니다.
• 문제를 더 쉽게 격리할 수 있습니다. 버그로 인해 하나의 테스트 시나리오가 실패하더라도 제품의 다른 부분이 정상인지 확인할 수 있습니다. 결과적으로 테스트 시나리오 세트가 안정적으로 유지됩니다.

반대로 테스트 시나리오가 길어질수록 불안정(또는 "들쑥날쑥")해지는 경향이 있습니다.

테스트 크기를 줄이는 방법

1. 확인할 기준을 나열하세요.

블로그 서비스를 테스트하려고 한다고 가정해 보겠습니다. 목록은 다음과 같을 수 있습니다:

1. 블로그 서비스 로고가 페이지 상단에 표시됩니다.
2. 새 사용자 만들기
3. 기존 사용자 계정으로 로그인합니다.
4. 블로그 글 만들기
5. 블로그 글 수정하기
6. 블로그 글 삭제하기
7. "블로그 게시물에 '좋아요'(또는 '업보트') 표시하기
8. 블로그 게시물 '좋아요' 취소하기
9. 로그인 후 로그아웃하기
10. 사용자 삭제하기

목록의 각 항목은 테스트 시나리오의 일부와 동일해야 합니다.

2. 목록을 작은 그룹으로 나누기

그룹은 작을수록 좋습니다. 하나의 목록 항목으로만 그룹을 만들 수 있다면 그렇게 하세요.

또는 사용자 관련 항목, 블로그 글 관련 항목 등의 카테고리로 나눌 수도 있습니다.

목록의 일부 항목은 이전 단계의 결과에 따라 달라질 수 있습니다. 예를 들어 사용자를 삭제하려면 먼저 사용자를 만들어야 합니다. 이러한 종속성이 발견되면 이러한 목록 항목을 하나의 그룹에 넣을 수 있습니다.

E2E(엔드투엔드) 테스트의 장점 중 하나는 서로 독립적일 수 없거나 함께 테스트해야 하는 기능을 한 번에 테스트할 수 있다는 것입니다. 하지만 이러한 종속성을 최소화해야 한다는 점을 명심하세요. 테스트 시나리오에 많은 종속성을 도입하면 예기치 않은 오류 하나로 모든 것이 파괴될 수 있습니다. 테스트 시나리오에 긴 준비 순서를 두는 대신 수정 사항을 두는 것이 좋습니다.

다음은 목록을 그룹화하는 방법의 예입니다.

• 시나리오 #1: 로고
  • 블로그 서비스 로고가 페이지 상단에 표시됩니다.
• 시나리오 #2: 사용자 생성 및 삭제
  • 새 사용자를 만듭니다.
  • 사용자를 삭제합니다.
• 시나리오 #3: 로그인 및 로그아웃
  • 기존 사용자 계정으로 로그인합니다.
  • 로그인한 후 로그아웃합니다.
• 시나리오 #4: 블로그 글 작성 및 삭제
  • 블로그 글을 작성합니다.
  • 블로그 글을 삭제합니다.
• 시나리오 #5: 블로그 글 편집
  • 블로그 글을 편집합니다.
• 시나리오 #6: 블로그 게시물에 '좋아요'를 누르고 취소하기.
  • 블로그 게시물에 '좋아요'(또는 '찬성')를 표시합니다.
  • 블로그 게시물 '좋아요' 취소하기

그런 다음 각 그룹에 대한 테스트 시나리오를 만듭니다.

3. 단계 그룹 사용

대부분의 테스트 시나리오에서 무언가를 확인하기 전에 로그인을 해야 한다는 것을 알 수 있습니다. 로그인이 필요한 모든 시나리오에 이러한 단계를 수동으로 추가하지 않으려면 로그인 시퀀스를 단계 그룹(재사용 가능한 구성 요소)에 넣고 대신 필요한 곳에 단계 그룹을 삽입할 수 있습니다.

단계 그룹을 사용한다고 해서 총 단계 수가 줄어들지는 않지만, 그렇게 하면 테스트 시나리오의 중복성이 줄어들고 유지 관리가 더 쉬워집니다.

단계 그룹도 작게 유지하는 것을 목표로 해야 합니다. 로그인 시퀀스 단계 그룹의 경우 로그인 작업과 관련이 없는 단계는 포함하지 않도록 하세요. 예를 들어 웹사이트에 실제로 로그인하기 전에 로그인 페이지 자체에서 일부 UI 구성 요소를 어설트하려는 경우 다른 테스트 시나리오에서 수행해야 합니다.

4. 고정 장치 준비

'픽스처'는 테스트를 실행하기 전에 준비하는 테스트 데이터를 포함하여 테스트를 실행하기 전에 필요한 일련의 전제 조건을 의미합니다. 예를 들어 로그인/로그아웃 동작을 테스트할 샘플 사용자 또는 편집 동작을 테스트하는 데 사용할 수 있는 샘플 블로그 게시물 등이 있습니다.

테스트 시나리오 내에서 테스트 데이터를 설정하기만 하면 된다고 생각할 수도 있습니다. 하지만 개발팀이 사용자 데이터가 생성되는 가입 페이지의 UI를 업데이트하면 어떻게 될까요? UI 업데이트는 "시나리오 #2: 사용자 생성 및 삭제'가 불안정해질 수 있지만, 테스트 실행 전에 이미 샘플 사용자 데이터가 준비되어 있는 경우 '시나리오 #3: 로그인 및 로그아웃"은 다른 시나리오의 결과에 영향을 받지 않고 안정적으로 실행할 수 있습니다. 요컨대, 일관된 데이터를 확보함으로써 테스트 시나리오의 안정성을 높일 수 있습니다.

이러한 고정 데이터를 수동으로 생성하는 것이 가장 간단한 방법인 경우가 많습니다. 또는 빌드/배포 프로세스에서 테스트 데이터를 자동으로 생성하는 경우, CI/CD 기능을 활용하여 테스트를 보다 효율적으로 실행할 수 있습니다.