Stories by Jung Han on Medium

한정

원문: https://testsigma.com/blog/decision-table-testing/
소프트웨어 테스팅 업계에서는 “완벽한 테스팅은 신화이며 실현 불가능하다”라는 말이 있습니다. 이를 뒷받침하듯 각각의 장단점을 가진 다양한 유형의 소프트웨어 테스팅 기법이 있습니다. 우리는 프로젝트와 요구사항에 기반하여 테스트 케이스를 영리하게 선택하고 모든 테스트 시나리오가 포함되도록 보장할 수 있는 더 나은 테스팅 기법이 필요합니다.
ISTQB에 따르면, 크게 두 가지 주요 소프트웨어 테스팅 기법 카테고리가 있습니다.
정적 테스팅 기법: 소프트웨어 제품의 실행 없이 명세나 구현 단계에서 컴포넌트나 시스템을 테스팅하는 것을 의미합니다. 예를 들어 다양한 유형의 리뷰, 계획, 킥오프 미팅, 작업 준비 등이 있습니다.
동적 테스팅 기법: 소프트웨어 제품이나 시스템의 실행을 포함하는 테스팅을 의미합니다.
동적 테스팅 기법은 다시 세 가지 카테고리로 세분화됩니다.
명세 기반 기법 / 블랙박스 테스팅 기법 / 동작 테스팅 기법
구조 기반 기법 / 화이트박스 테스팅 기법 / 구조적 테스팅 기법
경험 기반 테스팅 기법
명세 기반 테스팅 기법은 내부 구조를 참조하지 않고 컴포넌트나 시스템의 기능적 또는 비기능적 명세 분석을 기반으로 테스트 케이스를 도출 및/또는 선택하는 절차입니다. 간단히 말해, 테스터는 소프트웨어가 작업을 어떻게 수행하는지가 아닌 무엇을 하는지에 더 집중합니다.
명세 기반 설계 기법에는 네 가지 설계 방법이 있습니다.
동등 분할
경곗값 분석
의사결정 테이블
상태 전이 테스팅
동등 분할과 경곗값 분석 기법은 주로 사용자 인터페이스에 더 초점을 맞추지만, 결정 테이블과 상태 전이 테스팅은 비즈니스 로직이나 비즈니스 규칙에 더 초점을 맞춥니다.
의사결정 테이블 테스팅이란?
“의사결정 테이블 테스팅”은 의사결정 테이블에 나타난 입력값들의 조합을 테스트하기 위한 블랙박스 테스트 설계 기법입니다. 이는 다양한 입력값 조합을 효과적으로 다룰 수 있는 좋은 방법입니다.
의사결정 테이블은 무엇인가요?
위키에 따르면, “의사결정 테이블”은 주어진 조건이나 입력에 따라 수행할 작업을 지정하기 위한 간결한 시각적 표현을 의미합니다. 즉, 출력이 일련의 작업인 알고리즘입니다. 이러한 작업들은 추가로 테스트 케이스를 설계하는 데 사용될 수 있습니다.
이 테이블은 “원인-결과” 테이블이라고도 불립니다. 이는 의사결정 테이블을 도출하는 데 사용되는 “원인-결과 그래프”라는 로직 다이어그램 기법과 관련이 있기 때문입니다.
의사결정 테이블 테스팅 기법을 테스트 자동화에 사용할 수 있을까요?
살펴본 것처럼, 의사결정 테이블 테스팅은 시스템이나 컴포넌트의 입력과 출력 조합을 기반으로 테스트 케이스를 설계하는 기법입니다. 이는 모든 가능한 시나리오를 커버하고 중복과 복잡성을 줄이는 데 도움을 줍니다. 그러나 의사결정 테이블 테스트를 수동으로 생성하고 실행하는 것은 시간이 많이 소요되고 오류가 발생하기 쉽습니다. 따라서, 의사결정 테이블 테스팅을 자동화하면 다음과 같은 여러 이점을 얻을 수 있습니다.
시간과 노력 절약
테스트 커버리지 향상으로 품질 개선
유지보수성과 확장성 향상, 의사소통과 협업 촉진
테스트 케이스 자동 생성 및 실행으로 인적 오류 제거
테스트 케이스 업데이트가 쉽고 다양한 시나리오에 재사용하여 프로세스 효율성 향상
이러한 이유로 도구나 기법을 사용하여 의사결정 테이블 테스팅을 자동화한다면 큰 장점을 누릴 수 있습니다. 의사결정 테이블을 통해 도출한 테스트를 자동화하는 데 도움이 되는 다양한 도구들이 있으며, 이는 필요와 선호도에 따라 선택할 수 있습니다.
예를 들어, Testsigma라는 통합 클라우드 기반 테스트 자동화 도구를 사용하여 의사결정 테이블의 입력과 예상 결과를 자동화할 수 있습니다. 이 도구는 간단한 영어로 테스트 케이스를 자동화할 수 있게 해 주며 코딩이 필요하지 않습니다.
의사결정 테이블 사용 방법
의사결정 테이블을 사용하는 첫 번째 작업은 입력이나 이벤트의 조합에 따라 반응하는 동작을 가진 적절한 기능이나 하위 시스템을 식별하는 것입니다.
예를 들어, 앱의 로그인 화면을 보면 사용자 이름, 비밀번호, 2단계 인증 등 다양한 입력이 있습니다. 또한, 잘못된 비밀번호로는 로그인을 허용하지 않고 인증된 사용자 이름과 올바른 비밀번호로만 애플리케이션에 로그인할 수 있는 등의 다양한 동작/출력이 있습니다.
추가로 입력이 너무 많지 않도록 해야 합니다. 그렇지 않으면 조합의 수가 번거롭고 관리하기 어려워집니다.
이처럼 많은 수의 조건을 다뤄야 하는 경우, 이를 하위 집합으로 나누어 한 번에 하나씩 처리하는 것이 좋습니다.
결합해야 할 측면들을 식별했다면, 각 측면에 대한 모든 참과 거짓의 조합을 나열하여 테이블로 만듭니다.
이제 두 가지 예시에서 다양한 소프트웨어 프로젝트에서 의사결정 테이블 테스팅을 적용하는 방법에 대해 배워보겠습니다.
예시 1: 로그인 화면에 대한 의사결정 테이블 만들기
명세: Testsigma 애플리케이션의 로그인 화면을 예로 들어보겠습니다. 조건에 따르면 사용자가 올바른 사용자 이름과 비밀번호를 제공하면 홈페이지로 리다이렉트됩니다. 입력 중 하나라도 잘못되면 화면에 오류 메시지가 표시됩니다.
로그인 화면을 위한 의사결정 테이블
위 예시에서, T는 올바른 이메일 ID/비밀번호를 의미합니다. F는 잘못된 이메일 ID/비밀번호를 의미합니다. H는 사용자에게 표시될 홈 화면을 의미합니다. E는 사용자에게 표시될 오류 메시지를 의미합니다. TC는 테스트 케이스를 의미합니다.
이제 제공된 입력(이메일 ID와 비밀번호)에 따른 위 의사결정 테이블의 동작이나 출력에 관해 이야기해 보겠습니다.
테스트 케이스 1 — 이메일 ID와 비밀번호가 모두 올바릅니다. 따라서 사용자는 Testsigma의 홈페이지로 이동해야 합니다.
테스트 케이스 2 — 이메일 ID는 올바르지만, 비밀번호가 잘못되었습니다. 따라서 “잘못된 비밀번호”라는 오류 메시지가 사용자에게 표시되어야 합니다.
테스트 케이스 3 — 이메일 ID는 잘못되었지만, 비밀번호는 올바릅니다. 따라서 “잘못된 이메일 ID”라는 오류 메시지가 사용자에게 표시되어야 합니다.
테스트 케이스 4 — 이메일 ID와 비밀번호가 모두 잘못되었습니다. 따라서 “잘못된 이메일 ID”라는 오류 메시지가 사용자에게 표시되어야 합니다.
위 예시에서 모든 가능한 조건이나 테스트 케이스가 포함된 것을 보았듯이, 테스팅 팀은 이 의사결정 테이블을 참조하여 테스트 케이스를 생성함으로써 테스팅 단계에서 향후 발생할 수 있는 버그를 찾을 수 있습니다.
업로드 화면의 경우 의사결정 테이블을 어떻게 사용할 수 있는지 또 다른 예시를 살펴보겠습니다.
예시 2: 업로드 화면에 대한 의사결정 테이블 만드는 방법
이제 다른 예시를 살펴보겠습니다. 업로드 화면에 대한 의사결정 테이블과 테스트 시나리오를 고려해 보겠습니다. 사용자에게 파일 업로드를 요청하는 대화상자가 있습니다.
명세: 파일은 .png 형식이어야 합니다. 파일 크기는 25kb 미만이어야 합니다. 파일 해상도는 132*170px이어야 합니다.
이제 위의 명세를 염두에 두고 업로드 화면에 대한 의사결정 테이블을 만들어보겠습니다.
업로드 화면에 대한 의사결정 테이블
위 의사결정 테이블 데이터를 기반으로, 주어진 명세에 대한 포괄적인 커버리지를 보장하기 위해 8개의 개별 테스트 케이스를 개발할 수 있습니다.
테스트 케이스 1: .png 형식, 25kb 미만의 크기, 132*170 픽셀 해상도를 가진 파일을 추가하기 위해 업로드를 클릭합니다. 예상 결과는 사진이 성공적으로 업로드되는 것입니다.
테스트 케이스 2: .png 형식, 25kb 미만의 크기, 132*170 픽셀 초과 해상도를 가진 파일을 추가하기 위해 업로드를 클릭합니다. 예상 결과는 파일 해상도 불일치 문자열이 포함된 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
테스트 케이스 3: .png 형식, 25kb 초과의 크기, 132*170 픽셀 해상도를 가진 파일을 추가하기 위해 업로드를 클릭합니다. 예상 결과는 파일 크기 부정확 문자열이 포함된 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
테스트 케이스 4: .png 형식, 25kb 초과의 크기, 132*170 픽셀 미만의 해상도를 가진 파일을 추가하기 위해 업로드를 클릭합니다. 예상 결과는 파일 크기 부정확 문자열이 포함된 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
참고: 해상도가 132*170px이 아니더라도, 크기가 첫 번째 유효성 검사이고 이 경우 크기가 잘못되었으므로 크기 부정확 오류 메시지가 표시되어야 합니다.
테스트 케이스 5: .png가 아닌 형식, 25kb 미만의 크기, 132*170 픽셀 해상도를 가진 파일을 선택하고 업로드를 클릭합니다. 예상 결과는 형식 불일치를 언급하는 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
테스트 케이스 6: .png가 아닌 형식, 25kb 미만의 크기, 137*177 픽셀 초과 해상도를 가진 파일을 선택하고 업로드를 클릭합니다. 예상 결과는 형식 불일치를 언급하는 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
참고: 해상도가 132*170px이 아니더라도, 첫 번째 형식 유효성 검사를 기반으로 형식이 잘못되었으므로 형식 불일치 오류가 표시되어야 합니다.
테스트 케이스 7: .png가 아닌 형식, 25kb의 크기, 137*177 픽셀 해상도를 가진 파일을 추가하기 위해 업로드를 클릭합니다. 예상 결과는 형식 불일치를 언급하는 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
참고: 크기가 25kb 미만이 아니더라도, 첫 번째 형식 유효성 검사를 기반으로 형식이 잘못되었으므로 형식 불일치 오류가 표시되어야 합니다.
테스트 케이스 8: .png가 아닌 형식, 25kb 초과의 크기, 137*177 픽셀 미만의 해상도를 가진 파일을 선택하고 업로드를 클릭합니다. 예상 결과는 형식 불일치를 언급하는 오류 메시지가 표시되고 사용자가 파일을 업로드 할 수 없어야 합니다.
참고: 크기가 25kb 미만이 아니고 해상도가 132*170px이 아니더라도, 첫 번째 형식 유효성 검사를 기반으로 형식이 잘못되었으므로 형식 불일치 오류가 표시되어야 합니다.
위의 두 예시에서 다음과 같이 결론을 내릴 수 있습니다.
의사결정 테이블의 모든 가능한 조건 수를 찾기 위해, 2^n 공식을 사용할 수 있습니다. 여기서 n은 입력의 수를 나타냅니다. 예시 1에서는 입력이 2개(이메일 ID와 비밀번호)입니다.
가능한 테스트 조건 수 = 2^입력 조건 수 가능한 테스트 조건 수 = 2² = 4
따라서, 예시 1의 경우 4개의 테스트 케이스를 다뤘습니다.
마찬가지로 예시 2의 경우, 상위 수준에서 파일 형식, 크기, 파일 해상도와 같은 3가지 유형의 입력이 있습니다. 동일한 2^n 공식을 적용하면,
가능한 테스트 조건 수 = 2^입력 조건 수 가능한 테스트 조건 수 = 2³ = 8
따라서, 예시 2의 경우 8개의 테스트 케이스를 다뤘습니다.
의사결정 테이블 테스팅이 중요한 이유
의사결정 테이블 테스팅은 복잡한 비즈니스 규칙을 의사결정 테이블 형태로, 체계적으로 표현하는 방법을 제공하며, 이는 개발자와 테스터 모두에게 유용합니다.
의사결정 테이블 테스팅 기법은 테스트 조건이 명세에 사용되지 않더라도 테스트 설계에 사용될 수 있습니다. 이는 테스터가 비즈니스 규칙을 올바르게 구현해야 하는 다양한 입력과 기타 소프트웨어 상태의 조합 효과를 탐색하는 데 도움이 됩니다.
시스템 동작이 각 입력 세트마다 다른 대규모 입력 세트의 동작을 테스트할 때, 의사결정 테이블 테스팅은 좋은 커버리지를 제공하고 표현이 단순하여 해석하고 사용하기 쉽습니다.
동등 분할과 경곗값 분석 기법은 종종 특정 상황이나 입력에 적용됩니다. 하지만 서로 다른 입력 조합이 다른 동작을 수행하는 경우, 이를 동등 분할과 경곗값 분석을 사용하여 보여주기가 더 어려울 수 있습니다. 입력 조합의 경우 의사결정 테이블 테스팅 설계 기법이 더 선호됩니다.
예를 들어, 신용카드 이자율에 대한 의사결정 테이블을 들 수 있습니다. 동일한 신용카드의 경우, 신규 고객, 충성도 포인트, 쿠폰 등 다양한 입력에 따라 이자율이 달라집니다. 이러면 명세와 다양한 입력 조합을 기반으로 의사결정 테이블을 만드는 것이 매우 유용할 것입니다.
의사결정 테이블 테스팅의 장점
소프트웨어 테스팅에서 의사결정 테이블은 여러 장점이 있습니다.
효과적인 테스트 케이스를 체계적으로 선택하는 데 도움이 됩니다.
복잡한 비즈니스 흐름을 테스트 시나리오와 테스트 케이스로 쉽게 변환할 수 있습니다.
명세의 문제점과 모호성을 찾는 유익한 부수 효과를 가져올 수 있습니다.
모든 테스트 케이스에 대한 포괄적인 커버리지를 제공하여 테스트 케이스와 테스트 시나리오 작성에 대한 재작업을 크게 줄일 수 있습니다.
한 번 의사결정 테이블을 만들면 테스트 케이스 커버리지의 정확도가 높아집니다.
시스템 동작이 입력에 따라 달라지고 입력 범위에 걸쳐 일관되지 않을 때, 동등 분할이나 경곗값 분석은 도움이 되지 않지만, 의사결정 테이블은 이러한 경우에 테스트 케이스를 쉽게 설계하는 데 도움이 됩니다.
의사결정 테이블은 이해하기 쉽고, 누구나 이 설계와 테스팅 방법, 시나리오, 테스트 케이스를 사전 경험 없이도 사용하고 구현할 수 있습니다.
의사결정 테이블 테스팅의 단점
예시에서 봤듯이 의사결정 테이블에서 테스트 케이스를 만드는 공식은 2^n이므로, 입력 수가 증가하면 의사결정 테이블이 더 복잡해집니다. 주요 단점 중 하나입니다.
복잡한 의사결정 테이블을 다루기 위해 숙련되고 전문적인 테스터가 필요합니다. 복잡한 의사결정 테이블에는 많은 입력이 있기 때문에 초보자의 경우 이러한 복잡한 의사결정 테이블을 다루고 테스트 케이스를 추출하기 어려울 수 있습니다.
소프트웨어에 변경 사항이 있을 때마다 의사결정 테이블에도 반영해야 하므로 시기적절하게 의사결정 테이블을 유지해야 합니다. 따라서 자주 유지보수하고 업데이트해야 하며, 이는 팀의 비용과 노력이 더 많이 들게 됩니다.
테스팅이 효율적이고 유익하지만, 테이블을 만들고 그 후에 테스트 케이스를 추출하는 데 시간이 다소 걸릴 수 있습니다. 시간이 더 많이 필요할수록 테스팅 비용도 더 많이 듭니다.
요약
의사결정 테이블 테스팅은 소프트웨어 애플리케이션의 정확성과 신뢰성을 보장하는 데 도움이 되는 강력하고 효과적인 블랙박스 테스팅 기법입니다. 의사결정 테이블 테스팅을 사용함으로써 소프트웨어 애플리케이션의 품질을 향상하고 더 나은 사용자 경험을 제공할 수 있습니다.
이제 의사결정 테이블 테스팅 기법을 이해했으므로, 의사결정 테이블을 사용하여 비즈니스 규칙이 무엇이고 그에 따라 무엇을 테스트해야 하는지 탐색할 수 있습니다. 잘 만들어진 의사결정 테이블은 모든 조건을 포함해야 하므로 입력 데이터에 따른 시스템의 올바른 응답을 분류하는 데 도움이 될 수 있습니다. 이는 로직 설계를 단순화하여 제품의 개발과 테스팅을 개선합니다.
블랙박스 테스팅에서 의사결정 테이블은 어떻게 사용될까요? 아래 사용 방식을 정리해 봤습니다.
입력 조건과 가능한 값을 식별합니다.
결과나 예상 결과를 정의합니다.
표 형태로 해당하는 의사결정 테이블을 생성합니다.
이 의사결정 테이블을 사용하여 체계적으로 테스트 케이스를 설계합니다.
의사결정 테이블에서 도출된 테스트 케이스를 실행하기 시작합니다.
발견된 문제를 해결을 위해 개발 팀에 보고합니다.
의사결정 테이블 테스팅의 공식은 무엇인가요? 의사결정 테이블의 공식은 2^n이며, 여기서 n은 입력의 수를 나타냅니다. 가능한 테스트 조건 수는 2^입력 조건 수입니다. 의사결정 테이블의 종류는 몇 가지가 있나요? 소프트웨어 테스팅에는 상위 수준에서 두 가지 유형의 의사결정 테이블이 있습니다.
확장 항목 테이블: 확장 항목 의사결정 테이블에서는 조건 항목이 두 개 이상의 값을 가집니다. ‘참’과 ‘거짓’뿐만 아니라 여러 가능성이 있는 다중 조건을 사용하는 의사결정 테이블을 확장 항목 의사결정 테이블이라고 합니다.
제한 항목 테이블: 제한 항목 의사결정 테이블에서는 조건 항목이 참과 거짓이라는 이진값으로 제한됩니다.
의사결정 테이블을 구축하기 위해서는 분석가가 테이블의 최대 크기를 결정하고, 불가능한 상황, 일관성 또는 중복을 제거하고, 테이블을 최대한 단순화해야 합니다.

(번역) 의사결정 테이블(Decision Table) 테스팅 완벽 개요

댓글