요구 검증을 위한 테스트 케이스 작성은 어떻게 해야 하나요? (feat.설계)

질문

ISTQB에는 테스트 케이스 작성하는 방법에 대한 내용이 없네요. 테스트 케이스는 왜 작성해야 하나요? 그리고 테스트 케이스를 어떻게 작성해야 할지 모르겠습니다.

ISTQB 버전

ISTQB Syllabus 2018

답변

테스트 케이스란?

ISTQB 실라버스에서는 테스트 케이스에 대해 "특정 프로그램 경로를 실행하거나 특정 요구 사항을 준수하는지 확인하기 위해 특정 목표 또는 테스트 조건을 개발된 입력값, 실행 사전 조건, 예상 결과 및 실행 사후 조건의 집합이다."라고 정의하고 있습니다.

하지만 ISTQB에서는 테스트 케이스 작성 방법에 대한 안내에 대해서는 설명하지 않습니다. ISTQB는 국제 표준에 가깝고 실무 안내서가 아니기 때문에 그렇습니다. 그래서 ISTQB 자격증을 획득한 사람들도 '실무와 거리가 멀다'라는 의견을 표현하곤 하는데, 사실 ISTQB는 실무와 매우 가깝습니다. '어떻게 해라'라는 방법을 콕 찝어서 설명하지 않는다고 해서 실무와 관련 없는 건 아닙니다.

어쨌든 대부분의 테스터들은 회사에 입사해서야 테스트 케이스 작성 방법에 대해 배우는 경우가 많습니다. 어느 정도 경력이 있는 QA나 테스터라면 여러 종류의 테스트 케이스를 많이 보았거나 작성해 봤을거라 생각합니다. 아마도 실제로 보시면 대부분의 실무에서 작성한 테스트 케이스는 사실 ISTQB 실라버스의 정의에서 이야기한 내용들이 포함되어 있다는 걸 아시게 됩니다. 필자 같은 경우 테스트 케이스 작성 시 아래의 내용들을 포함하여 작성하고 있습니다.

기획서 / 화면설계서 / 스토리보드 등 No.
메뉴 경로 - 분류 (대 / 중 / 소 / 기능명)
사전 조건, 테스트 데이터
시나리오 or 스텝
기대 결과
테스트 결과 입력 - PASS | FAIL | N/A | N/S | BLOCK
이슈 No. → 이걸 작성하는 이유는 아래 설명하겠지만 매우 중요한 개념
확인자
비고

샘플 포멧은 아래와 같습니다. 테스트 케이스의 형태는 회사마다, 제품마다 다르게 작성되므로 '대략적으로 이렇게 생겼구나' 정도로 이해해 주시면 됩니다.

이 포맷은 필자가 오랜 시간 수많은 테스트 케이스를 작성하면서 개선하고 수정하면서 나름의 최적의 테스트 케이스 포맷이라 느끼고, 근래에는 포맷의 수정 없이 잘 사용하고 있는 포맷입니다. 현재는 테스트 케이스 관리 도구(Zephyr, Xray 등)를 통해 작업을 하고 있지만 업무 외적인 테스트 활동을 할 때는 어김 없이 위 포맷을 통해 테스트 케이스를 작성하고 수행하고 있습니다.

필자가 이야기하고 싶은 내용은 구글링해도 많이 나오는 테스트 케이스 포맷에 대한 이야기를 하려는 것은 아니고, 결론부터 이야기하면 테스트 케이스 활용 목적에 따라 작성법과 수행 방법이 달라져야 한다고 이야기 하려 합니다. 이러한 개념을 ISTQB에서는 테스트 케이스 설계라고 말합니다.

테스트 케이스에 항목들을 구분하는 이유는 버그를 효율적으로 보고하기 위해서입니다. 어떤 항목들을 고려해야 하는 지에 대해서는 '버그 보고'와 관련한 필자 중 한명의 개인 블로그를 참고해 주세요. - 테스팅-버그보고-04편

테스트 케이스 설계란?

테스트 케이스 설계는 영어로 Test Case Design이라고 표현합니다. 여기서 우선 설계(디자인)라는 단어 뜻을 알아야 합니다. 소프트웨어 설계 또는 소프트웨어 디자인이라고 해석하는 Software Design은 "소프트웨어 해결책을 위한 문제해결과 계획 과정이다. 소프트웨어의 목적과 명세가 결정되면 개발자가 설계하거나 설계자를 고용하여 해결책을 위한 계획을 개발하도록 한다. 저수준 요소와 알고리즘 구현 문제, 그리고 구조에 대한 조망이 포함된다."라고 위키백과에 표현되어 있습니다.

