[팀블로그] 소프트웨어 테스팅 참고서

Test와 Test Case와 Test Scenario의 차이

2022. 3. 23. 21:19
글쓴이 © 『 Lv8+の 꽃怪獸 』 천년나무

     

질문

본 포스팅의 질문은 SW테스트와 품질 카페에 올라온 질문을 기반으로 재구성하였습니다.


Test Case와 Test Scenario의 특징과 차이점에 대해 알고 싶습니다. ​TC와 TS를 작성하기 위해 검색해본 바로 두 개의 사용 기준이 다른 듯 한데 명확히 알고 싶습니다.

 

 

ISTQB 버전

ISTQB 전체 지식 체계 및 ISTQB Globassry

 

 

답변

본 포스팅의 답변은 SW테스트와 품질 카페에 올라온 원글의 답변 내용들을 기반으로 재구성하였습니다. 제 답변에 더하여, 다른 분들의 답변을 추가하여 재구성하였습니다. 이 부분 감안해 주십시오. 감사합니다.

 

ISTQB Glossary

먼저 소프트웨어 테스팅의 기준 문서로 활용되고 있는 ISTQB Glossary에 어떻게 정의되어 있는 지 확인해 보겠습니다.

 

테스트 시나리오(Test Scenario)는 테스트 실행을 위한 일련의 활동을 구체적으로 기술해둔 문서입니다. 테스트 시나리오는 「테스트 스크립트」라고 불리기도 하며, 혹은 「수동 테스트 스크립트」라고 부르기도 합니다.

테스트 케이스(Test Case)는 「프로그램의 특정 경로를 실험」해보거나 혹은 「프로그램이 특정 요구 사항을 준수하는지를 확인」하기 위한 목적으로 사용합니다. 이 때, 「특정 목적」 또는 「테스트 조건의 확인」을 위해 개발된 「입력 값, 실행 사전 조건, 예상 결과 및 실행 사후 조건」 등을 포함은 내용의 집합을 테스트 케이스라고 합니다.
 여기에서 하나 더 짚어야 하는 용어가 있습니다. 바로 Test라는 용어입니다. ISTQB Glossary에서는 Test에 대해 다음과 같이 정의하고 있습니다. 테스트(Test)한 개 이상의 테스트 케이스의 집합을 의미합니다.

 

즉, Test라는 용어와 Test Case라는 용어는 다른거고, 또 Test Case라는 용어와 Test Scenario라는 용어도 다른 의미입니다. 실무에서는 이 세 개의 용어를 혼용해서 사용하는 경우가 많습니다만, 원론적으로 이 세 가지 용어는 모두 다른 의미입니다.

 

 

영어도 어원은 있다

이런 차이가 나타나는 이유는 다음과 같습니다. 기본적으로 '한국말'에서는 '한국어'의 표현으로 '한글'을 사용하지만, 그 언어의 세부 내용들을 살펴보면 사실 많은 수의 단어들이 한자, 일어, 러시아어, 영어, 유럽어 등에서 차용되었다는 점과 궤를 같이 합니다. 예를 들어 "예절"이라는 단어는 우리 일상생활에서 흔히 쓰는 말이지만 사실 「예절(禮節)」은 '예의와 범절'이라는 의미가 담긴 한자 단어를 기반으로 합니다. 이와 같이 영어의 단어들도 라틴어나 기타 유럽의 언어들에서부터 다양한 영향을 받으면서 발전했고, 유럽의 각 언어권들은 각자 발전하면서 상호 영향을 끼쳤습니다. 그에 따라 현지인들은 각 단어에 담긴 의미를 (우리가 '예절'이라는 단어에서 느끼는 감정처럼) 느낌으로 이해하고 있습니다. 즉, 우리는 테스트 케이스를 TestCase로 받아들이지만, 영어권 사람들은 이 단어를 Test와 Case가 합쳐진 단어로 받아들인다는 의미입니다. 하지만, 이 단어가 한국에 전파될 때는 Test와 Case가 따로 떨어져서 들어오지 않고, TestCase로 붙어서 들어오는 데다가 우리는 라틴어 영향권의 언어를 사용하지 않다보니 용어 혼동이 발생할 수 있습니다.

 

