18화 테스트 설계 기법 의사결정 테이블

소프트웨어 테스팅

실무 요구사항 중 어떠한 조건의 조합 수에 따라 테스트 디자인 필요한 경우가 많습니다. 그러다 보니 테스터들은 알게 모르게 의사결정 테이블 기법을 활용하고 있지만, 정석적인 기법 활용법을 모르거나 피상적으로만 알고 있는 경우가 많습니다. 간혹 의사결정 테이블은 실무에서 사용하지 않는다고 얘기하는 경우도 있습니다. 그럴 수는 없을 텐데 말이죠. 알게 모르게 사용하고 있는 의사결정 테이블에 대해 알아보겠습니다.

의사결정 테이블은 논리적인 조건과 상황이 있는 시스템에서 요구사항을 분석하여 테스트 디자인하도록 돕는 기법입니다. 즉 입력값의 조합에 따른 출력 값을 참과 거짓으로 표현하며 테스트를 디자인하는 방법이죠.

예를 들어, 쇼핑몰 할인 적용 여부 테스트가 필요합니다. 사용자가 할인된 가격에 구매하기 위해서는 2가지 조건을 만족해야 합니다. 첫 번째 조건은 사용자가 50만 원 이상 결제, 두 번째 조건은 쇼핑몰 회원 등급이 일반, 실버가 있다고 했을 때 실버 등급이어야 합니다. 2가지 조건을 모두 만족시킨 사용자(할인받으려는 계정)에 한해서만 상품 결제 시 최종 금액이 할인됩니다.

어떻게 테스트해야 할까요? 탐색적 테스팅이나 애드훅 테스팅과 같은 경험 기반 기법으로 하는 것이 좋을까요? 의사결정 테이블 기법을 활용해서 명세 기반으로 진행하는 것이 좋을 것 같은데요. 경험 기반 기법은 조건이 많을수록 놓칠 수 있고 테스트 추적 관리가 어렵기 때문이죠. 어떻게 디자인하면 좋을까요?

위 요구사항을 테스트하려면 총 4개의 테스트 케이스가 필요하겠네요. 결제 금액이 50만 원이고 실버 회원인 경우는 정상적인 상황에서의 테스트입니다. 조건 조합에 따른 3가지 할인 미적용 케이스는 예외 케이스가 됩니다. 위처럼 논리적인 조건과 상황이 있는 기능에서 예외 케이스를 뽑아내는 기법을 의사결정 테이블이라고 합니다.

의사 결정 테이블 케이스 도출 개수는 2의 n승입니다. 어떠한 조건을 만족시키고, 시키지 않는다로 나뉘기 때문이죠. n승의 의미는 얼마나 많은 조건이 있는지에 대한 개수입니다. 위 표에선 2가지 조건이었죠? 그러므로 2의 2승이기에 4개의 테스트 케이스가 도출된 것입니다. 만약 할인 조건에 최근 결제한 금액이 20만 원 이상이라는 조건이 추가된다면 2의 3승이므로 총 8개의 테스트 케이스가 도출되겠죠.

좀 더 깊게 알아볼까요? 이번엔 다른 조건을 알아보겠습니다. 예를 들어 상품 구매 테스트가 필요합니다. 결제 방식은 3가지입니다. 신용카드, 계좌이체, 무통장입금으로 하겠습니다. 조건의 조합은 도출되었죠? 바로 신용카드, 계좌이체, 무통장입금입니다. 해당 조건을 입력했을 때 출력 값은 무엇일까요? 상품 구매가 되거나 그렇지 않은 것이 출력 값입니다.

의사 결정 테이블을 사용해서 8개 테스트 케이스를 도출했습니다. 그런데 무언가 이상하죠? 신용카드와 계좌이체와 무통장입금을 동시에 결제할 수 없기 때문에 유효하지 않는 조합이 됩니다. 2개 값이 참인 경우도 마찬가지고요. 즉 2개가 거짓이어야 유효한 테스트가 됩니다.

유효한 테스트를 위해 8개의 조건 조합을 4개로 줄였습니다. 실제로 벌어질 수 없는 원인과 결과를 제거했습니다. 따라서 의사결정 테이블로 3가지 결제방식에 대한 상품 구매 테스트를 하려면 4개의 테스트 케이스가 필요합니다. 각 조건이 1번씩 참인 경우와 모두 거짓인 경우 결제 방식 팝업 노출 여부까지 검증해보면 되겠죠.

의사결정 테이블 활용 과정을 살펴봤을 때 '처음부터 조건 조합을 4개로 생각해내서 하면 될 걸 왜 그렇게 어렵게 생각하지?'라고 느끼실 수 있습니다. 하지만 실무 요구사항들은 간단하지 않습니다. 안전하고 신뢰성 있는 테스트 커버리지를 확보하려면 위와 같이 의사결정 테이블 표를 사용해서 천천히 생각해보며 케이스 도출하는 것이 효과적입니다.

머릿속으로 수백 개의 원인과 결과를 생각해낼 수 있고 케이스화 시킬 수 있다면 굳이 위처럼 진행하지 않아도 괜찮겠죠? 하지만 그럴 가능성은 희박하기에 꼼꼼하게 진행하기 위해서는 정석적인 방법을 권장합니다. 또한 위 예시에서는 출력 값도 비교적 간단하게 작성한 것이고 실무 요구사항은 조건도 많고 조건에 따른 출력 조합도 많습니다.

여기까지 의사결정 테이블 기법을 알아보았습니다. 사실 저는 실무 진행 간에 의사결정 테이블을 많이 사용하지 않았던 것 같습니다. 실무에서 테스트 디자인 필요한 요구사항들은 꽤나 복잡한 시스템으로 이뤄지는 경우가 많습니다. 만약 의사결정 테이블 기법을 활용하면 테스트 설계 비용이 지나치게 높아집니다. 또한 조건이 복잡할수록 누락하는 경우가 생기는데, 그러한 경우 이전에 작성된 조건의 조합을 다시 살펴봐야 합니다. 따라서 사람의 실수에 따른 리스크가 높습니다.

그렇기 때문에 정석적인 방법은 필요한 경우에만 활용했습니다. 하지만 정말 중요한 기능인 경우 최대한 꼼꼼하고 안전하게 테스트하기 위해서 활용하거나, 의사결정 테이블 원리를 이해하고 있기 때문에 테스트가 필요할 것 같은 최소한의 조건과 출력 값을 선택해서 진행했습니다.

테스트 기법 활용에 있어서 정답은 없습니다. 어떠한 요구사항이 주어졌을 때 주어진 상황과 리소스에서 '왜 기법 활용이 필요한지, 왜 필요하지 않는지에' 대한 논리적인 설명이 가능하고 지표로 나타난다면 기법 활용 유무는 크게 중요치 않습니다. 하지만 최소한 QA, Tester라면 어떠한 테스트 기법이 있고 그것이 어떠한 원리로 동작하는지 이해하고 있는 것과 그렇지 않은 것에는 큰 차이가 있다고 생각합니다.