테스트 케이스 작성 전략

QA Engineer에게 가장 기초적으로 필요한 역량은 테스트 케이스를 작성하는 것 같습니다. 테스트 케이스를 작성하는 것이 필수적인 역량이지만 또 고민하다 보면 끝이 없는 업무이면서 경력이 쌓일수록 어렵게 느껴지는 역량이라고 생각됩니다.

오늘은 제가 실무를 하면서 배운 테스트 케이스에 대한 이야기를 해볼까 합니다. 이론적인 내용들도 물론 중요하지만 실무에서는 어떻게 사용되는지 저는 어떻게 작성하고 있는지에 중점을 두게 될 것 같습니다.

 

테스트 케이스란?

테스트 케이스(Test Case)는 소프트웨어 또는 시스템이 특정 요구사항이나 기능을 정확하게 수행하는지 확인하기 위해 작성된 일련의 절차와 조건을 말한다. 간단히 말해, 주어진 입력에 대해 예상되는 결과가 나오는지를 검증하는 구체적인 방법이다. 각 테스트 케이스는 특정한 시나리오나 기능을 테스트하며, 소프트웨어가 요구사항에 부합하는지, 혹은 예상하지 못한 오류가 발생하지 않는지를 확인하는 중요한 문서이다.

 

테스트 종류

먼저 테스트 케이스에 대해 알아보기 전에 테스트 종류에 대해 알아보자. 테스트에 따라 테스트 케이스가 다르게 작성될 수 있으며 테스트 케이스의 구성 또한 달라질 수 있다. 테스트의 종류로는 크게 기능 테스트와 비기능 테스트가 존재하고 각 영역에서도 여러 단계의 테스트가 존재한다.

오늘 이야기할 테스트 케이스는 단위 테스트와 회귀 테스트에 대한 이야기이며 명칭이 사용하는 사람에 따라 달라질 수 있고 테스트 케이스의 경우 개인 성향 또는 팀 성향이 강한 부분이라 동의하지 않는 내용일 수도 있다.

 

테스트 케이스 작성하기

단위 테스트 케이스

사실 단위 테스트는 개발자 관점에서 개발 초기 단계에서 개별 모듈이나 함수가 올바르게 동작하는지 검증하는 테스트이지만 QA Engineer 관점에서도 단위 테스트가 존재한다고 생각한다. 개인적으로는 이를 기능 테스트라고 칭하지만 이곳에서는 QA Engineer 관점의 단위 테스트라고 하자. QA Engineer 관점에서의 단위 테스트는 각 컴포넌트 별 기능 테스트를 의미한다.

구글 로그인 화면

 

구글 로그인 화면을 예로 든다면

- Google(로고)

- Chrome에 로그인(타이틀)

- Google 계정 사용(서브 타이틀)

- 이메일 또는 휴대전화 입력 필드

- [다음] 버튼

등..

 

각 컴포넌트를 개별 단위로 테스트 케이스를 작성하는 방법입니다. 이는 새로운 기능에 대해 빠르게 테스를 수행하고 요구사항에 맞도록 디자인 또는 설계된 것인지 확인 가능하도록 작성한다.

 

개인적으로 이 단위 테스트 케이스는 휘발성이 강한 테스트 케이스이며 주기적으로 바뀌는 기획과 디자인에서 애자일 하게 작성하고 수행할 수 있는 방법이라고 생각한다.

 

 

 

 

예를 들어 단위 테스트 케이스를 작성한다면 아래와 같이 작성된다.

TestCase ID	Precondition	Step	Expected Result	Status
로그인 화면
TC-001	-	-	[Google] 로고 노출
TC-002	-	-	"Chrome에 로그인" 타이틀 노출
TC-003	-	-	"Google 계정 사용" 서비 타이틀 노출
TC-004	-	-	[이메일 또는 휴대전화] 입력 필드 노출
TC-005	-	[이메일 또는 휴대전화] 입력 필드 > "1234" 입력	[이메일 또는 휴대전화] 입력 필드에 "1234" 입력되어 노출
TC-006	-	-	[다음] 버튼 노출
...

 

극단적으로 컴포넌트를 나눠 예시가 작성되었지만 단순히 노출되는 컴포넌트는 하나의 케이스로 작성하고 동작을 통해 기대결과가 바뀌는 케이스는 별도로 작성한다면 아래와 같이 케이스를 줄여 작성할 수 있다.

TestCase ID	Precondition	Step	Expected Result	Status
로그인 화면
TC-001	-	-	- [Google] 로고 노출 - "Chrome에 로그인" 타이틀 노출 - "Google 계정 사용" 서비 타이틀 노출 - [이메일 또는 휴대전화] 입력 필드 노출 - [다음] 버튼 노출
TC-002	-	[이메일 또는 휴대전화] 입력 필드 > "1234" 입력	[이메일 또는 휴대전화] 입력 필드에 "1234" 입력되어 노출

 