그래서 필자는 가끔 한국말의 의미가 궁금해서 한자 사전이나, 우리말 어원을 찾아보기도 하며, 또 영단어 볼 때 영어의 어원을 찾아보기도 합니다. 재미있어서요. 적어도 선사시대 이후 인류가 기록을 시작한 뒤로 쌓여온 수 많은 언어들 속에 담겨 있는 다양한 의미들은 그 원어를 추적해서 공부해보면 재미있기도 하고, 공부할 때도 더 잘 이해가 되기 때문입니다. 뭐, 쉽게 말해서 테스트 관련 용어들도 사전을 좀 찾아보시는게 좋다는 의미입니다.

 

영어 원어를 알려주는 온라인 사전을 소개해 드립니다. 

 

Etymonline - Online Etymology Dictionary

The online etymology dictionary (etymonline) is the internet's go-to source for quick and reliable accounts of the origin and history of English words, phrases, and idioms. It is professional enough to satisfy academic standards, but accessible enough to b

www.etymonline.com

 

etymonline 사전에서 Case의 어원을 찾아 보면, 이 단어는 13세기부터 "어떤 일이 벌어지는가, 어떻게 될 것인가"라는 의미로 사용되기 시작했고, 이는 프랑스어의 「Cas - 사건, 사고, 이벤트 등」에서 유래했다고 합니다. 이 프랑스어인 Cas는 라틴어의 Casus에서 유래했다고 합니다. 즉, 테스트 케이스라는 의미는 특정 테스트 상황에서 어떤 일이 발생하는가에 대한 점을 확인하는 행위이지요.

 

어원을 찾아본다는 행위는 굳이 어려운 사전이 아니라도 재미있다고 생각해서 하나 더 소개해 봅니다. [한국민족문화대백과사전 발췌, 하단 링크 참고] 시나리오는 Scenario라고 쓰는데, 이 단어의 어원은 이탈리아어인 Scena에서 유래했다고 합니다. 이 Scena라는 단어는 16세기 이탈리아의 즉흥희극 코메디아 델라르테(Commedia dell’arte)에서 주연자가 극의 줄거리와 배우의 소임, 각 장면의 기본적인 진행 등을 메모하여 공연 참고자료로 쓰게 되면서부터 생겨난 것이라고 합니다. 

 

즉, 쉽게 말해 시나리오라는 단어가 가진 의미는 "하나의 연극 장면에서 배우들과 줄거리와 장면에서 나타낼 장치, 진행 사항 등을 담았음"에서 발생했음을 보여줍니다. 그렇다면 '테스트'라는 단어에 '시나리오'를 붙여 '테스트 시나리오'가 된다면 좀 더 쉽게 이해가 되지요. 특정 테스트 장면, 상황 들에서 발생하는 일련의 줄거리와 흐름, 데이터 등을 확인하는 행위라고 해석하면 됩니다.

 

 

그래서, 테스트와 테스트케이스와 테스트 시나리오의 차이는? 

자, 다시 본론으로 돌아가겠습니다.

• Test는 기본적으로 명사도 될 수 있고, 동사도 될 수 있습니다. 동사는 '시험하다'라는 의미인거고, 명사는 '시험의 단위'를 의미하는 의미입니다.
• TestCase에서의 'Case'는 그 시험의 특정 '정황'을 의미합니다.
• Test Scenario에서의 'Scenario'는 말 그대로 '각본', 즉, 일련의 이어진 사건들을 의미합니다.

 

쉽게 예를 들어 설명하면 이렇습니다.

•"장보러 마트 간다"는 테스트입니다. 장보러 가서 뭘 할지에 대한 세부적인 Data Set 혹은 Test Suite가 후술될 것입니다.
•"장보러 마트 가서 당근을 산다"는 테스트케이스입니다. 확인해야 하는 해야 하는 목적과 데이터가 명시되어 있습니다.
•"장보러 마트 갔다가, 간 김에 밥도 먹는다"는 테스트 시나리오입니다. 확인해야 하는 일련의 활동들을 나열합니다.

 

이런 용어들을 외우실 때 뭐가 더 크고 작고 하게 외우지 마시고, 어떻게 다른지를 고려하여 받아들이시는게 좋습니다. 이런 용어들은 상하 관계를 가지는게 아니라, 그냥 쓰이는 상황이 다른 경우가 더 많습니다. 길이가 긴 요리용 젓가락이 식사용으로 사용하는 짧은 젓가락 보다 상위 개념이 아닌 것과 같은 의미입니다.

이미지 출처1 : http://nearbyshop.co.kr/product/흑단요리용젓가락/61/   -   이미지 출처2 : https://flypo.tistory.com/1059

 

 

해외 커뮤니티의 정리

