[지식/경험] TC와 CL의 차이점

 

 

 

 

안녕하세요.

 

딩딩입니다!

 

오늘은 테스트 케이스와 체크리스트에 차이점에 대해서 설명하려고 합니다.

 

저는 처음에 테스트 케이스라는 것에 대한 개념이 너무 헷갈려서 고민이 많았었는데요.

 

이후 경험을 하면서 확실하게 체감하였고 정리된 부분에 대해서 말씀드리려고 합니다.

 

 

---

 

 

TC란 무엇인가?

 

 

TC는 풀어서 적으면 TestCase입니다.

테스트 사례(조건)이라고 하며, '테스트 용이나 검사 용 입력 데이터의 샘플을 사용해 정확성이나 완전성을 검증하는 것과 같은 특정 목적을 위해 개발된 테스트 데이터와 그에 관련된 프로시저들의 집합.'으로 정리되는데

 

즉 테스트에 대한 다양한 조건과 기대 결과를 나열한 것을 말합니다. (기대결과가 꼭! 포함되어야 TC입니다.)

 

구조적인 형태로는 순서/분류/사전조건/스텝/기대결과/결과값으로 구분할 수 있습니다.

 

 

[TC의 구조적인 형태]

- 순서 : 케이스의 넘버링

- 분류 : 테스트 조건을 묶어서 분류별로 정리 대, 중, 소 분류 등으로 구분 가능

- 사전 조건 : 테스트 조건을 확인하기 위해서 사전에 준비될 부분

- 스텝 : 테스트 조건을 실행하기 위한 스텝

- 기대 결과 : TC의 특징입니다. 스텝을 통해서 어떤 결과가 나와야 되는지에 대한 기대 결과가 표기되어야 합니다.

- 결과값 : 해당 케이스의 결과입니다. 통과인지 실패인지 등.

- 비고 : 결과에 따른 내용 정리

- BTS : 결과가 실패인 경우 별도의 BTS 링크 표기

 

 

 

 

 

CL란 무엇인가?

 

CL은 풀어서 적으면 CheckList입니다.

체크 내역이라고 하며, 특정 행동, 특성, 산물 등을 나열한 목록으로 정리할 수 있습니다.

 

즉 챙겨야 할 내역들을 놓치지 않도록 리스트업 해놓은 것입니다.

 

구조적인 형태로는 순서/항목명(내용)/체크박스(결과값)으로 구성이 됩니다.

 

[CL의 구조적인 형태]

- 순서 : 해당 체크리스트의 넘버링

- 항목 명 및 체크 내용(내용) : 체크할 내용

- 체크박스(결과값) : 해당 내용에 대한 결과

- 비고 : 결과에 따른 내용 정리

- BTS : 결과가 실패인 경우 별도의 BTS 링크 표기

 

 

 

 

 

[공통 : TC, CL 결과값]

진행했던 항목에 대한 결과값입니다.

 

- 테스트 대기 : Not Tested라고 하며 아직 검증을 하지 않은 항목의 결괏값

- 성공 : Pass라고 하며 검증한 항목의 기대 결과 및 체크 항목의 확인했다는 것의 결과값

- 실패 : Fail라고 하며 검증한 항목이 기대 결과와 다르거나, 체크 항목에 미달되는 것의 결과값, 비고란에 실패 내용도 함께 작성

- 테스트 제한 : Blocked라고 하며 특정 기능이 실패로 인해 아예 테스트가 불가능한 경우 결과값

- 이용불가 : Not Available라고 하며 미구현, 기획 변경, 스펙 아웃 등으로 아예 기능 자체에 대한 검증을 할 수 없는 경우의 결과값

 

 

 

그리고 QA가 작성하는 TC와 CL는 주관적인 부분이 들어가서는 안됩니다.

테스트를 하기 위해 TC/CL를 설계하는 것은 QA의 스킬이지만, 주관적인 항목들이 들어가서는 안되고, 오로지 기획서에 명세된 내역에 따라서만 한 항목들이 작성이 되어야 한다는 것입니다.

 

왜냐하면, 그 기획서와 다른 결과값이 나왔다는 건. 무조건 버그이기 때문입니다.

(기획의도 같아도 리포팅하는 습관을 기르는 것이 좋습니다.)

 

 

---

 

 

TC와 CL의 구조적인 형태로 먼저 구분을 해 보았습니다.

다음으로는 보편적인 사용처에 대해서 설명드릴게요.

 

 

 

 

 

TC의 사용처

 

 

 

테스트 케이스는 주로 새로 들어가는 특정 기능에 대한 전수 검증을 진행할 때 사용합니다.

전달받은 기획서를 프로세스에 맞게 리뷰까지 모두 완료 후 정리를 합니다.

정리된 내용을 기반(기획서 기반, 명세 기반이라고 함)으로 TC를 설계하게 됩니다.

 

주로 TC는 게임의 특정 기능, 콘텐츠, 시스템의 다양한 부분의 전수 검증을 진행하기 위해서 사용합니다.

TC를 만든 인원 외에도 다른 처음 접하는 인원도 해당 TC를 이용해서 결과값을 도출해 낼 수 있게 설계되어야 합니다.

 