필자가 직접 번역했다보니 번역이 조금 어색할 수 있지만 뜻을 좀 직역하면 "설계(디자인)에서 가장 중요한 단어는 문제해결과 계획 과정"이라는 것입니다. 그러므로, 테스트 케이스 설계라는 것은 문제 해결을 위해 테스트 케이스를 개발하고 테스트 수행 계획을 세우는 것을 의미한다고 볼 수 있습니다.

하지만, 이번 글은 테스트 설계를 어떻게 해야 잘 할 수 있는가에 대해 기법을 소개하는 내용이 아닙니다. 필자는 이번 글에서는 테스트 케이스를 작성하는 목적을 알아보고, 수립된 목적을 잘 풀어내어 효과적이고 효율적인 테스트 케이스 작성 방법을 알아보려 합니다. 사실 테스트 케이스 작성 목적이 명확해지면 테스트 케이스 설계(디자인)를 하고, 테스트 케이스를 작성하는 게 일반적인 절차입니다. 참고하시어 아래 내용을 읽어 보시기 바랍니다.

테스트 케이스를 작성하는 목적은?

테스트 케이스를 작성하기 위해 기본 베이스가 되는 문서가 몇 가지 있습니다. 이런 문서들을 기반으로 테스트 케이스를 작성하고, 이렇게 작성한 테스트 케이스를 이용하여 진행하는 테스트 수행 방식을 ISTQB에서는 명세 기반 테스트 기법이라 부르고 있습니다. 여기서 명세 기반이라는 단어는 바로 테스트 케이스 작성에 기반이 되는 문서를 의미합니다. 테스트 케이스 작성을 위해 활용되는 대표적인 문서는 다음과 같습니다.

이렇게 명세를 기반으로 작성된 테스트 케이스의 첫 번째 목적은 바로 "요구사항 확인"입니다. 여기서 말하는 "요구사항 확인"에서 "확인"이라는 표현은 검증과 확인(Verification과 Validation)을 의미합니다. 이 두 단어의 차이점을 간단하게 설명하면 검증(Verification)은 "제품을 올바르게 만들고 있는가?"를 의미하고, 확인(Validation)은 "올바른 제품을 만들고 있는가?"를 의미합니다. 우리는 테스트 케이스를 명세 기반으로 작성하였기 때문에 제품이 올바르게 만들어졌는지를 확인하게 되는 것입니다. 그러므로 테스트 케이스 작성의 첫 번째 목적은 요구사항대로 제품이 만들어졌는지를 1차적으로 확인하기 위한 목적이 될 수 있습니다.

두 번째는 예외 케이스를 처리하기 위한 목적의 테스트 케이스입니다. 테스트 케이스의 분류는 요구사항대로 작성된 테스트 케이스와 요구사항에 명시되지 않은 예외 케이스로 분류할 수 있습니다. 요구사항대로 제품이 만들어졌는지 확인이 완료되었다면 예외적인 상황에 대한 테스트 케이스를 작성해야 합니다. 이때, 예외적인 테스트 케이스를 작성하기 위해서는 테스터의 경험이 매우 중요합니다. 누구도 요구사항을 완벽하게 분석해서 기획 명세를 만들 수는 없기 때문에 요구사항 분석에는 다양한 관점이 투입되어야 합니다. 테스터의 관점은 그 중 사용자 관점의 예외 상황들을 도출할 수 있는 관점을 제공합니다. 그러므로, 다양한 산업 환경에서 도메인 지식이 많은 테스터일수록 다양한 예외 테스트 케이스를 작성할 수 있습니다.

세 번째는 테스트 케이스의 재사용입니다. 실무에서 테스트를 하는 테스트 전문가 중 테스트 케이스를 1회성 사용으로 작성하는 사람은 없을 것입니다. 왜냐하면 우리는 리그레이션(회귀) 테스트라는 중요한 숙제를 알고 있기 때문입니다. 리그레이션(회귀) 테스트는 간단하게 신규 혹은 수정 사항으로 인해 기존 잘 동작하는 기능/비기능이 문제없이 잘 동작하는지를 확인하기 위함입니다. 이때, 우리는 기존에 작성해둔 명세 기반의 테스트 케이스를 활용하거나 예외 테스트 케이스를 재사용하게 됩니다.

테스트 케이스는 프로젝트 내에서 변경되는 기획들, 소스 코드의 변경, 혹은 개발 환경의 변화에 매우 민첩하게 반응해야 하는 영역이기 때문에 유지보수가 유연하도록 설계(디자인)하고 작성하는 것도 매우 중요합니다. 이렇게 할 수 있는게 테스트 전문가의 역량이라 할 수 있습니다.

효과적이고, 효율적인 테스트 케이스 작성 방법