해외의 커뮤니티인 Guru99에는 Test Scenario와 Test Case에 대해 다음과 같이 소개하고 있습니다. 번역하면서 발생하는 모호한 표현에 대해서는 필자가 임의로 추가적인 의미를 부여하였습니다.

 

테스트 시나리오 테스트케이스
테스트 시나리오에는 처음부터 끝까지 테스트 가능한 기능을 설명하는 개념적인 내용이 포함되어 있습니다. 테스트 케이스에는 명확한 테스트 단계, 테스트 데이터, 애플리케이션의 모든 기능을 테스트하기 위한 예상 결과 등이 포함됩니다.
세부적인 "테스트 방법" 보다 개념적인 "테스트 대상"에 더 중점을 둡니다 . 세부적으로 "무엇을 테스트할지" 와 "어떻게 테스트할지"에 대한 강조하여 가능한 완전한 테스트에 중점을 둡니다.
일반적으로 테스트 시나리오는 한 줄 정도로 제공합니다. 따라서 테스트 수행 중에는 항상 모호함이 존재합니다. 테스트 케이스는 수행 단계, 전제 조건, 예상 결과 등을 정의합니다. 따라서 이런 방식의 테스트에는 모호함이 적으며, 테스터가 임의로 테스트를 수행할 수 없습니다.
테스트 시나리오는 BRS, SRS 등과 같은 제품과 관련한 주요 테스트 문서에서 파생됩니다.
 • BRS(Business Requirement Specification)
 • SRS(Software Requirement Specification)
테스트 케이스는 대부분 테스트 시나리오에서 파생됩니다. 단일 테스트 시나리오에서 여러 테스트 케이스를 파생할 수 있습니다.
기능의 처음부터 끝까지 애자일한 방식으로 민첩하게 테스트하는 데 도움이 됩니다. 응용 프로그램을 세부적으로 보면서 철저하게 테스트하고자 할 때에 도움이 됩니다.
테스트 시나리오는 개념 수준의 작업입니다.
 • 역자 주 - 영어로 High-level은 높은 수준이라는 이야기가 아니라, 개념 수준이라는 의미입니다. "나무 보다는 숲을 본다"는 의미로 받아들이시면 됩니다.
테스트 케이스는 세부 수준의 작업입니다.
 • 역자 주 - 영어로 Low-level은 낮은 수준이라는 이야기가 아니라, 세부 수준이라는 의미입니다. "숲 보다는 나무를 본다"는 의미로 받아들이시면 됩니다.
테스트 시나리오를 사용하면 문서를 생성하고 테스트를 수행하는 데 필요한 시간과 리소스가 상대적으로 적게 투입됩니다. 테스트 케이스를 사용하면 문서 작성 및 테스트 케이스 실행을 위해 더 많은 리소스 투입이 필요합니다.

 

필자들은 위 자료 외에도 아래 "관련 참고 자료"란에 여러 링크들을 준비해두었습니다. 번역 도구를 사용하여 다양한 해외 사이트들에서 설명하는 두 용어의 차이점에 대해 확인하시고, 어려운 부분이 있으시면 다시 SW품질과 테스팅 카페에 질문을 주십시오.

 

 

실무에서는 어떻게 써야할까?

이번 단락은 이론적인 이야기가 아니라 실무적 관점의 이야기입니다. 이 블로그의 또 다른 필자들이 본 글을 검토하면서 실무 이야기를 조금 써주었으면 좋겠다는 의견을 주셔서 맛보기로 살짝 실무 관점을 남깁니다. 이게 전부라고 오해하시면 안됩니다. 아주 General한 이야기만 하겠습니다.

 

실무 이야기이다보니 누군가에게는 몽둥이로 뼈를 맞은 듯 아픈 이야기일 수도 있고, 어려움을 겪고 있는 누군가에게는 속시원한 사이다 같은 이야기가 될 수도 있겠습니다.

 

(1) 테스트 케이스의 특성 : 일반적으로 테스트 케이스를 작성할 때는 세부적으로 자세히 서술합니다. 제품의 스펙을 가능한 모두 테스트해야 할 때 작성하며, 시간이 오래 걸리더라도 가능한 많은 상황에서 다양한 데이터를 테스트해야 할 때 작성합니다. 제품을 잘 모르는 사람도 테스트 케이스를 읽으면서 어떤 상황에 어떤 데이터를 사용해서 어떻게 테스트를 해야 하는 지 (어느 정도) 알 수 있도록 작성하는게 대부분입니다. 그러나, 그렇다는 말은 당연히 수행하는데 시간이 오래 걸리며 많은 인력이 필요하게 됩니다. 

 