이런 식의 단위 테스트 케이스는 기획서와 디자인을 통해 작성할 수 있어 큰 고민 없이 기계적으로 작성할 수 있으며 사용자가 마주하는 모든 컴포넌트에 대해 기본적인 테스트를 수행할 수 있다.

 

개인적으로는 새로운 기능이 추가되거나 변경되는 경우 위와 같은 테스트 케이스를 작성하여 Feature QA를 수행한다. 위와 같은 단순한 테스트 케이스의 테스트는 QA Engineer가 수행할 수도 있지만 함께 기능을 개발에 참여하는 기획자, 디자이너, 개발자 등 나눠서 수행이 가능하며 단순한 테스트이지만 새로운 기능의 테스트 커버리지를 높이는데 큰 역할을 한다고 생각한다.

 

다만 위와 같은 단위 테스트 케이스는 다른 기능들과의 통합 테스트가 수행되지 않으며 추후에 진행되어야 하는 Regression Test에서 사용하기에 어려움이 있다. 테스트 케이스가 미시적인 관점에서 작성되었으며 사이드 이펙을 확인하기 위한 Regression Test에서는 의미 있는 테스트가 수행되지 않기 때문이다.

 

테스트 케이스를 작성하고 관리하는 측면에서 서비스의 기능이 확장되고 지속적인 유지보수를 해야 한다면 테스트 케이스를 작성하는 것보다 테스트 케이스를 줄이는 일이 더욱 어렵다는 것을 깨닫는 시점이 온다. 계속해서 늘어나는 테스트 케이스와 이 모든 테스트 케이스들에 대한 유지보수 비용이 계속해서 커지기 때문이다.

 

필자는 이런 점을 해결하려 단위 테스트 케이스 외 Regression Test Case를 별도로 작성한다. 

 

회귀 테스트 케이스 

회귀 테스트를 위한 테스트 케이스를 별도로 작성하는 이유는 유지보수 비용을 최소화하기 위함이다. 단위 테스트 케이스를 그대로 사용할 수도 있지만 각 컴포넌트에 초점이 맞춰진 테스트로는 사이드 이펙을 확인하기 위한 회귀 테스트에는 맞지 않다고 생각할뿐더러 회귀 테스트 케이스는 사용자 관점에서 유저 시나리오로 작성하기 때문이다.

 

단위 테스트 케이스에서는 사용자가 마주하는 UI 기반으로 테스트 케이스를 작성했다면 회귀 테스트 케이스에서는 사용자가 서비스를 이용하면서 마주하는 Flow를 기반으로 테스트 케이스를 작성하고 있다. 예를 들어 동일한 로그인 화면에 대한 테스트를 수행하게 되면 유저 시나리오에서는 아래와 같은 테스트 케이스가 도출된다.

TestCase ID	Test Title	Priority	Precondition	Step	Expected Result	Status
로그인
TC-001	비로그인 유저가 유효한 로그인 정보 입력 시 로그인 가능	Highest	비로그인 유저	1. 로그인 화면 > ID 입력 2. [다음] 버튼 선택 > PW 입력 3. 다음] 버튼 선택	- 로그인 완료 화면 노출
TC-002	비로그인 유저가 유효하지 않은 이메일 입력 시 오류 문구 노출	Medium	비로그인 유저	1. 로그인 화면 > 유효하지 않은 이메일 주소 입력 2. [다음] 버튼 선택	- 이메일 입력 필드 하단 "올바른 이메일 또는 휴대전화 번호를 입력하세요" 문구 노출
...

 

단위 테스트 케이스와 크게 달라진 점은 테스트 타이틀을 기입해 주는 것과 우선순위가 생겼다는 것이다. 컴포넌트 단위별로 테스트 케이스를 작성하게 되면 테스트 스텝과 기대결과에서 어떤 기능을 테스트하는지 명확하게 알 수 있지만 시나리오 기반에 테스트 케이스를 작성하게 되면 스텝과 기대결과가 길어져 어떤 테스트를 하게 되는지 명확하지 않을 수 있다. 이러한 불편을 해소하기 위해 테스트 타이틀을 작성하여 어떤 테스트를 위한 테스트 케이스 인지를 명확히 하고 타이틀에 given, when, then 형식을 기입하여 타이틀만으로도 테스트가 수행가능하도록 하면 가독성이 더욱 좋아진다.

 

