오늘은 프라이드가 강한 거친 개발자, 경력이 부족한 불안한 기획자, 그걸 지켜보는 QA에 대해서 이야기해보겠습니다.
오늘도 쉬운 예를 들어보겠습니다.
여기 기획서가 있습니다.
구매하기 BTN을 클릭하면
구매하기 Alert 이 출력되어야 합니다.
QA 도중 해당 페이지에서 구매하기 BTN 을 클릭했는데
바로 결제 페이지로 이동되는군요.
결함을 등록합시다.
이게 왜 결함이야!!!
개발자가 엄청 화가 났습니다.
왜일까요?
QA에서 BTS에 등록한 결함을 보고 왜 결함이냐고 묻습니다.
●QA : 기획서에 명시된 대로 BTN 클릭 시 Alert 이 출력되어야 합니다.
●Dev : 어차피 유저는 구매할 생각으로 눌렀는데, 왜 Alert을 띄워줘야 하죠? 그리고 또 결제 페이지로 이동되면 정상 동작 아닌가요? 이 issue #001 은 수정하지 않겠습니다.
●Planner : 헉! ㅠㅠ
●QA : 흠...
냉정하게 분석하기
●QA : 기획자님 해당 기능에 대한 기획의도가 무엇일까요?
●Planner : 어... 그냥 다른 사이트도 구매하기 BTN을 클릭하였을 때, Alert 이 나와서 동일하게 기획하였습니다.
●QA : 흠... 그러면 해당 기능에 대해서 수정을 진행할 수 없습니다. 사실 구매하기 BTN을 클릭하였을 때, 결제 페이지로 이동되는 현상은 정상적입니다.
●Planner : 어떻게 하죠 ㅜㅜ
●QA : 잠시만요...
기획자가 경력이 부족하여 자세한 히스토리를 모르는 업무에 대해
기획서를 쓰다 보니 이런 사소한 기능에서도
Description이 왜 이렇게 정의되어 있는지 모르고 있습니다.
이전 대화에서 기획자가 "다른 사이트도..... 동일하게...."
라고 말한 것 기억하시죠?
자 그럼 다른 사이트를 확인해보면 QA가 해야할 일은 두가지가 있습니다.
1. 다른사이트를 기획한 사람에게 히스토리 물어보기 2. 관련된 프로젝트 문서를 확인해보기
히스토리 파악하기
1. 다른사이트를 기획한 사람에게 히스토리를 물어봅니다.
●QA : 혹시 00 사이트를 기획하실 때, 해당 Alert을 띄우는 이유에 대해 알고 계신가요?
●다른 기획자 : 흠... 잘 모르겠지만 CS 관련 부서에서 요청이 들어왔었어요.
2. 관련된 프로젝트 문서를 확인해보기
CS 관련부서에서 요청이 들어왔기 때문에 CS 확인할 수 있는 게시판에서 특정 키워드로 검색을 하거나
관련된 프로젝트 문서에 대해 열람 권한을 획득한 후 히스토리를 파악할 수 있습니다.
●QA : 그럼 해당 프로젝트를 진행할 때에 문서를 확인할 수 있도록 열람 권한을 주시겠습니까?
●다른 기획자 : 네 ~ 드렸습니다.
관련 프로젝트 문서를 확인하던 도중
CS 관련부서의 요청을 확인할 수 있었습니다.
이유는 두 가지였습니다.
1. 강성 컴플레인 유저
2. 구매하시겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많았던 점.
자 그럼 이제 개발자를 설득할 시간이 되었습니다.
수정해주세요. 얼른!!
●QA : 개발자님
●Dev : 왜요!
●QA : Issue #001 수정해주셔야겠습니다.
●Dev : 왜요!! QA 도 개발팀 소속이면서 기획자 편을 들어주는 거예요?!
●QA : 해당 기능은 과거 유저 CS로 인해 생긴 기능입니다. 바로 구매 페이지로 이동하여 강성 컴플레인을 건 유저가 있었습니다. 그리고 구매하겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많아 다른 사이트에도 모두 Alert 을 노출시켜주고 있습니다. 그래서 이번 00 사이트에서도 구매하기 BTN을 클릭하였을 때, Alert 이 출력되어야 합니다.
●Dev : 깨갱.. 알겠습니다. 수정되었습니다.
이렇게 해서 잘 마무리되었습니다.
물론 위의 예시는 쉽게 설명하기 위해 들은 예시입니다.
실무를 하다 보면 많은 사람들과 커뮤니케이션을 하지만
늘 잘되는 일은 없습니다.
실제로 저는 위와 같은 경험을 굉장히 많이 겪었습니다.
Minor 한 결함이고, 당연하다고 생각되는 기능이지만
의문을 가지고 자신이 한 개발이 항상 맞다!
이런 식의 대화도 많이 겪었습니다.
여기서 QA는 그 누구의 편도 아니며, 항상 품질만을 생각해야 되기 때문에
이런 상황에서는 "근거"가 명확해야 합니다.
저는 회사를 다닐 때, 항상 다른 사람과 친하게 지냅니다.
물론 사람들과 대화하는 걸 좋아해서 그렇죠.
이런 상황이 오면 또 다른 사람들에게 도움을 받기에도 엄청 좋습니다.
물론 저도 제 일이 아니더라도 도움을 받는 만큼 돌려줍니다.
그리고 항상 확인하는 것이 프로젝트를 진행할 때에 유사한 프로젝트는 어떻게 진행되었으며
특이사항이 있었는지에 늘 체크를 합니다.
그리고 이번 프로젝트에서 예외적인 상황이 나올 수 있는지 미리 체크리스트를 작성하여 대비를 하는 것이지요.
실무에서 쓰이는 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 도 무사히 마칠 수 있습니다.
실무를 할 때, 요구사항 명세서 (기획서) 기반으로 Testcase를 설계하는 경우가 많습니다.
그래서 업무를하면서 과장하면 100개 이상의 기획서를 확인했다고 해도 과언이 아닐 정도인데요.
같은 기획서를 봐도 QA 엔지니어의 역량에 따라 다른 Testcase가 설계되는 경우가 많습니다.
물론, Testcase가 다르더라도 소프트웨어의 품질 향상이 목적이기 때문에 큰 문제는 없습니다만
효율적으로 업무를 하기 위해서는 우리는 빠르게 접근할 수 있어야 합니다.
그래서 제가 Testcase를 설계할 때 사용하는 방법 중 하나는
FlowChart를 작성하고 그 FlowChart 기반으로 Test case, Scenario 를 작성하는 것입니다.
Flow Chart 를 작성하는 방법은 아래와 같습니다.
Flow Chart 를 구성하는 요소
Flow를 진행하게 될 조건 또는 사용자 (Conditions) 조건 또는 사용자(Conditions)가 진입/확인할 화면 상태 (States) 상태(States)를 변경하게 하는 상호작용 (Actions)
위의 세 가지만 구분된다면 Flow Chart를 쉽게 작성 할 수 있습니다.
예를 한번 들어보겠습니다.
세가지 STEP으로 진행해보겠습니다.
소프트웨어의 간단한 설명
외국인을 대상으로 한글을 배울 수 있는 교육용 App 이 있습니다. 교육용 App 에는 한글익히기 메뉴가 있으며 해당 메뉴에는 문자단위, 문장단위로 학습유형을 선택 할 수 있습니다. 문자단위의 학습에서는 자음, 모음을 선택해서 학습 할 수 있습니다. 유저는 메인화면 또는 네비게이션 드로어 화면에서 한글익히기 메뉴를 선택할 수 있습니다. 학습화면에서는 이전, 다음 단어/문장을 학습할 수 있습니다. 모든 단어/문장을 학습하면 학습종료 페이지로 이동됩니다.
요구사항
유저가 한글 학습App(임의의 학습App) 으로 자음에 대한 학습을 진행할 수 있어야 한다.
Flow Chart를 도식화 하기 위해서는 소프트웨어의 간단한 설명(또는 기획서)에서
요구사항이 무엇인지, 핵심이 무엇인지 빠르게 파악을 해서 요약을 해야 합니다.
그리고 여기서 Flow Chart의 세 가지를 도출해낼 수 있어야 합니다.
#Step 1#
▶Condition : 유저, 교육용 App
▶States : 메인 화면, 내비게이션 드로어 화면, 학습 유형 선택 화면, 자음/모음 선택 화면, 학습 화면
▶Actions : 유저가 각 화면에서 상호작용 할 수 있는 항목들을 기록( 선택, 클릭, 스와이프, 스크롤 등등..)
1. 메인 화면
2. 네비게이션 드로어 화면
3. 학습 유형 선택 화면
4. 자음/모음 선택화면
5. 학습화면
1-1. 한글 익히기
2-1. 한글 익히기
3-1. 문자단위 학습
4-1. 자음 문자
5-1. 학습 5-1-1. 자음 선택 이동 5-1-2. 다음 문자
1-2. 네비게이션 드로어 화면
5-2. 학습종료 5-2-1. 이전글자 5-2-2. 자음 선택 이동
##Step 2##
요구사항 도식화
###Step 3###
Flow Chart 기반의 Test case, Scenario 작성
위에서 작성한 Flow Chart 기반으로 아래와 같은 case가 도출됩니다.
예시를 들기 위해서 만든 요구사항과 Flow Chart 이므로 굉장히 간단하고 쉽습니다.
이를 응용하는 것은
프로젝트에 참여하는 이해당사자(기획자, 디자이너, 개발자 등등) 에게 프로젝트를 쉽게 설명할 수 있을뿐더러
접근하는 데에 오랜 시간이 걸리지 않습니다.
Testcase 리뷰 기간에 사용하는 것이 적절할 수 있겠네요.
마지막으로
저는 실무를 진행할 때, 유스 케이스 다이어그램을 사용하여 프로세스를 따로 정의하지 않습니다.
제가 하고 있는 업무 환경에서는 불필요한 동작이기 때문이죠.
그러나 Testcase 설계를 진행할 때에는 꼭 노트와 펜으로 도식화나 Flow Chart를 그린 후 Testcase 설계를 진행합니다.
Flow Chart를 그리다 보면 기획서의 오류에 대해 알 수 있고,
전반적인 테스트 흐름도 머릿속에서 시뮬레이션할 수 있기 때문입니다.
따라서 이번 글에서 하고 싶은 말은 제가 쓴 글은 단순 참고 대상입니다.
본인이 QA를 진행할 때, 설계 때부터 테스트가 어떻게 진행되는지에 대한 시뮬레이션을 2~3번 머릿속으로 진행해 봐야
경험 기반의 테스팅 기법 중 하나로 테스터의 경험, 직관, 기술능력을 바탕으로 테스팅 하는 기법
*내용추가(2021.04.20) *탐색적 테스팅의 구성요소 ⓐ테스트 차터(Test Charter) - 탐색적 테스팅에서 테스트의 범위와 목적, 테스트 방법 등을 정의하기 위한 테스트 참조 문서 - 테스트 목적 선언 또는 임무 - 테스트 차터는 테스트 아이디어를 포함할 수 있다. ⓑ시간 제한 (Time Boxing) - 테스트 차터를 정할 때, 시간을 정한다. - 시간 제한을 두고 테스트에 몰입을 유도한다. ⓒ테스트 노트(Test Note) - 테스트를 실행하며 테스트 실행 시 활동이나 머릿속에 계획한 내용, 설계한 내용을 간략하게 노트에 기록한다. - 테스트 케이스의 역할을 대체하며 검토 가능한 결과물로 활요한다. ⓓ요약보고/회고 (Debriefing) - 테스트가 종료되고 발견된 결함과 이슈를 공유한다. - 테스트 노트를 기반으로 테스트가 수행된 경험과 의견을 팀원과 공유한다.
탐색적 테스팅은 테스터가 의도하던, 의도하지 않던 테스트 진행 시 발생되는 기법중에 하나라고 생각됩니다.
탐색적 테스트는 테스터의 역량에 따라 결과가 달라질 수도 있습니다.
저는 주로 명세기반으로 TC를 작업하고, 그 TC 를 가지고 테스트를 하게되면 전반적인 기능에 대한 검증은 가능하지만
예외적인 상황에 놓칠 수 있는 결함이 발생하게 됩니다. (소프트웨어의 특성상 더더욱 확인이 필요한 작업)
예를 들면 , 음원 재생에 관한 탐색적 테스팅 기법을 적용해보도록 하겠습니다.
EX)
APP : MP3 플레이어
준비물 : 기획서, 기획서 기반으로 작성된 Testcase, 테스트용 단말기,
명세기반으로 작성된 TC
TC-ID
REQ-ID
Main
Middle
Sub
Pre-Condition
Test Step
Expected Result
XX-00X
XX-XX
Main
MP3 음원 목록
재생
1. 로그인 상태 2. 네트워크 연결상태 3. MP3플레이어 App 진입상태 4. MP3 음원 목록 진입상태
1. 재생중인 음원을 확인한다.
1. 선택한 음원이 정상재생되어야 한다. (재생중일때, 프로세스 바가 멈추면 안된다.)
일 때, 명세기반으로만 확인을 하게되면
단순히 재생버튼을 눌렀을 때의 동작만 확인하게됩니다.
재생버튼을 눌렀을 때 외부환경에 따라 재생기능이 어떻게 동작되는지 확인하고 싶습니다. (테스트 차터)
그러나 우리의 경험 멜론, 지니뮤직, 애플 뮤직 등 여러 음원 스트리밍 APP을 사용해본 경험에 의거하여 해당부분에 대해 추가적인 테스트를 할 수 있습니다. 이러한 계획들은 테스트 노트에 간단하게 기록합니다. (테스트 노트)
그러면 추가적으로 탐색적 테스팅을 간단하게 진행해보도록 하겠습니다.
제 경험으로는 대표적으로 MP3가 재생될 때 전화가 오거나 혹은 백그라운드에 MP3플레이어를 실행 시켜놓은 후 다른 APP 을 사용하였을 때 어떻게 결과가 나올지 궁금합니다.
1. MP3가 재생될 때 전화수신 event 추가
2. Pre-condition에 재생중인 MP3 제외 유저들이 많이 사용하는 APP 실행 추가
(Time box 를 설정하여 검증 진행)
위의 테스트를 진행하게 되었을 때, 극단적으로 외부 앱과의 충돌로 인한 APP 종료 상황이 발생되었다고 가정한다면
이 결함에 대해 팀원들과 이슈를 논의할 수 있습니다. (요약 보고 Debriefing)
요약 보고 활동을 통해 공유된 결함으로 앞으로의 프로젝트에 있어 시행착오를 줄이고, 효과적인 기획, 개발, 검증 모두