프로젝트 기간은 항상 정해져 있습니다. 짧게는 1~2개월, 길게는 6개월에서 1~2년으로 프로젝트 기간을 산정합니다. 프로젝트 기간 안에는 요구사항 분석, 설계, 구현, 테스트 등등 개발 생명주기를 포함하는데요. 어디서든 계획한 대로 일정을 지키지 못합니다. 물론 계획한 대로 잘 진행되면 매우 좋겠지만 보통의 현실은 그렇지 못합니다.

그래서 발생하는 문제는 "요구사항이 명확해야 개발이 들어간다. 개발이 완료돼야 테스트할 수 있다."의 딜레마에 빠지게 되는데요. 결국 마지막에 있는 테스트 일정이 데드라인(출시일 혹은 발주사 이관)을 기준으로 줄어드는 현상이 발생합니다.

그러면 어떻게 해야 제한된 시간 내에 가능한 많은 테스트 케이스를 확인할 수 있을까요? 앞에서도 말씀드렸듯이 테스트 케이스는 시장(Market)의 시시각각 변화하는 상황에서 데이터 변동이 발생하는 경우가 실무에서는 비일비재합니다. 그렇기 때문에 변화에 매우 민첩하게 대응할 수 있도록 작성해야 합니다.

그러기 위해서 최근 필자가 근래에 많이 활용하고 있는 테스트 케이스의 모듈화를 알려 드리려고 합니다.

모듈이란? "기어 톱니의 크기를 나타낸 값. 밀리미터로 나타낸 피치원의 지름을 톱니 수로 나눈 것."입니다. 한마디로 테스트 케이스의 모듈화는 테스트 케이스를 잘게 쪼개는 것을 의미합니다.

그러나, 테스트 케이스를 잘게 쪼개기만 해서는 테스트 케이스의 양만 많아질 것이기 때문에 추가로 알아야 하는 부분이 바로 테스트 시나리오 혹은 스위트(Suite, Set)입니다. 테스트 케이스와 테스트 시나리오에 대한 자세한 설명과 차이점은 본 블로그의 다른 필진이 작성한 글을 참고하시기 바랍니다.

테스트 시나리오는 하나의 흐름으로 시작과 끝이 있는 반면에 ISTQB에서 이야기하는 스위트(Suite)에는 해당 테스트 케이스를 쪼개진 것을 합쳐놓는다는 것에서 사용법이 조금 차이가 있습니다. 물론 스위트(Suite)를 테스트 시나리오와 같이 사용할 수도 있습니다.

로그인에서 A, B, C 기능을 포함하고 로그아웃까지 수행하는 테스트 시나리오가 있다고 가정해 보겠습니다. 이때, [A-1] 기능은 [A]와 연관된 영역으로 리그레이션(회귀) 용도로 추가되었고, [B] 기능은 로그인 기능에서 일부 수정되는 기능입니다. [C] 기능의 경우 [B]의 수정 영향으로 시나리오 수행이 어려워 제외한 테스트 케이스입니다.

이렇게 사용할 때 가장 중요한 것은 시나리오의 흐름을 중간에 멈추지 않고 로그인 ~ 로그아웃을 수행할 수 있어야 합니다. 흐름이 무너지지 않는 선에서 테스트 케이스 모듈을 넣어다 뺐다 할 수 있도록 하는 것이 중요합니다. 또한, 영향 범위를 명확히 알 때 시나리오를 구성하면 테스트 케이스 수행이 매우 효과적으로 될 수 있습니다.

또한, 이렇게 테스트 케이스를 모듈화하여 시나리오까지 구성이 되면 나아가 테스트 자동화 시나리오로도 활용이 가능합니다. 테스트 자동화 시나리오 작성법에 대해서는 나중에 따로 글을 작성해서 설명해 드리겠습니다.

테스트 케이스를 작성해야 하는 이유는?

우리는 회사에서 일합니다. 회사는 사업을 합니다. 사업은 영업 이익을 창출하기 위해 진행하는 활동입니다. 다시 말해, 영업 이익을 창출하기 위해 회사는 사업을 하고, 이를 위해 「사업 요구사항」을 도출합니다. 이 도출된 요구사항을 기반으로 제품과 서비스에 대해 기획을 하고, 시스템을 설계하고 구현합니다.

테스트 케이스는 처음에도 말씀드렸듯이 가장 주된 목적은 바로 사업의 요구사항이 잘 반영되었는지 확인하기 위함입니다. 영업 이익을 창출하기 위한 요구사항을 분석하는 테스트 관점을 더하고, 구현된 프로그래밍 결과물을 요구사항에 기반하여 확인(Validation)하기 위한 목적이죠. 그다음 목적은 예외적인 케이스에 대한 확인, 그리고 마지막으로 기존 기능에 문제가 없는지 확인하기 위함입니다.

