문성준의 단단해지기

두 번째 에피소드입니다.

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

2019년 3월 7일에 작성한 제 게시글 중 가장 인기가 많은 게시글 중 하나인 

https://ddanx2.tistory.com/96

실무에서 쓰이는 ad-hoc testing, 그리고 random testing에 관련된 글이 있습니다.

이때는 QA 경력이 1년차일때, QA 보다는 Tester에 가까운 입장에서 쓴 글이었습니다.

그러나 지금은 하나의 part를 관리하는 part manager 로써 Ad-hoc testing에 관한 제 생각을 써보려고 합니다.

그때 제가 Ad-hoc testing에 대해 마지막으로 제 생각을 적었는데요 한번 보겠습니다.

이때 제가 쓴 글을 하나하나 분석해보겠습니다.

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

이 때는 Ad-hoc testing의 매력을 느끼지 못한 상태에서 단순 사전적 의미로 분석하고 제 생각을 적었었는데요.

사실 이때는 Tester의 입장에서 작성해서 둘 다 진행해도 좋다고 썼습니다. 

두 가지 테스트 방법을 동일선상에서 생각했기 때문이죠.

그러나 적재적소에 맞는 Testing 방법이 있습니다. 본인이 판단하기에 Ad-hoc Testing이 필요한 경우에는 Ad-hoc testing을 진행하면 되고, Random Testing 이 필요한 경우에는 Random Testing을 진행하면 됩니다.

다만 제가 하고자 했던 말의 요점은 Ad-hoc Testing 안에 Random Testing 이 포함된다고 느꼈기 때문에 저런 워딩이 나왔다고 생각됩니다.

그러나 기간이 촉박한 프로젝트에서는 모든 Testcase를 수행한 이후 Ad hoc testing 만 진행하는 게 맞다고 생각됩니다.
기간이 촉박하고 일정을 미룰 수 없을 때, Random testing을 통해 임의의 값을 입력하여 결함을 찾아냈을 때
결함 보고까지의 범위를 측정하는 시간이 많이 소요된다고 생각합니다.

이 부분을 작성한 이유는 제가 업무를 할 때 1~2달 사이의 프로젝트 업무를 많이 진행하였습니다.

3일 정도의 기획서 리뷰 기간을 가진 후 5일 정도 Testcase를 작성했습니다.

명세 기반의 Testcase를 작성하다 보면 느끼는 점이 많은데요.

사실 명세서는 유저의 요구사항이나, 유관부서의 요구사항이 반영되어있다고 하더라도 

소프트웨어의 품질을 높이는 데에는 한계가 있습니다.

어떻게 보면 사용설명서 같은 느낌으로 정해진 Step과 정해진 Result 가 나오기 때문입니다.

그래서 정해지지 않은 Step으로 진행하였을 때 소프트웨어 특성상 예기치 못한 Result 가 나오기 때문에

Ad-hoc testing을 진행해야 한다고 생각했던 것 같습니다.

그리고 이 생각을 뒷받침하는 근거로 실제 제가 근무하는 환경에서 Ad-hoc testing으로 나온 critical 한 이슈가 많았기 때문에 더욱더 그렇게 생각한 것 같네요.

그리고 Random testing의 정의를 봐도 일정이 촉박하면 테스트 케이스를 설계하여 문서화할 시간도 없다고 생각됩니다.
그래서 Ad hoc testing 만 단독으로 진행할 때는 프로젝트의 규모가 작아야겠죠..?

이 부분의 생각은 3년이 지난 지금 많이 바뀌었습니다.

2019년에 간과했던 부분은 Ad-hoc Testing을 진행할 때, Tester 나 QA 엔지니어의 역량이라는 필수 요소를 배제했었던 점이 가장 크게 작용했는데요.

Ad-hoc testing을 매력적으로 보는 이유는 보이지 않는 "역량"에 따라 결과물이 달라지기 때문입니다.

Part manager가 된 지금 QA Team을 구성할 때 제일 먼저 보는 것이 구성원의 경력입니다.

예를 들면,  신입직원, 1년 차, 3년 차, 5년 차 총 4명의 테스터가 있다고 한다면, 저는 신입직원, 5년 차의 Ad-hoc testing 의 결과에 주목할 것입니다.

왜 신입직원의 testing 결과를 주목할 것이냐 의문을 가지실 수 있는데요.

Testing 경력이 얼마 없기 때문에 고정관념이 없고, 예외적인 시도에 대해 열려 있기 때문입니다.

그리고 5년차의 Testing을 주목하는 이유는 베테랑 테스터의 실력을 믿기도 하는 것이지요.

물론 경력이 테스팅 역량을 대변해 줄 수 있는 수단은 아니지만 위험성을 줄일 수 있기 때문에 업무 분배에 참고하고 있습니다.

그래서 제가 하고 싶은 말은

"역량"이 높은 사람은 일정이 촉박해도 Testcase 나 CheckList 설계가 가능하며 동시에 Testing 도 무사히 마칠 수 있습니다.

그래서 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 생각이 바뀌었습니다.

아래 관련 게시글을 보면서 더 이어나가겠습니다.

https://ddanx2.tistory.com/125