주로 테스트 케이스는 추가된 기능과 사이드 이펙트 등을 예상할 수 있습니다.

 

TC의 설계 방법은 검증을 진행할 콘텐츠, 시스템, 혹은 별도의 기능에 따라 형태와 구성이 달라지게 됩니다.

(별도의 포스팅으로 다루도록 하겠습니다.)

 

 

 

 

 

CL의 사용처

 

 

다량의 품목 리스트 검증 또는 기본적인, 기존의 기능을 반복적으로 진행하는 루틴의 경우 사용됩니다.

게임 QA에서 주로 사용되는 부분은 확률 검증, 데이터 검증, 기본 기능 테스트(BVT) 등에서 사용되게 됩니다.

혹은 기존에 만들어진 기능에서 추가적으로 기능이 추가되었을 때, 전체적으로 다시 TC를 유지보수하고 만들기에는 시간적인 여유가

없는 경우 체크리스트를 이용해서 검증 문서를 만들기도 합니다.

 

- 확률 검증 : 실제로 이 확률에 해당 데이터 결과값이 도출되었는가?

- 데이터 검증 : 실제로 이 데이터 결과값이 확인되었는가? (ex. 아이템 리스트, 장비 수치, 스킬 수치 등등)

- 기본 기능 테스트(BVT) : 이 기본 기능이 정상 동작하는 것을 확인하였는가?

- 기존 기능에 추가 기능 : 기존 기능의 기능 구동은 정상 작동하는가? 또한 연계된 기능들이 어떤것이 있고 그들은 정상 작동하는가?

 

 

 

 

 

 

 

 

<22-02-08> : ISTQB를 기반한 TC와 CL 특징

 

■ 테스트 케이스(TC : Test Case)

- 테스트 분석 단계에서 테스트 베이시스를 분석하여 식별된 테스트 컨디션으로 테스트 설계 활동에서 테스트 케이스 작성

- 테스트 컨디션에 기반하여 개발된 전제조건, 입력값, 조치, 기대결과 및 사후 조건의 조합

- 특별한 목표 또는 테스트 상황을 테스팅하기 위해 개발된 입력값, 실행사전조건, 예상결과, 실행사후 조건들의 집합.

- 하위수준의 테스트 케이스(구체적인 테스트 케이스) : 구체적인 입력값들이 실제로 들어있는 테스트 케이스

- 상위수준의 테스트 케이스(논리적인 테스트 케이스) : 입력, 결과값을 돌려 쓸 수 있도록 설계된 테스트 케이스(추상 클래스와 같은 개념)

- 동적 테스팅의 주요 도구

- 기법을 적용하여 도출되는 경우가 대부분이고 기법이 보장되는 범위에서 효과성을 보장

 

 

■ 체크리스트(CL : Check List)

- 경험 기반 기법 중 하나의 기법

- 테스트하거나 평가해야할 내용과 경험을 나열해 놓은 것

- 테스트 경험과 노하우를 정리하고 목록화해서 테스팅에서 해당 내용 누락없이 검증하는 것을 목적으로 작성

(경험과 노하우의 반영물, 테스트를 효율적으로 진행할 수 있음)

- 주로 테스팅 절차와 테스트 대상 기능 및 시스템 요소등을 체크리스트로 작성함

- 일반 체크리스트 : 수행해야할 테스트 목록과 절차 나열

- 기능(블랙박스) 체크리스트 : 전체 시스템의 최상위 기능 체크, 개별적인 컴포넌트 기능, 서로 다른 레벨의 기능과 그룹핑

- 시스템 요소 체크리스트 : 상위 레벨 서브-시스템이나 모듈, 개별 구문이나 데이터 아이템, 다른 레벨의 시스템 요소와 그룹핑

- 효과성은 없음

 

 

 

---

 

 

이렇게 TC와 CL에 대한 차이점을 설명드렸습니다!

현업에서 항상 쓰이며, TC, CL 설계는 QA의 개인적인 스킬로도 평가가 됩니다.

TC와 CL의 개념조차 헷갈리는 부분이 계신다면 한번 정독하셔도 좋을 것 같습니다. 업무 간 많은 도움이 되길 바랍니다.

 

글로만 보면 정확한 형태가 어떤 것인지 감이 안 잡히는 경우가 있습니다. 조금 디테일하게 궁금하거나

개념을 좀 더 알고 싶다면 댓글 남겨드리면 추가 설명드리도록 하겠습니다.

 

 

 

 

 

 

 

 

 

 

[P.S]

끝으로 좋은 TC는 어떤 것 일까?에 대한 물음으로 지인 QA들과 많은 토론을 나누었었는데, 3가지로 정리가 되었었습니다.

- 커버리지

- 가독성

- 진행구성(설계)

 

일단 TC의 하나의 케이스에서 막을 수 있는 커버리지

전체적으로 보기 깔끔한 가시성(복잡하다... 버겁다 느낌이 들지않는)

그리고 테스팅 시 TC를 아래위로 왔다갔다하는 구성이 아닌 한번에 해당 뷰포트 내에서 마무리 할 수 있는 진행 구성 부분

 

여러분들은 어떻게 생각하시나요?