앞으로 몇개의 포스팅에 걸쳐 관련 책의 요약 및 실무에서의 경험을 토대로, 탐색적 테스팅에 관련된 포스트를 기재하고자 합니다. 오늘은 주로 탐색적테스팅을 진행할때 많이 작성하는 테스트 차터에 대해 기재해봅니다.

What is the Test charter?

A test charter is a concise statement that defines the scope, objectives, and strategy of a test session. It typically includes information such as the target area or feature, the test idea or question, the resources and tools needed, the risks and assumptions involved, and the expected outcomes or deliverables. A test charter is not a detailed script or checklist, but rather a high-level guide that helps you focus your testing efforts and adapt to changing conditions.

https://www.linkedin.com/advice/0/how-do-you-use-test-charters-guide-your-learning

테스트 차터는 테스트를 하기위해 테스트 목적, 영역, 하는 방법, 어떻게 테스트를 진행하면 되는지 간단한 절차 등을 기재해놓은 일종의 가이드 문서라고도 할 수 있습니다.

차터는 보통 탐색적테스팅을 진행할 때 작성한다는 인식이지만, 굳이 탐색적테스팅을 할 때만 작성할 필요는 없습니다. 좀 더 범위를 넓혀서 테스트 대상에 대해 인지도가 없거나, 테스트 대상의 이해관계자이지만 테스트를 어떠한 방향으로 해야할지 모르는 사람들과 같이 협업할 때, 하나의 가이드문서로 사용할 수 있습니다.

Why use Test charter?

사실 테스트 담당자들은 테스트 설계를 진행하면서 이미 테스트 대상 프로덕트에 대해 어느 부분을 테스트해야할지 대부분 인지하고 있는 상태일 것 입니다. 그렇기 때문에 어떤 프로덕트를 테스트하는 테스트 팀은 굳이 테스트 차터를 작성할 필요는 없습니다.

문제는 테스트 대상 프로덕트/서비스 에 대해 인지도가 전혀 없는 사람과 같이 테스트하는 경우입니다. 이 경우는 작게는 개발자/테스트 담당자 이외에 기획자, 디자이너, 사업측 담당자가 같이 참여하여 테스트를 하는 Dog fooding 활동을 비롯해서, 좀 더 크게는 부서/전사적 내부 테스트를 진행할 때가 해당한다고 할 수 있습니다.

위와 같은 경우라면, 테스트 담당자가 아닌 사람들은 테스트 대상 프로덕트에서 아래와 같은 부분에서 혼동하고 잘못 이해하여, 테스트 대상 범위가 아닌 범위에서 테스트를 진행할 수 있습니다.

• 테스트 목적
• 테스트 대상 프로덕트가 제공하는 기능
• 테스트 대상 기능 / 범위
• 이미 알려진 이슈 (Known-issue)

예를 들어, 우리는 A라는 기능을 테스트해야하는데, 엉뚱하게도 B라는 기능을 조작하면 이것은 테스트를 했다고 할 순 없습니다. 물론 회귀테스트 차원에서 B의 기능을 조작해볼 필요는 있을 것이지만, 테스트의 목적이 회귀테스트를 포함한 테스트냐 아니냐에 따라 달라질 것 입니다.

이러한 경우를 방지하기 위해, 어떠한 가이드 문서의 하나로 테스트 차터를 작성합니다.

how to write test charter?

엘리자베스 헨드릭슨의 탐험적 테스팅 : 배우고 통찰하며 개선하는 소프트웨어 테스트 (인사이트 출판) 에서는 테스트 차터는 기본적으로 아래의 요소가 포함되어야한다고 말하고 있습니다.

• 목표 : 어떤 기능이나 요구사항일 수도 있고, 특정 모듈일 수도 있다.
• 자원 : 테스트에 도움이 될만한 도구, 데이터, 기술, 환경 설정 등을 기재한다.
• 정보 : 어떤 종류의 정보를 테스트하고 싶은지?

테스트 차터는 엄청 형식적인 문서도 아니고, 어려운 문서도 아닙니다. 그러나 좋은 테스트차터를 만들기 위해서는 몇가지 포함되어야할 요소들이 있습니다.

• 테스트 개요
• 테스트 대상 기능 (티켓이 있다면 티켓을 링크해도 좋음)
• 테스트 목표 (테스트를 통해서 무엇을 확인하고자 하는지)
• 테스트 스케쥴
• 테스트 대상 기능에 대한 테스트 상세 범위
• 테스트 수행환경 및 테스트 수행자
• 테스트 수행 방법
• 이슈 정리 방법

테스트 개요

보통 테스트차터는, 테스트 세션을 기획하고 진행하는 사람이 작성하여 테스트 참여자들에게 공유하게됩니다. 세션 기획자는, 이번 테스트 세션이 왜 진행하게 되었는지를 간략하게 설명해야하빈다. 그래야 테스트 참여자들이 왜 테스트를 하는지 명확하게 이해할 수 있을 것 입니다.

테스트 대상 기능

당연하게도 테스트 세션에서 어떠한 기능에 대해 테스트할 것인지를 기재합니다. 개발자나 기획자가 만든 티켓이 있다면 해당 티켓을 문서에 같이 기재하는 것이 tracability 를 위해서도 좋습니다.