제가 Flow Chart 기반으로 Test Case를 작성하는 방법에 대해 공유한 적이 있습니다.

주로 기획문서가 없는 소프트웨어에 대해 Testing을 진행할 때 사용하는데요.

옛날에는 기획문서가 없는 소프트웨어에 대해 Ad-hoc Testing으로만 진행될 수 있다고 말했지만

이제는 역으로 기획문서가 없어도 소프트웨어를 보고 Flow Chart를 작성할 수 있고, 그 Flow Chart 를 기반으로 Test case , Scenario 등 여러 문서를 작성할 수 있는 실력을 갖추었습니다.

그래서 2019 년과는 다르게 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 말하고 싶습니다.

결국 지금 와서 생각해보면 2019년의 제 QA 역량과, 2022년의 제 QA 역량이 다르고 그만큼 성장했기 때문에 생각이 바뀌었다고 볼 수 있습니다.

이제 또 3년 뒤에 저는 해당 글을 다시 가지고 와서 2025년에 작성하는 Ad-hoc testing에 대한 나의 생각 이런 식으로 포스팅을 할 수도 있겠네요.

아무튼 밤에 두서없이 쓴 글이긴 하지만 읽어주셔서 감사합니다.

오늘은 탐색적 테스팅에 관해 알아보도록 하겠습니다.

탐색적 테스팅의 개념 :

경험 기반의 테스팅 기법 중 하나로 테스터의 경험, 직관, 기술능력을 바탕으로 테스팅 하는 기법

탐색적 테스팅은 테스터가 의도하던, 의도하지 않던 테스트 진행 시 발생되는 기법중에 하나라고 생각됩니다.

탐색적 테스트는 테스터의 역량에 따라 결과가 달라질 수도 있습니다.

저는 주로 명세기반으로 TC를 작업하고, 그 TC 를 가지고 테스트를 하게되면 전반적인 기능에 대한 검증은 가능하지만

예외적인 상황에 놓칠 수 있는 결함이 발생하게 됩니다. (소프트웨어의 특성상 더더욱 확인이 필요한 작업)

예를 들면 , 음원 재생에 관한 탐색적 테스팅 기법을 적용해보도록 하겠습니다.

EX)

APP : MP3 플레이어 

준비물 : 기획서, 기획서 기반으로 작성된 Testcase, 테스트용 단말기, 

명세기반으로 작성된 TC

일 때, 명세기반으로만 확인을 하게되면

단순히 재생버튼을 눌렀을 때의 동작만 확인하게됩니다.

재생버튼을 눌렀을 때 외부환경에 따라 재생기능이 어떻게 동작되는지 확인하고 싶습니다. (테스트 차터)

그러나 우리의 경험 멜론, 지니뮤직, 애플 뮤직 등 여러 음원 스트리밍 APP을 사용해본 경험에 의거하여 해당부분에 대해 추가적인 테스트를 할 수 있습니다. 이러한 계획들은 테스트 노트에 간단하게 기록합니다. (테스트 노트)

그러면 추가적으로 탐색적 테스팅을 간단하게 진행해보도록 하겠습니다.

 제 경험으로는 대표적으로 MP3가 재생될 때 전화가 오거나 혹은 백그라운드에 MP3플레이어를 실행 시켜놓은 후 다른 APP 을 사용하였을 때 어떻게 결과가 나올지 궁금합니다.

1. MP3가 재생될 때 전화수신 event 추가

2. Pre-condition에 재생중인 MP3 제외 유저들이 많이 사용하는 APP 실행 추가

(Time box 를 설정하여 검증 진행)

위의 테스트를 진행하게 되었을 때, 극단적으로 외부 앱과의 충돌로 인한 APP 종료 상황이 발생되었다고 가정한다면

이 결함에 대해 팀원들과 이슈를 논의할 수 있습니다. (요약 보고 Debriefing)

요약 보고 활동을 통해 공유된 결함으로 앞으로의 프로젝트에 있어 시행착오를 줄이고, 효과적인 기획, 개발, 검증 모두 

피드백이 가능합니다.

*** 탐색적 테스팅에 관해 임의로 예를 들어 작성해 보았지만 부족한 부분이 많습니다.

피드백 환영입니다.***

안녕하세요

이번에는 PICT 의 설치 및 실행 방법에 대해 알아보겠습니다!

cmd 창에서 명령어를 입력해야하니

미리 cmd 명령어를 숙지하는게 좋을 것 같습니다.

안녕하세요!!

이번에는 Pairwise Testing 에는 어떤 Tool 이 있는지 알아보고

대표적인 Tool 소개와 Tool을 다운받을 수 있는 링크를 첨부하였습니다.

https://www.pairwise.org/tools.asp

에서 이와같은 페이지를 찾아볼 수 있고 다운로드 받을 수 있습니다.

안녕하세요

저번 Pairwise Testing 원리에 이은 두번째 시간은

CIT 기법에 관한 정리입니다.

안녕하세요

오랜만의 포스팅이네요..

오늘은 Pairwise Testing 에 대해서 글을 써보려고 합니다.

일단 이번글은 Pairwise Testing 의 정의에 대해서 알아보겠습니다.

오랜만에 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