테스트 기법은 소프트웨어를 분석하고 이를 바탕으로 테스트 케이스를 도출하는 방법입니다. 품질을 전문적으로 검증하는 부서에서만 사용하는 기법은 아닙니다. 예시로 구조기반 기법의 경우, 코드 기반 테스트로 화이트박스 테스트를 수행할 수 있는 인원이 활용하거나 개발자가 수행하는 개발 단계 테스트에서도 활용할 수 있습니다. 테스트 설계 기법은 ‘테스트 케이스를 도출'하여 '테스트 보장성을 확보'하는데 목적과 목표가 있습니다. 테스트 수행을 위해 어떤 종류의 테스트 기법으로 케이스를 도출할지 방법론을 제시합니다. 하지만, 실무에서는 기대하는 바와 다르게 기법에 따른 설계가 잘 작동되지 않습니다. 설계기법을 열심히 공부하고 실무에 돌아와서는 기존 방식대로 기능을 나열하는 수준으로 TC를 작성하고 사용합니다. 결제와 같은 복잡한 테스트 수행 조건과 기능들이 얽혀있는 컴포넌트와 같은 경우에는 결정 테이블이나 구조기반 기법을 사용해서 테스트 케이스를 도출하나 그 외 일반적인 기능 테스트는 대부분 설계기법이 잘 사용되지 않습니다. 이는 단순히 ‘테스트 케이스를 작성하는 방법'으로만 설계 기법을 접근하기 때문이라고 생각합니다. 테스트 기법을 실무에 잘 활용하려면 접근 방법을 달리 생각해야합니다. ‘테스트 케이스를 어떤 기법을 사용해서 작성' 할 것인가 하는 테스트 케이스 작성 방법론으로서 접근이 아니라, ‘전략적으로 테스트를 실행하기 위한 테스트 설계기법 활용'을 목적으로 접근해야 합니다. 즉, 테스트에 보장성을 확보하고자 테스트 케이스를 설계기법에 따라 다양하게 도출하는 것이 아닌 프로젝트 상황에 맞는 테스트 전략을 계획하고 계획된 목표와 목적 달성에 가장 적합한 테스트 기법을 선택하여 테스트 케이스를 설계 하는 것입니다. 예를들어 제품 출시를 위해 테스트를 계획할 때 QA는 테스트 일정(시간적 제약), 투입 인원 (보유지식/역량수준), 시스템 복잡도, 리스크 수준, 요구사항 기준 등을 고려하여 테스트를 설계합니다. 주어진 테스트 일정과 투입된 리소스가 매우 부족한 상황이라고 가정할 때, 투입된 인원을 적절히 분산하여 테스트 대상을 가능한 범위에서 빠짐없이 테스트할 것인지 또는 주요 기능에 선택&집중하여 테스트할 것인지 등 주어진 조건안에 최대한 품질을 확보할 수 있는 전략을 세우고 전략에 따라 테스트케이스를 설계할 것 입니다. QA가 최종 선택한 전략이 ‘주요 기능에 대한 선택과 집중'이라면 테스트 설계 기법 중 동등분할 기법을(입출력값 영역을 수학적 등가집합으로 만든뒤 대표값 하나를 선택해서 테스트케이스를 만드는 기법) 사용하거나 조합테스트 중 Each choice testing기법을(입력 값을 최소 한번 이상 테스트하는 기법) 사용하여 테스트케이스를 설계하는 것입니다. ❖ 전략적으로 테스트를 실행하기 위한 테스트 설계 기법 활용 Ⅰ - 명세기반 기법 계획된 전략에 맞게 테스트 설계기법을 활용하여 테스트케이스를 작성하는 방법을 구체적으로 살펴보겠습니다. 본 장의 구성은 일반적으로 알고 있는 테스트 설계 기법 종류 중 '명세기반 기법'에 해당하는 기법의 개요과 해당 설계기법을 전략적으로 활용할 수 있는 예시로 작성하였습니다. {{각 기법에 대한 충분한 이해를 위해 기법별로 TestCase를 작성하는 방법도 예시로 넣고싶었으나, 표와 같은 에디터 기능이 제공되지 않아서 작성 하지 못했습니다. 검색을 통해 쉽게 각 기법별 TC 작성 방법에 대한 예시를 찾아볼 수 있으니 테스트 설계기법을 공부해보고자 하시는 분들은 꼭 TC도 함께 작성해보시기 추천드립니다.}} 1. 등가(동등)분할 시스템 입력의 결과로 나타나는 결과값이 동일한 경우 하나의 그룹으로 간주합니다. 한 그룹 내 입력값은 어떠한 값을 선택해도 항상 같은 결과를 기대할 수 있다는 것을 전제로 합니다. 등가 분할은 이 원리를 이용해서 입/출력값 영역을 수학적 등가 집합으로 만든 뒤 대표값 하나를 선택하여 테스트 케이스를 만드는 기법입니다. 예를들어 A클래스에 해당되는 입력값이 1~100이고, 결과값이 N으로 동일할 경우 1~100까지 모든 값으로 테스트 케이스를 만들지 않고 1~100 중 하나의 대표값만 선택하여 테스트 케이스를 만드는 것입니다. 클래스가 A~Z로 수가 많을 경우 입력 대표값 하나씩과 각 클래스별 출력값을 확인했다는 것이 보장되어 테스트 커버리지를 달성하게 됩니다. 테스트 담당자에 따라 하나의 대표값만 확인하기 불안해서 같은 클래스 내에 2~3개 정도 케이스를 추가 할 수 있지만 결과적으로 등가 분할의 보장성은 대표값 하나로 테스트 하는 것과 결과가 동일합니다. 이런 특징으로 인해 등가 분할은 모든 경우의 수에서 테스트 케이스 갯수를 줄여줄 수 있습니다. 하지만 항상 같은 결과를 기대하는 것을 “가정"하여 테스트가 실행되고 테스트 강도가 약해서 실무에서는 특수한 상황(ex_입/출력값이 방대하나 테스트 일정/투입인력이 부족할 경우 샘플링테스팅 일환으로 등가 분할 기법을 사용하여 테스트를 진행)에서만 테스트 기법이 활용되고 있습니다. 등가 분할의 또 다른 특징으로는 명세 기반 기법으로 분류되어있지만 구조기반기법/경험기반 기법에서 입/출력값이 있는 경우 모든 상황에서 기법을 활용할 수 있습니다. 또한 단위/통합/시스템/인수 테스트 등 모든 테스트 레벨에서와 기능/비기능/리그레션 등 모든 테스트 타입에서도 활용이 가능합니다. ✻ 전략을 반영한 등가 분할 기법 활용 예시 • 테스트 일정 + 투입인력이 충분할 경우, “강한 등가 분할 테스팅"으로 등가 집합 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 테스트 할 수 있도록 설계한다. • 테스트 일정 + 투입인력이 부족할 경우, “약한 등가 분할 테스팅"으로 등가 집합에서 하나의 대표값만 선택해서 테스트 케이스를 설계한다. • 데이터 테이블 검증 시 테스트할 데이터의 양이 몇 만건에 해당된다. 이 경우, 모든 등가집합의 조합에 대한 테스트를 수행하는 것은 비효율적이다. 약한 등가 분할 테스팅을 선택하여 등가 집합에서 하나의 대표값에 대한 테스트를 수행하도록 설계한다. 2. 경계값 분석 등가 분할 후 각 범위의 경계에 해당되는 입력값에서 결함이 발생되는 경우가 많다는 경험에 기반하여 결함 검출 가능성을 높일 수 있도록 경계값을 포함하여 테스트 케이스를 설계하는 기법입니다. 경계값은 임의의 데이터를 사용하지 않고 class 경계에 있는 실 데이터를 이용합니다. 예를들어 A클래스에 해당되는 입력값이 ‘1 <= X < 100’ 일 경우 경계부분에 해당되는 최소값과 최대값, 즉 0, 1과 99, 100 이 경계값에 해당됩니다. 보통 경계값 분석은 하나의 기법이 단독으로 사용되지 않고 등가 분할 기법과 함께 테스트 범위 확장 형태로 함께 사용됩니다. 이렇다 보니 등가 분할과 마찬가지로 모든 테스트 레벨, 테스트 타입에 적용할 수 있고 테스트 커버리지를 보장할 수 있습니다. ✻ 전략을 반영한 경계값 분석 기법 활용 예시 • 등가 집합에서 하나의 대표값만 선택해서 테스트하기에 테스트 강도가 약하다 판단될 경우 등가 분할 기법 + 경계값 분석 기법을 함께 활용하여 테스트 강도 및 커버리지를 확보하고 품질을 보장하는 형태로 활용한다. • 시간/초기화 조건이 있는 이벤트 또는 컨텐츠(ex_00시 컨텐츠 초기화, 출석보상 등) 검증 시, 경계값에서 이슈가 발생되는 경험이 많다. 테스트 범위에 이런 조건이 포함되어있는 경우, 경계값 분석 기법을 적극적으로 활용한다. 3. 결정테이블 테스팅 결정 테이블 테스팅은 발생 조건에 따른 결과를 테이블 형태로 나열한 것으로 시스템의 동작을 유발시키는 조건(conditions)과 처리(actions)의 모든 가능한 조합을 고려하고 조합에 대한 예상 결과를 포함하여 테스트 케이스를 설계하는 기법입니다. 결정 테이블 테스팅은 요구사항을 도출하거나 내부 시스템 설계를 문서화 하는데 유용하며 명세서 또는 시스템 설계 자체를 테스트 하는데 주로 적용됩니다. 명세서의 품질이 낮다면 모든 조건과 정확한 처리를 찾기 어려울 수 있고 시스템 설계 자체에 결함이 있을수 있어 테스트 전문가의 시각에서 결정 테이블 기법을 적용한 테스트 케이스를 설계하는 것만으로도 개발 초기 명세서와 내부 시스템에서 오류를 발견할 수 있습니다. 한가지 유의할 점은, 결정 테이블 테스팅을 전체 시스템에 적용할 경우 너무 많은 경우의 수가 도출될 수 있어서 가급적 해당 기법은 중요한 코어 시스템에서만 사용하는 것을 권장해드립니다. ✻ 전략을 반영한 결정 테이블 테스팅 기법 활용 예시 • 결정 테이블 기법을 활용하여 테스트를 수행하기 전 명세서와 시스템 설계 단계에서 결함을 발견하여 개발 초기 단계부터 품질을 향상할 수 있다 • 일정 이슈 등으로 유효 케이스에 대한 테스트만 진행이 가능한 상황일 경우 모든 가능한 동작을 유발하는 조건의 조합을 커버할 수 있어서 결정 테이블 테스팅 기법이 유용하다 4. 상태전이 테스팅 명세를 구성하는 모델이 ‘상태 다이어그램'이라면, 소프트웨어가 상태 다이어그램에 맞게 구현되어있는지 확인하기위해 상태 전이 테스팅 기법을 사용하여 모든 입출력 상태의 입력 조합과 상태간에 전이되는 것, 상태를 변화 시키는 이벤트와 상태의 변화로 유발되는 동작까지 보장하는 테스트 케이스를 생성할 수 있습니다. ✻ 상태 전이 테스팅 기법으로 테스트케이스를 설계하는 방법 [1] 상태 전이 기법으로 테스트 케이스 도출 - 전형적인 상태의 순서를 커버하는 방식 - 특정한 상태 전이 순서를 실행하는 방식 - 모든 상태를 커버하는 방식(유효케이스) - 불가능한 상태 전이를 테스트 하는 방식 (비유효 케이스) - 모든 상태 전이를 커버하는 방식 테스트 전략에 따라 하나만 선택 또는 복수 선택으로 설계 할 수 있습니다. [2] 도출된 테스트 케이스로 연속된 테스트 시나리오 작성 상태 전이 테스팅 기법으로 테스트 케이스를 설계할 때 유의해야 할 사항은 테스트 효율성을 높이고 더 깊이 있는 테스트 결과를 얻기 위해 테스트 실행 순서를 연속된 상태 전이를 이어서 테스트 할 수 있도록 테스트 시나리오를 작성해야 합니다. 상태 전이 테스팅 기법을 사용해서 테스트 케이스를 도출하고 도출한 순서대로 순차적으로 테스트를 수행하는 것이 아니라 테스트 수행 절차가 연속된 시나리오를 가지고 테스트가 실행될 수 있도록 작성되어야 하는 것입니다. 예를 들어, 상태전이 기법으로 도출된 테스트 케이스가 아래와 같다면, TC 1) 1 → 2 → 4 TC 2) 1 → 3 → 5 TC 3) 4 → 6 연속된 상태 전이를 이어서 테스트 수행할 수 있도록 테스트 시나리오를 작성해야합니다. TC 1) 1 → 2 → 3 → 4 TC 2) 3 → 4 → 5 → 6 ✻ 전략을 반영한 상태 전이 기법 활용 예시 • 테스트 일정 + 투입인력이 충분할 경우, 모든 상태 전이를 커버할 수 있도록 설계한다. • 개발자 테스트 또는 스모크 테스트 또는 리그레션 테스트로 사용하는 경우, 전형적인 상태 전이를 커버할 수 있도록 설계한다. • 일정/투입인력 부족으로 적은 케이스로 많은 결함을 찾도록 전략이 계획된 경우, 유효+비유효 상태를 커버할 수 있도록 설계한다. • 기획/개발 담당자의 보유 지식/경험이 부족한 경우, 특정한 상태 전이를 추가로 설계하여 예외처리에 대응할 수 있도록 테스트 케이스를 설계한다. 5. 유즈케이스 테스팅 유즈 케이스 또는 시나리오 테스팅은 유저와 시스템 사이 상호작용을 사용자의 시각에서 표현한 시나리오이며, 비즈니스 시나리오 또는 프로세스 흐름을 기반으로 테스트 케이스를 설계하는 기법입니다. 유즈 케이스는 시스템을 실제로 사용하는 행위의 절차로 기술되기 때문에 흐름상 예상하지 못했던 정보나 존재할 수 있는 결함을 발견할 수 있고 인수테스트나 통합 테스트 단계에서 각각의 컴포넌트 사이의 상호작용으로 발생되는 결함을 발견하는데 유용합니다. 유즈 케이스 테스팅 기법이 “사용자 시각에서 표현"되는 시나리오다 보니 작성자의 경험치/역량수준/보유지식에 따라 시나리오 품질과 해석의 차이가 발생될 수 있고 표준으로 사용할 수 있는 테스트 케이스도 존재하지 않아서 해당 기법 사용시 일정 수준의 품질 결과를 얻을 수 있도록 작성에 각별히 유의해야 합니다. 시나리오 품질과 해석의 차이를 줄이기 위한 방법으로 다른 테스트 기법을 활용하여 시나리오를 작성하는 것도 좋은 방법이 될 수 있습니다. 예를들어 시스템 레벨 시나리오 테스팅은 ‘상태 전이 테스팅 기법'을 활용하여 수행순서(흐름)을 전이로 간주하여 시나리오를 작성하거나, 단위 레벨 시나리오 테스팅은 결정테이블/등가분할&경계값 분석/구조기반기법 등을 활용할 수 있습니다. ✻ 전략을 반영한 유즈 케이스 테스팅 기법 활용 예시 • 상태는 다르나 수행 순서(흐름)에 반복이 많은 경우 상태 전이 기법의 테스트 케이스 도출 전략을 활용하여 흐름의 반복 횟수를 줄여 제한적으로 커버리지를 달성 할 수 있도록 테스트 케이스를 설계한다. a) 테스트 일정 + 투입인력이 충분할 경우, 전형적인 상태 순서 + 모든 상태 전이를 커버할 수 있도록 설계 b) 일정/투입인력 부족으로 적은 케이스로 많은 결함을 찾도록 전략이 계획된 경우, 유효케이스의 상태 전이를 커버할 수 있도록 설계 • 입력값의 조합 수가 많은 경우 등가 분할+경계값 분석 기법 활용 또는 조합 테스팅 기법을 활용하여 테스트 케이스를 설계한다. 6. 조합 테스팅 조합 테스팅은 입력값을 조합해서 최대 커버리지를 가지는 최소 개수의 테스트 케이스를 설계하는 기법입니다. 잠재적 조합 요소의 거대한 양을 처리하기 위해 테스트 케이스를 선정하는데 도움을 주는 통계적 테스트 기법으로 테스트 할 입력값의 양에 따라 All Combinations Testing, Pairwise Testing, Each Choice Testing으로 분류되며 이 중 대표적인 조합 테스팅인 페어와이즈 기법은 대부분 결함이 2개 요소의 상호작용에서 발생된다는 경험에 기반하여 테스트 하는데 필요한 각 값들이 최소한 한번씩은 조합을 이루도록 설계하는 기법입니다. 조합 테스팅은 의도적으로 테스트 케이스 수를 줄여서 테스트 하는 기법인 만큼 리스크 수준이 높지만 입력값의 누락없이 잘 조합된 최소 개수의 테스트 케이스로도 일정 수준의 품질은 보장될 수 있습니다. 그래도 가급적 pairwise 기법과 each choice 기법은 일정 및 투입 리소스가 부족한 상황 등 제한적인 테스트 환경에서만 사용할 것을 권장합니다. ✻ 조합 테스팅 기법 종류 All Combinations Testing : 입력값의 모든 조합을 모두 테스트 Pairwise Testing : 입력 값의 모든 쌍의 조합이 TC내에 최소 한번 이상 들어가도록 설계 Each Choice Testing : 입력 값을 최소 한번 이상 테스트 ✻ 전략을 반영한 조합 테스팅 기법 활용 예시 • 테스트 일정 + 투입인력이 부족할 경우, Pairwise 또는 Each Choice 기법으로 테스트 케이스를 설계한다. • 테스트 투입 인력에 테스트 전문가 또는 테스트 리더가 포함된 경우, 주어진 입력값 외 경험에 기반하여 의미있고 결함이 발견될 가능성이 높다고 판단되는 입력값(유효/비유효 포함)도 포함하여 테스트 케이스를 설계한다. -- 테스트 설계 기법을 전략적으로 테스트를 실행하기 위한 활용방법의 목적으로 접근해본 이유는, 이렇게 좋은 설계 기법들이 실무에 잘 사용되지 않는것이 늘 아쉬웠기 때문입니다. 무엇이 문제여서 쉽게 접근하기도, 사용하기도 어려운 것인지..오랜 시간 고민했던 것 같습니다. 그에 대한 개인적인 해답을 얻은 것이 우리가 너무 방법론적으로만 설계기법을 인식하고 있기때문이 아닌가라는 결론에 이르게 된것이었고, 테스트 전략에 맞춰 테스트를 효율적으로 수행하는 것과 유용한 품질의 제품을 얻기위한 방법으로 설계 기법을 활용했을때 만족스러운 결과를 얻을 수 있었습니다. 별것 아닐수 있지만 경험을 통해 얻은 바를 공유하고자 한 것은, 그 내용이 너무 자그마하지만(너무 작아서 귀여울 지경인..) 지금도 현장에서 저와 같은 고민을 하고 있을 동료나 후배QA들에게 이 글을 읽기 이전보다 업무를 좀 더 효율적으로 수행할 수 있게되고, 효과적인 결과를 얻을 수 있는데 도움이 될 수있지 않을까하는 바램으로 글을 공유해봅니다.