‘테스트 베이시스’와 ‘테스트 디자인’은 무엇인가요?

질문

‘테스트 베이시스’가 무엇인가요? ‘테스트 디자인’은 무엇인가요?

“테스트 디자인 과정에서 테스트 베이시스를 검토한다”라는 말이 무엇인지 감이 오지 않습니다. 용어 설명을 부탁드립니다.

ISTQB 버전

ISTQB Syllabus 2018

답변

테스트 베이시스(Test Basis) 개요

ISTQB 용어사전에서 말하는 '테스트 베이시스'의 뜻은 다음과 같습니다.

• 테스트 케이스의 기준이 되는 시스템과 컴포넌트의 요구사항을 추론할 수 있는 테스트 케이스의 기반이 되는 모든 문서를 뜻함.

테스트 베이시스 - 요구사항 명세서

요구사항 명세서는 요구사항 분석 과정이 완료된 후 선별된 기능을 바탕으로 시스템 및 서비스에서 제공하는 특성과 기능을 기록한 문서를 말합니다.

Product Requirements Document - Product Management to Development

요구사항 명세서 구성

일반적으로 요구사항 명세서에는 「요구사항 ID, 요구사항 이름, 구분, 유형, 업무 중요도, 요구사항, 관련부서」 등을 기재합니다.

테스터는 요구사항 명세서로 어떤 작업을 하는가?

요구사항 명세서는 고객이 소프트웨어 제품/서비스에 요구하는 필요 사항을 적는 '요구사항'이 자세히 기재되어 있습니다.
그 뿐만 아니라 요구사항을 식별하고 요구사항에 대해 간단하게 설명할 수 있는 '식별 아이디'와 '요구항목 이름' 등 다양한 내용으로 구성되어 있습니다.
테스트 설계 전 요구사항을 확인하고, 향후 요구사항대로 최종 산출물이 개발되었는지 확인이 필요합니다. 또한, 요구 검증에 대한 테스트 결과는 고객에게 제공할 의무가 있습니다.

테스트 베이시스 - 아키텍처

아키텍처(소프트웨어 구조)는 소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고, 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙을 기록한 문서를 말합니다.

아키텍처 패턴의 종류

소프트웨어 아키텍처 패턴이란 시스템에 대한 기본 구성 스키마로써, 하위 시스템의 집근간의 관계를 구성하기 위한 규칙과 지침을 패턴으로 분류한 것 입니다. 이 아키텍처 패턴 또한 소프트웨어 개발 시 테스트 베이시스로 사용합니다. 이번 글에서 설명하고자 하는 바는 아키텍처 패턴도 테스트 베이시스로 사용한다는 점을 설명하는 게 목적이므로, 이번 기회에는 패턴의 종류만 언급하고, 상세 내용은 다루지 않겠습니다. 해당 패턴에 대한 내용은 Architectural Pattern페이지를 참고해 주세요.

계층화 패턴 (Layered pattern)
클라이언트-서버 패턴 (Client-server pattern)
마스터-슬레이브 패턴 (Master-slave pattern)
파이프-필터 패턴 (Pipe-filter pattern)
브로커 패턴 (Broker pattern)
피어 투 피어 패턴 (Peer-to-peer pattern)
이벤트-버스 패턴 (Event-bus pattern)
MVC 패턴 (Model-view-controller pattern)
블랙보드 패턴 (Blackboard- pattern)
인터프리터 패턴 (Interpreter pattern)

테스터는 아키텍처 패턴으로 어떤 작업을 하는가?

테스터들은 이러한 아키텍처의 패턴을 확인함으로써 시스템과 컴포넌트들이 어떤 식으로 연계되고, 어떻게 상호작용 하는 지를 이해할 수 있습니다.
그리고 이를 통해 테스트 설계 시 위험 요소를 미리 식별하거나 테스트 케이스를 작성하여 개발 완료 후 확인이 가능해집니다.
예를 들어, 데이터 간 인터페이스(Interface)에서 주고 받는 파라미터(Parameter) 값의 데이터 타입(Data Type)을 굳이 일일히 테스터에서 알려주지 않아도 되므로, 예외 상황 테스트(Exception Testing)를 훨씬 원활하게 수행할 수 있습니다.

테스트 베이시스 - 개발 설계 문서

개발 설계 문서란, 요구시힝 분석/설계 단계를 거쳐 식별된 내용을 어떻게 컴포넌트 및 시스템으로 개발할 지에 대해 기술한 문서들을 말합니다.

개발 설계 문서의 종류

기획서(화면 설계서 or 스토리보드): 시스템 구성도, 이해관계자 정의, 팀 R&R 정의, 개발 범위 명시
시스템 흐름도
프로세스 정의서
용어 사전
ERD
공통코드 정의
네이밍 룰
WBS

테스터는 개발 설계 문서로 어떤 작업을 하는가?

위 V 모델은 테스터들이 소프트웨어 개발의 각 단계에서 도출한 산출물들로 어떤 테스트를 하는 지에 대해 개괄적으로 설명합니다.
요구사항 항목들은 시스템 개발 완료 후 인수 테스트(Acceptace Testing)으로 진행됩니다.
시스템의 작동 방식에 대한 내용은 시스템 테스트(System Testing)으로 진행됩니다.
시스템의 요구 항목 및 작동 방식은 통합 테스트(Integration Testing)으로 진행됩니다.
각 컴포넌트 및 모듈의 세부 기획 사항은 단위 테스트(Unit Testing)으로 진행됩니다.
그 외에도 각 단계에서 진행할 수 있는 여러 테스팅 활동들이 있습니다.

※ "전체 테스트", "풀(Full) 테스트"라는 말은 콩글리시(Konglish)이며, 국제 표준에서는 인정하지 않는 실무자들의 언어이므로, 가급적 사용을 지양하시기 바랍니다.

테스트 디자인(Test Design) 개요

디자인(Design)이라는 단어를 들으면 우리는 흔히 그래픽 디자인을 연상하지만, 사실 Design은 '기획'이나 '설계'를 의미합니다. (다음 영한사전, Dictionary 영영사전) 그러므로 우리가 "테스트 디자인"을 말할 때 "테스트 케이스를 도화지에 그림 그리듯 하는 것이다."라고 표현하시는 분들도 계신데 사실 조금은 틀린 표현입니다. 테스트 디자인은 그 용어 자체로 "테스트 활동을 설계한다"라는 의미를 가지고 있기 때문입니다.

즉, 테스트 디자인이란, 위 1번에서 설명한 테스트 베이시스를 토대로 테스트 활동 전체에 대한 기본 설계를 하는 행위로 볼 수 있습니다. "테스트를 어떻게 수행할 것인가?"라는 것이 테스트 디자인의 행동 목적이므로, 이를 위해 테스트 베이시스를 기준으로 검토하여 테스트 설계를 진행하게 됩니다.

"테스트 활동을 설계한다"는 말과 "테스트를 계획한다"는 말은 다른 의미입니다. 아래 '관련 참고 자료'에서 Test Plan vs Test Design 내용을 참고하여 주세요. 기회가 될 때 필자들이 다시 설명 드릴 수 있도록 하겠습니다.