두 번째 큰 다른 점은 테스트 케이스의 우선순위를 기입하는 것이다. 단위 테스트 케이스도 우선순위를 기입할 수 있지만 개인적으로 크게 중요하진 않다고 생각한다. 단위 테스트 케이스는 테스트를 수행하기 위해선 각 케이스들이 독립적이지 못하고 이전 케이스를 수행해야 다음 케이스를 수행할 수 있는 경우가 대부분이다. 이러한 이유로 우선순위를 작성하다고 해도 필터링하여 테스트를 수행하기 어렵다. 반면 시나리오 기반에 테스트 케이스는 최대한 독립적으로 작성되며 하나의 테스트 케이스만 봐도 테스트를 수행할 수 있다.

 

물론 시나리오 기반으로 테스트 케이스를 작성하게 되면 특정 문구나 디테일한 기능은 놓쳐질 수 있다. 허나 사용자가 실제 사용하는 시나리오 기반으로 테스트되기 때문에 사이드 이펙을 확인하거나 앱을 사용하는 데 있어 주요 기능들을 확인하기에 용이하다.

 

단위 테스트 케이스를 작성하고 회귀 테스트를 위해 다시 회귀 테스트 케이스를 작성하는 것에 간혹 테스트 케이스를 중복으로 작성하는 것이냐는 질문이 있을 수 있다. 허나 필자는 이것이 중복 작성이라고 생각하지 않는다. 단위 테스트와 회귀 테스트는 엄연히 테스트의 목적이 다르다. 그에 따라 다른 목적으로 작성된 테스트 케이스이지 중복 작성된 테스트 케이스라고 생각하진 않는다.

 

물론 실무적인 관점에서 일정이나 기능의 크기에 따라 어느 한쪽은 Skip 될 수도 있고 모든 테스트 케이스가 작성되지 않을 수도 있다. 다만 개인적으로 업무를 했을 때 테스트 케이스를 관리하는 측면에서 회귀 테스트 케이스와 특정 기능을 위한 테스트 케이스는 별도로 존재하는 것이 좋다고 생각한다.

 

탐색적 테스트 케이스

탐색적 테스트 케이스는 테스트 케이스를 작성하기 어려운 상황에서 경험적인 측면을 이용해 테스트 케이스를 작성하는 방법이다. 실무에서도 자주 사용되는 부분이다. 실무에서는 테스트 케이스를 모두 수행했으나 기능상 중요도가 높아 추가적인 테스트가 필요한 경우나 일정상 테스트 케이스를 작성하기 힘든 경우 등 여러 가지 상황에 테스트 케이스를 작성하거나 수행하기 어려울 때 사용된다.

Mission : 로그인 기능을 확인한다. Goal - 유효한 정보로 로그인이 가능하다. - 유효하지 않은 정보로는 로그인이 불가능하다. - ... Limit Time : 15 min
TestCase ID	Precondition	Step	Actual Result	Status
TC-001	비로그인 상태	이메일 정보 "1234"입력	"올바른 이메일 또는 휴대전화
TC-002	비로그인 상태	이메일 정보 "adbced123@1234.com" 입력	비밀번호 입력화면 노출
...

 

동일한 기능을 탐색적 테스트 케이스로 작성한 예시이다. Mission, Goal, Limit Time만 정해진 상태에서 경험기반으로 테스트를 수행하며 어떤 테스트를 수행했는지 케이스를 작성한다. 탐색적 테스트를 수행하는 경우 예상치 못한 이슈를 발견하거나 기존부터 잠재되어 있던 이슈를 발견하는 경우가 많아 자주 사용되는 테스팅 기법이다.

 

다만 탐색적 테스트 케이스를 작성하고 수행할 때 유의해야 하는 부분은 Mission과 Goal이다. 어떤 기능에 대해서 테스트를 수행할지 목적과 범위를 인지하지 않은 상태에서 경험기반 테스트를 수행하게 되면 테스트 범위를 벗어나 엉뚱한 영역을 테스트하기 십상이기 때문이다.

 

탐색적 테스트 케이스는 작성이 되면 테스트 결과 리포트에 함께 첨부가 되긴 하지만 작성된 테스트 케이스를 회귀 테스트 케이스에 추가하는 일은 드물기 때문에 Mission, Goal, Limit Time 템플릿만 지속적으로 관리하며 재사용한다.

 

정리

개인적으로 실무를 수행하며 작성하는 테스트 케이스는 단위 테스트 케이스, 회귀 테스트 케이스, 탐색적 테스트 케이스 이렇게 세 가지 종류가 있습니다. 아직 많은 분야의 도메인에서 테스트 경험해보지 못해 스스로 갇혀있는 지식을 수도 있습니다.. 하지만 처음 테스트 케이스 작성 및 유지보수 전략을 만들어야 하는 팀이나 개인에게 시행착오를 줄일 수 있는 내용이었으면 합니다.