(2) 테스트 시나리오의 특성 : 테스트 시나리오는 조금 다르게 제품/서비스의 전체 흐름을 빠르게 확인해야 하는 상황이거나, 전체 모듈에 대한 이해를 갖춘 상태에서 테스트를 빠르게 진행해야 할 때 선택하는 경우가 일반적입니다. 그래서 테스트 시나리오는 제품에 대한 이해가 갖추어진 사람들이 빠르게 여러 상황을 가정하고 데이터를 검증할 수 있는 경우 사용합니다. 우리가 흔히 "경험 기반 테스트"라고 알고 있는 테스트를 진행할 경우에 사용합니다. 

 

아, 맞다. 그런게 있습니다. 실무에서는 「테스트 시나리오」라고 부르지만, 사실 '용어만' 그렇게 되어 있고, 실제로 따져보면 "자동화 코드"이거나 "테스트 케이스"를 그렇게 부르는 경우도 상당히 많습니다. 모든 테스트 실무자가 ISQTB Glossary를 공부하지는 않았으니까 회사마다 실제 용어는 다를 수 있습니다.

 

예를 들어 보겠습니다. 하나의 프로젝트 내에 100개의 모듈이 있고, 해당 모듈들은 각기 1번~100번까지의 번호로 이름이 매겨졌다고 가정합니다. 그리고 각 모듈은 자기 앞뒤 +1, -1번 모듈과만 의존성을 가진다고 가정합니다. 예를 들어, 3번 모듈은 2번과 4번에 의존성을 가지는 것이지요. 이 때, 우리가 이번 패치로 4번 모듈을 수정했다면 테스트는 어디를 해야 할까요?

 

당연히 3번과 4번과 5번입니다. 처음부터 끝까지 모든걸 테스트할 필요 없지요. 이런 경우 테스트 케이스를 써야 할까요? 테스트 시나리오를 써야 할까요? 상황에 따라 다르겠지만, 필자라면 테스트 시나리오를 사용하고, 검증할 데이터세트(Data Set)를 구성하여 커버리지(Coverage)를 높이겠습니다. (물론 실무의 상황은 누구나 다를 것이므로, 이는 필자의 의견임을 밝혀 둡니다.)

 

그래서 즉, 정규 릴리즈/패치가 있을 때는 실제 서비스 상황과 동일한 환경을 갖추어 놓고 테스트 케이스로 처음부터 끝까지 보는게 의미가 있을 수 있겠고, 특정 모듈의 변경이 있는 경우는 해당 시나리오와 데이터 세트를 갖추어 진행하는게 현실적일 겁니다.

 

이 부분이 사실... 현실의 테스트 전문가들에게는 아픈 이야기입니다. 하지만, 21세기가 된 후 22년이나 지난 지금까지도 SW개발팀 내에서의 Testing팀은 보유한 전문성을 회사에서 잘 인정받지 못하며, "QA팀"이라는 애매한 이름으로 불립니다. "테스트 하자"는 말이 쪽팔리신 건지 자꾸 "QA 하자, QA했어?" 라고 합니다. (음... 「테스트」라는 말이 대체 왜 쪽팔리신지 잘 모르겠습니다만...) 현실에서는 의미만 잘 전달되면 되니 그러려니 합니다만, 사실 QA와 Testing은 다른 행위인데 이를 동일 시 해 버리면 조직의 품질 발전은 언젠가 한계에 부딛힐 수 밖에 없습니다. 그래서, TDD를 도입하고 여러 방식을 도입해도 어느 순간 한계점에 임박하는 거거든요.

 

그러한 조직들에서는 아주 빈번히 발생하는 문제가 있습니다. "테스트는 완벽해야 한다"면서 아주 조그만 수정을 하고서도 전체를 다 테스트하자는 말도 안되는 소리를 아직도 하곤 합니다. 사업을 관장하는 누군가들은 자기 의지를 관철 시킬 목적으로 개발 부서 내 "테스트 전문성을 재고"하기 보다는 "테스터의 단가를 낮추거나 아웃소싱을 사용"하는 방식으로 테스터의 수를 늘리면 된다고 생각합니다. 그러다가 오류가 나오면 오류를 못 잡았다고 괜히 테스트 담당자에게 난리 치는 경우도 다반사지요. 자, 누군가 동네에 방화를 했으면 불 지른 사람을 찾아 나무라거나, 아니면 앞으로 누구도 불을 못지르게 예방할 생각을 하는게 상식적이고 정상적 접근입니다. 방화를 왜, 누가 했는지 상관 없고, 불을 못 끈건 나쁘다며 소방관만 나무라는 격입니다. 이런걸 사자성어로 적반하장(賊反荷杖)이라고 합니다. 필자는 그런 행동 양식을 "프로그래머의 설계 역량 미숙을 테스트 전문가에게 덮어 씌우는 기만행위"라고 이야기합니다.

 

