문성준의 단단해지기

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

몇 가지 상황에 어떻게 대처하는지 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 마무리하도록 하겠습니다.

오랜만에 QA 관련 글을 포스팅해봅니다.

QA 업무를 진행하다 보면

테스트 케이스를 모두 수행한 프로젝트에 대해 종종 ad hoc testing을 진행하곤 합니다.

ad hoc의 사전 의미는

입니다.

즉, 다시 정리해서 말하자면

비공식적으로 수행하는 테스팅이다.

 

공식적인 테스트 준비 작업 없이, 공인된 테스트 설계 기법을 적용하지 않고, 예상 결과를 사전에 정의하지 않고, 자의적이고 임의적으로 실행하는 테스트 활동을 의미한다.

실 업무에서 설계한 테스트 케이스를 모두 마친 후, 말 그대로 예상 결과를 정의하지 않고 테스트를 하다 보면

소프트웨어 특성상 결함이 발생될 수 있기 때문입니다.

실제로도 AD-HOC testing에서 발생된 결함은 예상외의 결과를 가져다 주기 때문에 결함의 중요도가 크리티컬 하거나 또는 엄청 마이너 하게 나타나지요.

그리고 저도 헷갈렸지만. 흔히들 하는 실수로

랜덤 테스팅 (Random testing)과 애드 혹 테스팅(ad hoc testing)을 동일 의미로 사용하는 경우가 많습니다.

의미상은 비슷한 것 같지만

테스팅적으로 깊게 들어가자면 엄연히 다른 내용입니다.

테스트 케이스를 설계할 때, 특정 범위나 값, 집합에 대해서 동등 분할, 경곗값을 등을 주고 테스트 케이스를 설계하고 수행하게 됩니다.

근데 Random testing은 테스트 설계 기법을 통해 입력값을 따로 설정해 주지 않고 임의로 값을 선택해서 수행하는 방법입니다.

어떻게 보면 비슷한 기법이지만 미묘한 차이가 있다는 점을 알아주셨으면 좋겠습니다.

그렇다면,

Ad hoc testing , Random testing은 언제 이루어져야 할까요?

프로젝트의 테스트 케이스 수행을 마무리 한 단계에서 예상치 못한 결함을 도출할 때?

아니면 기간이 촉박한 프로젝트에서 테스트 케이스 수행이 어려울 때?

기획문서가 없는 소프트웨어의 테스트를 진행할 때?

모두 사용 가능합니다. 물론 다른방법도 있으니 Ad hoc testing 이 최선의 방법은 아니라는 점!!

제 생각은 프로젝트의 테스트 케이스 수행을 마무리 한 단계에서 예상치 못한 결함을 도출할 때는 Ad hoc, Random testing 둘 다 진행해도 좋다고 생각됩니다.

그러나 기간이 촉박한 프로젝트에서는 모든 Testcase를 수행한 이후 Ad hoc testing 만 진행하는 게 맞다고 생각됩니다.

기간이 촉박하고 일정을 미룰 수 없을 때, Random testing을 통해 임의의 값을 입력하여 결함을 찾아냈을 때

결함 보고까지의 범위를 측정하는 시간이 많이 소요된다고 생각합니다.

그리고 Random testing의 정의를 봐도 일정이 촉박하면 테스트 케이스를 설계하여 문서화할 시간도 없다고 생각됩니다.

 

그래서 Ad hoc testing 만 단독으로 진행할 때는 프로젝트의 규모가 작아야겠죠..?

이상입니다..

피드백 환영입니다.!!


++ 2022년에 해당 글에 대한 제 생각을 적은 게시글입니다.
https://ddanx2.tistory.com/133