문성준의 단단해지기

두 번째 에피소드입니다.

오늘은 명세 기반 작성법으로 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 마무리하도록 하겠습니다.

오늘은 제가 실무에서 명세 기반 테스트 케이스 작성을 하면서 드는 생각과

몇 가지 상황에 어떻게 대처하는지 Episode 형식으로 간략하게 포스팅을 할 예정입니다.

상황 설명에 앞서 명세 기반 테스트 케이스 작성법에 대해 간략하게 짚고 넘어가겠습니다.

일단 명세기반 테스트 케이스 작성법이란?

요구 분석 명세서나 설계 설명서에서 테스트 케이스를 추출하여 테스트한다.

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

위의 두 문장 정도가 key point 입니다.

자세한 설명은 Naver 지식백과 링크에서 확인할 수 있습니다.

▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼

https://terms.naver.com/entry.naver?docId=3533034&cid=58528&categoryId=58528 

주로 저는 소프트웨어 기획서를 전달받고, 그 기획서에 나온 logic , description을 토대로

Pre-condition(사전 조건), Test Step(테스트 스텝), Expected Result(예상 결과) 3가지를 구분하여 작성합니다.

기획서에 명확하게 명시되어있다면 정말 빠르고 손쉽게 작성할 수 있지만

기획서의 logic이 불분명하거나 description의 내용이 부족하면 작성하는데 조금 시간이 걸리곤 합니다.

오늘 다룰 상황은 "생략"된 description입니다.

# 다른 페이지의 기능과 동일하다.

여기 2페이지의 기획문서가 있습니다.

1페이지 에서는 [A] Tab에서 Web BTN을 클릭했을 때의 Description 이 명시되어 있지만

2페이지에서는 이전 페이지와 동일한 기능을 한다고만 적혀 있습니다.

그러면 2페이지에 대한 Test case는 어떻게 작성해야 할까요?

어떻게 보면 똑같이 [B] Tab에서도 Web BTN이 있고, 동일한 URL로 이동하기 때문에 큰 문제는 없겠지만

Expected Result에 "이전 페이지와 동일하게 동작해야 한다."라고 적을 수는 없습니다.

TestCase를 작성하는 이유 중 하나는 문서화를 통해 문서를 참고하는 사람들에게 이해를 도울 수 있어야 합니다.

이전 페이지와 동일하게 동작해야 한다.라고 작성할 경우에는 

해당 프로젝트를 진행할 때는 이상 없이 진행될 수 있겠지만

추후 관련 프로젝트 개발을 위해  또는 새로운 인력이 소프트웨어 이해를 돕기 위해 해당 문서를 참고할 경우

[A] Tab의 기능 부분을 다시 숙지해야 하는 번거로움이 생기거나, 누락된 Case로 인해 오류가 발생할 수 있기 때문입니다.

Test Step이나 Expected Result 가 같을 순 있겠지만, Pre-Condition 이 다르기 때문에 꼭 구분해서 작성합니다.

간단한 예시를 들었지만, [A] Tab에서 나올 수 있는 Test Step 이 10가지 이상으로 Description 이 명시되어있는 상황에도

똑같이 [B] Tab 에 대한 Case를 구분하여 작성합니다. 

제가 실무를 할 때, 기획자마다 스타일이 정말 다릅니다.

어떤 기획자는 Description 상세하게 적어서 Ctrl + C, Ctrl + V를 해도 될 정도로 상세하게 Description을 적어주는 반면,

어떤 기획자는 예상 결과를 QA 가 추측을 해서 작성해야할 정도로 간략하게 Description 을 적어주기도 합니다.

물론, 유능한 QA 엔지니어라면 어떤 기획문서가 와도 입력값에 대한 정확한 예상결과를 도출해 낼 수 있어야 합니다.

오늘은 "다른 페이지의 기능과 동일합니다."

라는 상황에 어떻게 대처했는지에 대해 다뤄봤는데요.

앞으로 명세 기반 테스트 케이스 작성을 하면서 발생했던 상황과 예시를 많이 작성할 예정입니다.

많은 관심 부탁드리며~

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