그만하겠습니다. 실무 이야기를 하니까 좀 우울하죠? 그래서 테스트 전문가분들이 이 글 읽으시면서 속 시원하시라고 조금 쎄게 써봤습니다. 이 글 읽으시는 테스트 전문가 여러분, 다들 실무 현장에서 건승하시기 바랍니다.

 

※ 필자 주 : 경험기반 테스트와 탐색적 테스팅은 다릅니다. 두 개를 혼동해서 사용하지 마세요.

• 경험 기반 테스트는 특정 제품/서비스에 대한 이해도가 높고, 해당 제품에 경험이 많은 전문테스터가 시나리오와 변경 예상 부분을 중심으로 테스트를 수행하는 방식의 접근을 사용합니다. 
 탐색적 테스팅은 특정 제품/서비스에 대한 이해도가 떨어질 때 제품의 전체 구간, 설계 시 찾아내지 못한 의존성 등을 Blackbox 관점에서 찾아내기 위해 반복적이고 순차적인 방식의 접근을 사용합니다.

두 개 중 무엇이 더 옳다고 이야기하는 건 틀렸습니다. 두 개는 상황에 따라 상호 혼용 및 보완되어야 합니다. 모든 테스트는 정황에 기반(Context Driven)합니다. 버그를 많이 찾을 수 있는 방식으로 상황에 맞게 사용하시면 됩니다. 그리고 프로젝트 내에서 그렇게 할 수 있는 사람이 테스트 전문가(Test Expert)입니다.

"우리는 애자일팀이니 탐색적 테스팅을 해요."라는 말은 사실은 굉장히 창피한 이야기입니다. 개발팀 내부에 추적 가능한(trace-ability) 설계 프로세스가 없다는 이야기를 하고 있는거니까요. 애자일은 모두 옳고, 전통적(?)인 방법은 모두 나쁘다는식으로 (유치원생이나 할 법한) 이분법적이고 극단적 사고 방식은 좋지 않습니다.

 

 

참여자 정보

 글쓴이 : 천년나무

• 검토한이 : Bykj, 품생품사

 

 

STEEG 개인 의견

※ STEEG 전문가들의 개인 의견은 각 전문가 개인이 경험한 경력에 따른 주관적 견해입니다. 이런 개인 의견들의 경우는 그룹 전체의 의견을 대표하지 않음을 알립니다.

본 글과 관련한 전문가 의견이 아직 없습니다. 

 

 

관련 참고 자료

※ 아래는 필자들이 선정한 관련 외부 자료입니다. 아래 자료들은 필자들이 작성한 본문 의견과 다를 수 있으며, 필자들과 관련되지 않았을 수 있습니다.
 

test scenario

A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script.

istqb-glossary.page

 

test case

A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

istqb-glossary.page

 

test

A set of one or more test cases.

istqb-glossary.page

 

Test Case vs Test Scenario: What’s the Difference?

What is the Test Case? A Test Case is a set of actions executed to verify a particular feature or functionality of your software application. The Test Case has a set test data, precondition, certain e

www.guru99.com

 

Test Case vs Test Scenarios - javatpoint

Test Case vs Test Scenarios with introduction, software development life cycle, design, development, quality assurance, quality control, methods, black box testing, white box testing, etc.

www.javatpoint.com

 

What is difference between Test Cases vs Test Scenarios?

Test Case is ‘How to be tested’ and Test Scenario is ‘What to be tested’. Lets learn What is difference between Test Cases Vs Test Scenarios with proper example

www.softwaretestingclass.com

 

Introduction of Test Artifacts - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

 

시나리오 - 한국민족문화대백과사전

글자에 의하여 영화의 시청각적인 묘사를 구체적으로 표현하는 것을 목적으로 하며, 영화의 각 장면(scene)을 구성하는 데 필요한 등장인물과 대사·동작·배경·음향 등 여러 가지 요소를 종합적

encykorea.aks.ac.kr

 

 

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band