테스트 목표

이번 테스트 세션을 통해서 이루고자하는 목표가 무엇인지를 명시합니다. 작게는 테스트 대상 기능의 정상동작 확인부터, 좀 더 세부적으로는 테스트 대상 기능에 특정 상태에서의 버그가 없는지 등을 기재할 수 있을 것입니다. 또는 요구사항/스펙 문서를 인용하여 꼭 동작되어야하는 내용, 비즈니스적으로 무엇을 제공하고 싶은지 등을 기재해볼 수도 있습니다.

그러나 테스트 차터를 이용한 테스트는, 일반적으로는 구체적인 테스트케이스 없이, 정해진 시간동안 자유롭게 조작하며 테스트하는 것을 목적으로 하기 때문에, 오히려 너무 세부적인 테스트 목표를 기재한다면 테스터의 인식을 제한해버릴 수도 있습니다.

테스트 스케쥴

테스트 세션을 진행할 일정/시간 등을 기재합니다.

테스트 대상 기능에 대한 상세 범위

테스트 대상 기능에 대해서, 좀 더 구체적으로 테스트를 해야할 컴포넌트들에 대해 기재할 필요가 있다면, 기재합니다.

테스트 수행 환경 및 테스트 수행자

이 부분을 역할을 나누어서 역할 및 조작환경을 명시화하고 제한하는 역할입니다. 수행 환경이란, 어떠한 OS나 단말기가 될 수 있으며, 서버나 특정 조건을 충족하고 있는 유저계정으로 로그인한 경우등이 포함될 수 있습니다.

이러한 수행환경에 대해, 테스트 세션 참여자들을 확인하여 적절히 분배하여 테스트 수행자를 기재합니다.

테스트 수행 방법

테스트 수행 환경과 조금 겹치는 내용입니다. 특정 기능의 경우에는, 특정 조건이 충족되는 경우에만 조작이 가능할 수 있습니다. 이러한 경우라면 세션 개최자가 미리 준비하여 테스트 참여자들에게 제공하는 것이 일반적이나, 그것이 어려운 경우에는 테스트 참여자들에게 해당 조건을 충족한 후에 테스트를 진행하게끔 가이드되어야합니다.

예를 들어, 일반 고객이 아닌 VIP 고객으로 로그인한 후에 조작을 해야하는 기능이라면, 세션 개최자가 VIP고객의 계정을 테스트 참여자 수에 맞추어 미리 준비 후 제공해야합니다.
그렇게하지 못하는 경우에는 미리 제약조건을 명시하고, 해당 조건을 충족(VIP 등급으로 등급업)하기 위해 어떠한 조작을 해야하는지를 기재해야합니다.

이슈 정리 방법

테스트를 진행하면서 이슈가 발생한다면, 어떻게 해야할지를 정의합니다. 참여자가 직접 티켓을 생성할 수도 있겠으나, 참여자 수가 많거나, 테스트담당자가 아닌 사람들도 테스트에 참여한다면 티켓을 등록하는 것 또한 시간이 많이 걸릴 수도 있습니다. 이러한 경우에는 메모장이라던지, 채팅방에 간단하게 문제현상/재현경로/전제조건 등을 기재하라고 가이드 할 수 있을 것입니다.

테스트 세션 개최자는 테스트 종료 후에 이슈내용을 정제/정리하여 리포트해야합니다.

좀 더 좋은 테스트 차터란...?

제가 생각 하기에 위 사항들이 포함되어야 좋은 테스트 차터인 것 같긴 합니다만, 좀 더 추상적으로는

테스트 순서를 하나하나 일일이 구체적으로 명시하지 않으면서도, 테스트가 나아가야할 방향을 제시하는 차터가 좋은 차터

라고 말할 수 있을 것 같습니다. 차터를 너무 구체적으로 기재한다면 오히려 테스트케이스를 세션 참여자들에게 공유하는 것이 더 좋을지도 모릅니다.

When write test charter?

테스트 차터를 작성할 시기는 따로 정해져있진 않습니다. 보통 탐색적테스팅 세션을 진행하기 직전에 작성해도 문제될 것은 없습니다.

그러나, 탐색적 테스팅을 할꺼야! 라는 계획이 프로젝트 초기단계부터 정해져있다면, 요구사항 정의 단계부터 테스트차터를 작성하는 것도 하나의 방법일 수 있습니다. 이것은 추후 테스트 케이스를 작성할 때 좀 더 도움이 될 수 있을 뿐더러, 요구사항 리뷰 / 테스트케이스 리뷰시간에 이 차터를 활용해서 리뷰를 진행해볼 수도 있을 것 입니다.

프로젝트 초기부터 테스트차터를 작성한다고 한다면, 아래 내용을 확인하며 작성하면 좋을 것 입니다.

• 소프트웨어에 대해 조작해도 되는 행동과 그렇지 않은 행동들 (만약 ~~한다면?)
• 이해관계자들이 신경쓰는 것들

끝!

---

Ref

• 엘리자메스 헨드릭슨, 『탐험적 테스팅 : 배우고 통찰하며 개선하는 소프트웨어 테스트』, 오광신 옮김, 인사이트(2014)
• https://www.linkedin.com/advice/0/how-do-you-use-test-charters-guide-your-learning