문성준의 단단해지기

두 번째 에피소드입니다.

오늘은 명세 기반 작성법으로 TestCase를 작성한 후에

TestCase를 보완하는 CheckList를 작성하는 이유와 방법에 대해 간단하게 포스팅해보겠습니다.

가기 전에 두 가지 Keypoint를 짚고 넘어가겠습니다.

입력 값에 대한 예상 출력 값을 정해놓고 그대로 결과를 나오는지 확인한다.

테스트 혹은 평가해야 할 항목을 정리하고 누락 없이 검증하는 것을 목적으로 한다.

얼핏 보면 같은 내용 아닌가요?

라고 생각할 수 있습니다만

포커스를 어디에 맞추느냐 생각해보면 달라질 수 있습니다.

첫 번째 키 포인트는 예상 출력 값에 포커스를 맞췄습니다.

즉, 기대 결과를 중심으로 작성한 TestCase입니다.

두 번째 키 포인트는 항목에 포커스를 맞췄습니다.

경험이나 TestCase를 보완할 테스트 항목에 대해 작성한 CheckList입니다.

각각 차이를 쉽게 볼 수 있도록 아래 표를 준비해 보았습니다.

공통된 목적을 가지고 있으나 미세하게 다른 차이가 있습니다.

물론 사람마다 다르겠지만 제가 업무를 할 때는 위의 표처럼 구분지어서 사용하고 있습니다.

간단하게 예를 들어보겠습니다.

여기 로그인 페이지에 대한 기획서가 있습니다.

Description 1번 로그인 항목에 대한 Test Case를 작성해 보겠습니다.

# 명세 기반의 TestCase 작성

명세서 기반으로 작성하였기 때문에 위의 TestCase 에는 Test Step 동작 후 로그인 처리 동작에만 포커스를 맞췄습니다.

물론 로그인이 동작하면 Pass 처리가 되겠지만

우리는 그동안의 업무 경험으로 인해 우리는 추가로 보완해야 할 항목이 무엇인지 알고 있습니다.

회원에 대해 분류를 해야 하는데요.

이는 어떠한 사이트를 가도 공통된 항목이 있을 것입니다.

대표적으로, 비밀번호가 만료된 계정 또는 일정 기간 동안 접속하지 않아 휴면 처리된 계정 등 

해당 사이트를 접속하는 여러 회원에 대해서 테스트가 누락될 수 있습니다.

그렇기 때문에 CheckList를 추가적으로 작성합니다.

# 업무 경험 기반으로 CheckList 추가 작성

이런 식으로 회원별 CheckList를 추가로 작성하는 겁니다.

그렇게 된다면 TestCase로 1차적으로 로그인 기능에 대해 확인을 하고,

2차적으로는 회원을 분류하여 회원 타입별로 로그인 기능이 정상 동작을 하는지 확인할 수 있습니다.

오늘은 "TC 다 썼는데 CheckList도 작성해야 돼요?"

라는 의문에 대한 답을 어떻게 내렸는지에 대해 다뤄봤는데요.

사람마다 생각하고 실무에 적용하는 것이 각자 다르겠지만

우리 QA 엔지니어의 목적은 하나입니다.

어떻게 품질을 상승시킬 수 있고, 효율적으로 문서들을 관리할 수 있는지에 대해 늘 고민해야 됩니다.

그럼 Episode 02 마무리하도록 하겠습니다.

실무를 할 때, 요구사항 명세서 (기획서) 기반으로 Testcase를 설계하는 경우가 많습니다.

그래서 업무를하면서 과장하면 100개 이상의 기획서를 확인했다고 해도 과언이 아닐 정도인데요.

같은 기획서를 봐도 QA 엔지니어의 역량에 따라 다른 Testcase가 설계되는 경우가 많습니다.

물론, Testcase가 다르더라도 소프트웨어의 품질 향상이 목적이기 때문에 큰 문제는 없습니다만

효율적으로 업무를 하기 위해서는 우리는 빠르게 접근할 수 있어야 합니다.

그래서 제가 Testcase를 설계할 때 사용하는 방법 중 하나는

FlowChart를 작성하고 그 FlowChart 기반으로 Test case, Scenario 를 작성하는 것입니다.

Flow Chart 를 작성하는 방법은 아래와 같습니다.

위의 세 가지만 구분된다면 Flow Chart를 쉽게 작성 할 수 있습니다.

예를 한번 들어보겠습니다.

세가지 STEP으로 진행해보겠습니다.

Flow Chart를 도식화 하기 위해서는 소프트웨어의 간단한 설명(또는 기획서)에서 

요구사항이 무엇인지, 핵심이 무엇인지 빠르게 파악을 해서 요약을 해야 합니다.

그리고 여기서 Flow Chart의 세 가지를 도출해낼 수 있어야 합니다.

#Step 1#

▶Condition : 유저, 교육용 App

▶States : 메인 화면, 내비게이션 드로어 화면, 학습 유형 선택 화면, 자음/모음 선택 화면, 학습 화면

▶Actions : 유저가 각 화면에서 상호작용 할 수 있는 항목들을 기록( 선택, 클릭, 스와이프, 스크롤 등등..)

##Step 2##

요구사항 도식화

###Step 3###

Flow Chart 기반의 Test case, Scenario 작성

위에서 작성한 Flow Chart 기반으로 아래와 같은 case가 도출됩니다.

예시를 들기 위해서 만든 요구사항과 Flow Chart 이므로 굉장히 간단하고 쉽습니다.

이를 응용하는 것은

프로젝트에 참여하는 이해당사자(기획자, 디자이너, 개발자 등등) 에게 프로젝트를 쉽게 설명할 수 있을뿐더러

접근하는 데에 오랜 시간이 걸리지 않습니다.

Testcase 리뷰 기간에 사용하는 것이 적절할 수 있겠네요.

마지막으로

저는 실무를 진행할 때, 유스 케이스 다이어그램을 사용하여 프로세스를 따로 정의하지 않습니다.

제가 하고 있는 업무 환경에서는 불필요한 동작이기 때문이죠.

그러나 Testcase 설계를 진행할 때에는 꼭 노트와 펜으로 도식화나 Flow Chart를 그린 후 Testcase 설계를 진행합니다.

Flow Chart를 그리다 보면 기획서의 오류에 대해 알 수 있고,

전반적인 테스트 흐름도 머릿속에서 시뮬레이션할 수 있기 때문입니다.

따라서 이번 글에서 하고 싶은 말은 제가 쓴 글은 단순 참고 대상입니다. 

본인이 QA를 진행할 때, 설계 때부터 테스트가 어떻게 진행되는지에 대한 시뮬레이션을 2~3번 머릿속으로 진행해 봐야

미리 예정해두었던 일정에 차질이 없이 진행될 것입니다.

그럼 모든 QA 엔지니어 분들 파이팅입니다.