19화 테스트 설계 기법 상태 전이 테스팅
소프트웨어 테스팅
이번 장에서는 상태 전이 테스팅 사례를 통해 원리를 알아보도록 하겠습니다. 상태 전에 테스팅 기법을 활용하면 실무에서 받는 요구사항 중 복잡한 비즈니스 로직의 테스트 케이스를 쉽게 도출할 뿐 아니라 공식적인 설계 기법을 적용했기 때문에 높은 테스트 케이스 커버리지 신뢰성을 보장하면서도 테스트 케이스를 효과적으로 줄일 수 있습니다.
상태 전이 테스팅은 테스트 대상이 유효 전이를 통해 정의된 상태에서 들어오고 나가는 것은 물론 유효하지 않은 상태로 들어가려 하거나 유효하지 않은 전이를 수행하려는 능력을 테스트하는 데 사용되는 것을 의미합니다.
신용카드 등록 테스트
- 카드번호 8자리 입력 후 유효한 카드이면 등록 후 마이페이지 이동
- 1회 입력 실패 시 ‘카드번호가 올바르지 않습니다. 다시 입력해주세요’ 팝업 노출
- 2회 입력 실패 시 ‘마지막 시도입니다. 다시 입력해주세요' 팝업 노출
- 3회 입력 실패 시 ‘24시간 동안 해당 기능 사용 불가' 팝업 노출
위와 같은 요구사항이 있습니다. 어떻게 테스트 디자인하면 높은 테스트 커버리지를 달성할 수 있을까요? 상태 전이 테스팅 기법을 활용해보겠습니다.
피그마로 스케치한 상태 전이 테스팅의 핵심 개념입니다. 상태란, 특정한 행동을 했을 때 나타나는 출력 값이라고 이해하면 좋습니다. 전환이란, 각각의 상태로 이동하기 위한 행동이라고 이해하시면 좋습니다. 신용카드 등록 기능에는 몇 가지 상태가 있을까요? 5가지 상태가 있습니다. 검은색 동그란 원이 상태를 뜻합니다. 그렇다면 각 상태별로 얼마나 많은 전환이 있을까요? 6번의 전환이 있습니다.
올바른 카드번호는 12345678입니다. 첫 번째 상태에서 2가지 전환이 발생할 수 있습니다. 카드 번호가 올바를 때와 그렇지 않을 때이죠. 첫 번째 상태에서 12345678을 입력했다면 올바른 값의 전환이 발생합니다. 따라서 E 상태인 마이페이지로 이동하겠죠? 만약 올바르지 않은 전환이 나타나면 '카드번호가 올바르지 않습니다' 팝업이 노출될 겁니다. B상태에서도 2가지 상태로 갈 수 있는 2개의 전환이 있습니다. 카드 번호를 올바르게 입력해볼까요? 올바른 전환이 발생하고 E 마이페이지로 이동하네요. 만약 틀린 값을 입력했다면 '마지막 시도입니다. 다시 입력해주세요' 팝업이 노출됩니다. 마찬가지로 2가지 전환이 있네요. 올바른 값을 입력하면 C에서 E 상태가 됩니다. 만약 C 상태에서 값 입력이 틀릴 경우 '24시간 동안 해당 기능 사용 불가' 팝업이 노출됩니다.
여기서 Dead States(죽은 상태) 개념이 등장합니다. 아래 테스트 케이스를 보면서 죽은 상태 개념을 한번 살펴보겠습니다.
1. ABCD(기능 사용 불가)
2. AE(등록 성공)
초기 상태에서 기능 사용 불가한 케이스와 초기 상태에서 바로 올바른 상태로 이동하는 2가지 케이스를 작성했습니다. 그런데 무언가 부족해 보이지 않나요? 앞서 상태 전이 다이어그램을 통해 도출된 상태는 5개이고 총 6번의 전환이 일어나는 기능입니다. 그런데 위처럼 2가지만 검증할 경우 누락된 케이스가 존재합니다. 바로 죽은 상태에 대한 테스트이죠.
죽은 상태는 어떠한 상태에 도달하는 순간 이전 상태로 되돌아갈 수 없는 상태를 뜻합니다. 마이페이지 이동(E)과 기능 사용 불가(D)가 죽은 상태가 되겠죠. 카드 번호 입력(A) 시작 상태에서 E와 D에 도달하는 순간 이전 상태로 되돌아갈 수 없게 됩니다.
죽은 상태 개념을 포함한 각 상태에 따른 전환을 검증하는 방법이 바로 상태 전이 테스팅입니다.
신용카드 등록 테스트
- 카드번호 8자리 입력 후 유효한 카드이면 등록 후 마이페이지 이동
- 1회 입력 실패 시 ‘카드번호가 올바르지 않습니다. 다시 입력해주세요’ 팝업 노출
- 2회 입력 실패 시 ‘마지막 시도입니다. 다시 입력해주세요' 팝업 노출
- 3회 입력 실패 시 ‘24시간 동안 해당 기능 사용 불가' 팝업 노출
TC1. AE(Pass-4)
TC2. ABE(Pass-5)
TC3. ABCE(Pass-6)
TC4. ABCD(Fail-3)
위 기능은 상태 전이 테스팅 기법을 활용해서 총 4개의 테스트 케이스만 디자인하면 테스트 커버리지를 높일 수 있습니다.
간단한 예시를 설명했기 때문에 무작정 테스트하는 것과 별 차이를 못 느끼실 수 있는데요. 그렇지 않습니다. 실무에서 받는 요구사항은 복잡합니다. 비즈니스 로직 흐름이 긴 경우를 떠올려보시면 좋습니다.
흐름 간에 각각의 상태가 있을 것이고 전환에 따라 테스트 결괏값이 달라질 것입니다. 그러한 테스트를 감에 의존한다거나 무작위로 해본다거나 하면 테스트 실행 속도는 빠를 수 있습니다. 그런데 무엇을 테스트했고 꼼꼼한 테스트가 진행되었다는 것을 어떻게 증명할 수 있을까요? 또는 무작정 TC를 디자인했다고 가정합니다. 어떤 테스트가 더 진행되어야 할지 어떻게 파악할 수 있을까요?
테스트란 결함을 찾는 행위임과 동시에 운영 환경에서의 버그를 예방하는 활동이라 생각합니다. QA, Tester에게 2번의 기회란 없습니다.(실제로는 있어야겠죠..? 사명감을 갖자는 의미입니다.) 운영 환경에서 버그가 발생하면 남은 건 빠른 대응뿐입니다. 물론 버그 발생을 100% 막을 순 없겠지만 사전에 최소화하고 예방하겠다는 일종의 직업적 사명감이 필요합니다.
테스트 설계 기법을 활용하지 않으면 TC 커버리지 예측이 어려워집니다. 경우에 따라서 상태 전이 기법을 활용하지 않으면 테스트 케이스 도출에만 상당히 애를 먹습니다. 비즈니스 로직 흐름이 굉장히 길고 복잡하기 때문에 무엇을 테스트할 것이며, 테스트 범위, 고려 대상이 쉽게 떠오르지 않기 때문이죠.
그렇기 때문에 소프트웨어 품질을 업으로 삼고 있다면 최소한 그 업을 이루고 있는 근본 지식들을 탐구할 필요성이 있습니다. 블랙박스 테스트 명세 기반 설계 기법만 잘 이해하고 실무에 적용해도 많은 테스트 커버리지를 효과적으로 줄일 수 있습니다. 이는 리그레션 수행 비용과도 직결되며 테스트 프로세스 전체 비용을 절감시킬 수 있습니다.
이상으로 상태 전이 테스팅 기법 설명을 마치겠습니다.