그리고 QA라고 하는 포지션을 가진 품질 보증을 하는 분들을 위한 얘기를 간단하게 하자면 소프트웨어 품질을 정량적으로 측정하기는 불가능한 것을 잘 알고 계실 텐데요. 그래서 보통은 정량+정성을 잘 믹스해서 QA 리포트를 발행하곤 할 겁니다. 그리고 이런 정량적 측정을 가능하게 하는 것이 바로 테스트 케이스입니다. 테스트 케이스의 모수를 통해 품질률을 측정하는 것이 바로 그 시작입니다.

예를 들면, 요구 사항대로 작성된 테스트 케이스 100개 > 모두 수행하고, 실패가 없다면 품질률은 100%로 QA 리포트를 발행하면 됩니다. 하지만, 현실 세계의 우리에게는 예외 케이스 발생을 피할 수 없습니다. 물론 요구 사항 명세를 100% 다 작성했다 하더라도 사전 작업 즉, 요구 사항 누락이 발생하거나, 시장 상황이 변화하면서 요구사항이 변경될 수 있습니다. 이런 경우라면 테스트 케이스 수행을 100% 수행했다고 하더라도 빈틈이 발생하는 것이 현실입니다. 그래서 우리는 가정을 합니다. 요구사항 = 테스트 케이스를 100%으로 보자는 약속입니다. (테스트 수행 전 테스트 계획을 리뷰해야 하는 이유는 바로 그 약속을 하기 위함입니다.)

추가로 탐색적 테스트를 통해 발견한 이슈에 대한 리그레션 테스트 케이스를 +alpha로 더해 전체 테스트의 모수로 보자고 약속할 수 있습니다.

그래서 테스트 케이스 작성 포맷에 "이슈 No"를 넣습니다. 다시 한번 간단하게 말씀드리면 바로 「테스트 수행을 위한 준비 작업인 테스트 케이스」와 「테스트 수행 후 발생하는 테스트 이슈」의 분리해서 생각하기 위함입니다. 이 말은 더 단편적으로 표현하면 "이슈 내용 = 테스트 케이스는 아니다."라는 말입니다.

현업에서는 많은 사람들이 Jira나 레드마인에 등록한 이슈로 내용만을 보고 '확인 테스트'를 수행하곤합니다. 그 행위 자체가 잘못된 것은 아니지만 품질률을 측정하는데 요구사항을 중복으로 분석하고, 특정 부분만 집중적으로 테스트하고 나서 '살충제 패러독스'가 발생하면 "우리 제품엔 버그가 없어" 라는 착각을 하게 됩니다.

그래서 이슈와 테스트 케이스는 분리해서 관리해야 합니다. 그리고, 이슈에는 필수적으로 어떤 테스트를 수행하다가 발생했는지 테스트 케이스가 링크되어 있거나, 재현 방법이 기록되어 있어야 합니다.

마치며

테스트 케이스 작성을 어떻게 해야 가장 좋다는 정답은 없습니다. 자신이 속해있는 회사와 사업, 그리고 그 사업이 속해 있는 도메인(산업군)에 최적화된 테스트 케이스를 설계하고 작성해야 하며, 이는 매우 중요합니다. 가장 중요한 것은 사업의 요구사항을 이해 해야 한다는 점이며, 이를 잘 할 수 있는게 테스트 전문가(Test Expert)로서 갖추어야 할 역량입니다.

인터넷 검색을 이용해서 어딘가에서 가져온 다른 사람이 만든 테스트 케이스 포맷만을 가져다 자신이 속해 있는 회사 제품의 테스트 케이스를 작성하는 건 매우 위험한 일입니다. 해당 테스트 케이스의 형태가 본인 회사의 사업과 요구사항을 분석하는 데에 적합치 않을 수 있기 때문입니다. 테스트 케이스 포맷은 일반적일 수 있지만 테스트 케이스 설계 및 작성은 일반적일 수 없다는 것을 명심하시길 바랍니다. 물론, 위에 작성된 내용은 필자들의 경험에 의한 방법이고 모든 사업과 프로젝트에 일반화할 수 없습니다.

사업을 이해하고, 고객 요구사항을 이해하여, 수익을 창출해야 하는 것이 일을 잘하는 사람이겠죠. 테스트 전문가에겐 테스트 케이스 설계를 잘 하는게 프로그래머와 구분할 수 있는 테스터의 경쟁력이며, 이 역량을 키우는 일이 경쟁력 있는 테스트 전문가가 될 수 있는 방법입니다. 테스트 케이스 모듈화의 노하우를 통해 자신만의 테스트 케이스 설계 및 작성 방법을 찾아보시길 바랍니다. 감사합니다.