테스트 케이스 양식 - teseuteu keiseu yangsig

테스트 작성방법에 대해 포스팅해보려고 한다. 이 직군에 몸 담고 있으면서 온라인/오프라인을 막론하고 가장 많이 듣는 질문 중하나가 "테스트 케이스는 어떻게 만드나?"인데 사실 허무하게도 테스트케이스 작성에 있어 정해진 정답은 없다. 테스트 수행자가 어떻게 작성하느냐에 따라 테스트의 품질도 천차만별이기 때문이다.

그런 이유로, 이번 포스팅은 테스트케이스의 기준과 정답을 알려주기보다는 '테스트케이스 작성에 도움이 될만한 것들'을 몇 개 소개하려고 한다. 어떻게 보면 굉장히 기초적인 내용이기 때문에 QA/QC 직무를 어느정도 해본 숙련자에게는 어울리지 않은 내용일 수도 있으니 참고 바람. 아무튼 우리는 목적은 고품질의 테스트케이스를 만들면 된다는 것.

*굳이 테스트케이스의 이론 공부를 더 하고 싶다면 "개발자도 알아야 할 테스트 용어", "문제로 배우는 소프트웨어 테스팅", 마지막으로 STEN 홈페이지(STA, KSTQB)의 도움말을 참고하면 된다. 물론 ISTQB 자격증 공부를 하다보면 알고 싶지 않아도 알 수 있지만.

**본인은 2015년 'N****' 게임사에 입사하여 2020년까지 약 5년(1년 쉼)정도의 경력이 있는 QA 겸 테스터다. 중간에 작은 회사로 이직도 하면서 런칭 준비중인 게임에 대한 테스트케이스도 작성해본 경험이 있다. (QA는 혼자였는데 정말 힘들었다.) 위에도 언급했다시피, 본 포스팅은 주관적 경험을 바탕으로 작성되었으며 참고 정도만 할 뿐 굳이 똑같이 모방할 필요는 없다는 점을 알아두었으면 한다. 

• 테스트케이스?

테스트케이스에 대해 아무것도 모르는 상황에서 대뜸 테스트케이스를 작성하려고 하면, 머리가 멍해진다. 적어도 본인은 그랬다. 그게 뭔데 작성하라는거지? 테스트케이스는 '각 시험을 수행하기 위한 시험 시나리오' 라고 정의한다. 실제로 몇몇 회사는 테스트케이스를 '시나리오' 내지는 '테스트 시나리오'라고 부르기도 한다. 한 마디로 테스트 시 확인해야 할 부분을 상황(CASE)별로 작성한 표' 정도로 해석할 수 있겠다.

다음은 작성도구에 대해 알아보자. 보통 엑셀을 사용하는데, 테스터에 따라 워드를 사용하는 사람도 있고, 한글2007을 사용하는 사람도 있다. 사실 어떤 유틸리티를 사용할지는 크게 중요하지 않다. 메모장을 사용하더라도 고품질의 테스트케이스를 내놓으면 그만이기 때문이다. 그래도 회사 등 제출할 때는 범용적인 엑셀을 사용하는 것을 추천한다.

또한 테스트케이스 작성에 앞서 간단하게 테스트 인원, 테스트 범위, 테스트 목적, 테스트 일정 등을 정한 다음 시작해야하는데, 이는 고품질의 테스트케이스를 얻기 위한 초석이다. 생각없이 테스트케이스를 적다보면 문득 테스트의 목적이 헷갈리고 범위 또한 모호할 때가 있는데 이럴 때 테스트 전 정한 규칙이 큰 도움이 되기 때문이다. 굳이 문서에 적지 않더라도, 메모 등을 통해 기록해두도록 하자.

아래 테스트케이스는 네이버 메인을 기준으로 작성됐다. 시간관계상 약 20~30라인 정도만 진행했고 P, B, F 3가지 결과방식 사용했다. P= pass(확인), B= block(확인불가), F= Fail(오류). B의 경우 환경 미지원 등으로 확인이 되지 않을 때 사용하는데, 'B'없이 'P'와 'F'만으로 테스트케이스를 작성하는 방법도 있다. 이건 뭐 작성자 마음이다.

① 대분류 - 중분류 - 소분류 - 내용 - 결과 - 비고

내가 현업에서 가장 많이 사용하는 테스트케이스 형식이다. 기능별 혹은 위치 및 단락별로 분류를 크게 3가지로 나누고 내용에는 테스트해야 할 내용을 간단히 작성한다. 파란색은 테스트에 도움이 될만한 부가 설명을 기록한다. 가끔 정상동작했을 때의 이미지를 삽입하는 사람들도 있는데, 뭐 완벽한건 좋지만, 라인이 100줄이 넘어갈 경우 시간이 너무 많이 지체된다. 이미지까지 캡쳐하여 추가하는건 개인적으로 비추하는 편.

② 대분류 -화면번호 - 중분류 - 소분류 - 내용 - 추가내용 - 결과 - 비고

화면번호와 추가내용이 추가된 부분으로 사실 1번과 크게 다르지 않지만 수정해야할 화면번호를 추가하여 개발자들이 아주 조금이나마 더 효과적으로 버그에 대한 대처를 할 수 있다. 사실 개발자 중에는 콘텐츠를 완전히 숙지하지 못한 사람들도 많아 "메인화면 메일함 위쪽" 이라고 하는 것보다 "S0000008" 이라고 표현주는게 더 효과적이다. 추가 내용 부분은 1번의 파란색 글씨를 따로 우측으로 빼두었을 뿐 특별한 의미는 없다. 단지 형식의 차이 정도.

③ 대분류 -화면번호 - 중분류 - 소분류 - 내용 - 추가내용 - 결과 - 비고 - 이미지

위에서 잠깐 언급한 이미지를 추가하는 테스트케이스다. ①에서는 부정적으로 표현했지만 사실 테스트를 하다보면 특정 부분은 어쩔 수 없이 실제 이미지와 비교를 해야하는 부분이 있다.(월별 상품 배너 광고 변경 등) 테스트케이스 문서에는 단순히 "이미지 확인"이라고 작성해두었는데 비교할 원본이 없으니 개발자와 테스터 입장에서 이미지는 수 십, 수 백가지로 해석될 수 있기 때문이죠.

이미지의 개수가 적다면 위와 같이 해당 페이지에 첨부할 때도 있지만 보통 이슈 관리와 히스토리 관리를 위해

시트를 따로 빼거나 다른 문서에 작성하여 같이 전달한다.

④ 확인란

개발자 혹은 테스터의 직접적인 커뮤니케이션이 가능하거나 협엽이 쉬운 상황이라면 버그, 이슈를 직접 전달하여 업무를 진행할 수도 있지만 이슈의 수가 많아지고 협엽 및 유관부서가 많아질수록 해당 방법은 한계점을 보이기 마련이다. 특정 인원은 휴가라 공유 인원에서 제외 됐을 수도 있고, 이슈에 대한 진행사항도 놓칠 수 있기 때문. (사실 이런 규모의 프로젝트를 진행할 때는 BTS 또는 ITS 사용하는게 정상이긴 하다. 이미 대부분 사용하고 있기도 하고.)

결과 부분은 어떻게 보면 앞 내용에 대한 작성란 보다 더 공을 쏟아야 하는 부분이기도 하다. 오고 가는 엑셀 및 스프레드 시트 문서만으로 현재 이슈의 진행 결과를 알 수 있는 툴이 될 수도 있기 때문인데, 실제 QA/QC 입장에서 Fail이라 판단 했는데 개발/기획/운영진에서는 기획의도라고 정상처리하는 부분도 많이 발생하는 편이다. 누가 봐도 오류인데, 기획의도라고 우기는 기획자도 있으니 마음의 준비를 단단히 해야한다.

테스트케이스 문서는 보통 QA팀이 작성하여 유관부서로 전달되는데 이 때 (특히 개발) 유관부서는 해당 문서를 확인하고 F 처리된 부분에 대해 확인하고 수정 또는 코멘트를 남기게 된다. 이 부분의 히스토리를 유지하는게 이슈 관리 일정을 수립하는데도 꽤 많은 도움이 되기 때문에 히스토리는 최대한 유지되는게 좋다. 또 수정된 버전 혹은 모듈 역시 버그가 발생할 수 있기 때문에 QA는 1차/2차/3차로 나누어 관리하고 확인 일자를 메모해두도록 하자.

결국 최종적으로 테스트케이스 문서에는 "오류", "F" 등이 하나도 남지 않을 때까지 이 부서에서 저 부서로, 저 부서에서 이 부서로 계속 돌아다니게 된다. 

*개인적인 경험. 간혹 "F"가 남아있는데도 "영향도가 작다", "사용성이 적은 콘텐츠다" 라고 주장하며 유관부서에서 리스크를 감수하여 일정을 진행할 때가 있다. 개인적으로 실무를 접하며 QA의 현실을 가장 크게 느낀 부분이기도 하다. 가끔은 이럴꺼면 QA/QC를 왜 하나 싶기도 하다. 아직 한국에서는 QA의 힘이 그렇게 막강하지 않다는걸 알 수 있는 대목. 

이렇게 진행하다 큰 이슈라도 발생하면 그 책임은 누구에게 물을 것인지도 참 막막하다. 실제로 게임회사에서 재직 중, 시간 상 여력이 되지 않아 특정 콘텐츠의 결함을 인지하고도 정기점검을 끝내고 게임을 오픈한 적이 있었는데, 계정당 1회 획득 가능한 아이템이 무제한으로 획득 가능한 버그가 터져서 대규모 롤백 사태로 이어졌었던 경험이 있다.

결국 매출은 크게 감소하였는데, 너무 억울했었다.사업팀에서 오픈을 강행했고 책임도 전부 지겠다고 했는데 결국 내가 속해있던 QA 팀은 한동안 휴가 쓰는것도 눈치 보면서 30분 일찍 출근하고 그럤다는 이야기 아닌 이야기. 

영업팀/사업팀은 영업이익으로 존재가치를 보여줄 수 있다. 운영팀은 처리한 업무처리 양으로 보여줄 수 있다. 기획팀은 콘텐츠 매출을 통해 보여줄 수 있다. 그러나 QA/QC는 타 팀과 달리 이슈가 발생하지 않아야 실력을 인정받는 직군이다. 티 나는 실적이 발생하지 않는다는건 그만큼 타 팀에 비해 관심을 받지 못하고 있다는 방증이 되기도 한다. 딱히 무슨 일이 일어나지 않는 것이 존재의 이유라는게 일하면서도 참 아이러니하다고 생각을 많이 한 부분. 확실히 타직군처럼 엄청 드라마틱한 그런건 없다. 물론 지극히 개인적인 이야기이므로 참고 정도만 해주었으면 한다.

다시 본론으로 돌아옴.

위에 작성한 테스트케이스는 모두 예시일 뿐이다. 각 조직의 특성이 있고 모두 환경이 다른 만큼 테스트케이스가 천편일률적일 필요는 없다. 단, 최소한 어느정도의 가이드라인은 약속하고 규정해두는 편이 기록하고 관리하는데 수월한 것은 사실. 그런 의미에서 이 포스팅을 작성한 것이고, 이런 마음을 헤아려주셔서 포스팅을 봐주셨으면 좋겠다.

+팁 아닌 팁?

1. 누차 말하지만 테스트케이스 작성에는 절대적인 정답이 없다. 설계자가 마음먹기 나름이고 또 축적된 경험 여부에 따라 테스트케이스의 양에도 많은 차이를 보이기 마련. 여유가 있을 때마다 특정 콘텐츠 및 사물에 대한 테스트케이스를 자주 작성해보는 것도 장기적으로 테스트케이스를 유기적으로 만들 수 있는 원동력이 된다. 가장 많이 듣는 질문 중 하나가 "분류는 어떻게 나누나요?" 인데, 화면상 위치로 나누든, 기능별로 나누든 크게 상관은 없다고 생각한다. 개인적으로 기능별로 나누는게 더 편하긴 한데, 어떻게 나누든 해당 화면에서 제공하는 모든 콘텐츠는 커버할 수 있어야 좋은 테스트케이스라고 할 수 있지 않을까. 

2. TL(Test Leader)을 무시하지 말자.  본인이 게임회사 다닐 때는 TL은 일도 안하고 매일 노는 것 같아 내심 배가 아팠다. 작은 규모의 경우 테스트케이스 설계부터 테스트 - 사후관리 - 유관부서와 협의 등에 대한 모든 내용을 QA 혼자 혹은 몇 명이서 다 하게 되지만, 어느정도 규모가 있는 회사의 경우 TL(테스트 리더)와 테스터의 업무가 확실히 구분되어있다. 막말로 어느정도 규모가 있는 회사에서 TL이 테스트케이스를 직접 작성할 일은 거의 없다. 하지만 TL도 그 자리까지 올라가기 전엔 수도 없이 많은 테스트케이스를 작성해보았을 듯. TL의 주업무는 유관부서의 커뮤니케이션과 일정관리다.

3. 테스트케이스 작성은 위부터 아래, 좌측부터 우측으로 하는게 통상적이다. 작성자에 따라 아래부터 위, 우측부터 좌측으로 한다고 해서 그게 잘못된 것이고 안될 일은 아니지만, 만약 테스트케이스를 이용하여 다른 사람이 확인했을 때 아래부터 위로 테스트한다면 조금 불편하지 않을까? 보통 시선의 이동에 따라 처리하는게 덜 피로하기 때문이다. 실수할 일도 적고. 뭐 테스트케이스를 본인 혼자 보고 협업할 유관부서도 없다면 위부터 우측이든, 좌측부터 위든 크게 상관 없는 문제다.

4. 중의적인 표현은 쓰지 않는게 좋다.가장 대표적으로 "정상적으로", "정상동작" 이라는 표현이 있다. "A 영역에서 B가 정상적으로 작동되는지 확인" 이라고 작성했을 경우, 본인은 정상적인 동작이 무엇인지 알고 있지만, 다른 테스터의 경우 "정상적으로"에 대한 기준이 모호하기 때문.

5. 테스트케이스는 기본적으로 해당 콘텐츠에 대해 1도 모르고 있는 사람도 수월하게 테스트 할 수 있어야 한다. 즉, 누가보아도 테스트케이스를 이용하여 당장 테스트가 가능하여야 한다는 말이다. 특정 용어에 대해서는 낯설고 어려울 수 있지만, 그 밖의 테스트 방법 및 내용에는 누구나 알기 쉬운 내용이 들어가도록 작성해야 한다. 물론 업무효율적으로도 좋고. "이건 무슨 뜻이죠?", "이건 어딨나요?" 같은 질문이 여러 번 핑-퐁 될 이유도 없고 귀찮게 일일이 대답해줄 필요도 없고 말이다.

6. 기본적인 엑셀 수식은 외워두는게 좋다.

P,B,F 혹은 확인, 실패와 같은 결과표시는 그 개수가 수십, 수백 개에 달한 경우, 개발자가 일일이 확인하는데 많은

시간이 소요되는데, 이런 경우 Countif 함수를 이용하여 그 개수를 상단에 기록해두거나 B,F 항목에 대한 넘버링 혹은 화면번호를 메모해두곤 한다. 함수를 사용하지 않아도 눈대중으로 개수를 파악할 수 있겠지만, 그 수를 가늠하기 힘들정도로 테스트케이스가 늘어난다면 그건 또 지옥이라는 것도 알아두어야 한다.

그 밖에 눈금선은 보기 좋게 없애준다, A열은 살짝 띄워준다든가, 글자크기는 몇이 적당한가, 테두리는 어떻게 긋는 것이 보기 좋은가 등도 테스트케이스 설계가 어느정도 작성되면 고민해보아야 할 문제. 

7. 하위 분류는 더 많은 하위 분류로 분화하는게 좋다. 또 동일 표현을 사용하지 않도록 하자.

(좌측) 중분류- 검색창, 소분류- 검색창 (동일 분류명 사용) / 이럴꺼면 중분류와 소분류 나눈 이유가 없잖아?

(우측) 중분류- 검색창, 소분류- 검색창 (2개로 분화했지만, 동일 분류명 사용) 위에 같은 이유

동일 분류명을 사용하거나, 1개에서 1개로 분류가 된다면 테스트케이스로써 딱히 분류한 큰 이유가 없다. 물론 특정 콘텐츠의 경우 아무리 생각해도 1개 이상 분화가 힘든게 있는데, 뭐 그런 부분은 어쩔 수 없지만, 이왕이면 그런 개수를 최소한으로 줄이는 편이 실무적으로 좋다. 

8. 마지막으로 누군가의 입맛에 딱 맞는 테스트케이스를 만드는건 사실상 거의 불가능하다. 정말 잘 만들고 심혈을 기울여서 만들었다고 생각했는데 상급자의 경우 이게 마음에 안들고 저게 마음에 안들고 개선해야할 부분만 말해주고, 하는 경우가 참 많았다. 바로 가장 처음에 언급한 테스트케이스에 정답이 없기 때문에 발생하는 문제(?)인데, 결국 상급자에 입맛에 맞는대로 수정하고 바꾸다 보면 어느새 그 상급자가 생각하는 테스트케이스대로 가기 마련이다.

테스트케이스의 목적은 버그를 사전에 예방하고 이슈를 효율적으로 관리하기 위함이다.(후자는 BTS에 좀 더 가까울듯) 사실 형식에 얽메일 필요가 없다. 꾸준히 연습하고 설계해보면서 어떻게 하면 더 적은 시간을 쓰면서 많은 부분을 테스트 커버리지로 가져갈 수 있는지 고민해보록 하자. 본인의 경우 상급자와의 제출하는 테스트케이스가 여러가지 이유로 잔소리를 듣자 상급자에게 제출할 테스트케이스를 따로 만들었던 기억도 난다. 물론 실무적인 부분에서는 내가 제작한 것으로 하고.

이 포스팅은 QA/QC 테스터 입문 테스터(?) 분들을 위해 작성되었다. 별 것 아니지만 테스트케이스로 어려움을 겪고 계시는 여럿 분들에게 도움이 되었으면 하는 바람이다. 요즘 게임회사 취업하려면 테스트케이스 작성해서 포트폴리오로 내라고 하던데, 진짜인가..?

아무튼 나도 입사 초반 당시 TL에게 "경쟁사 게임 XXXX 테스트케이스 작성해오세요" 라고 과제를 받았었는데, 당시 테스트케이스 작성방법 및 분류 방법을 알려주는 사람이 없어서 많이 고생했던 기억도 난다. 무엇보다 한 번 직접 부딪혀보며 작성해보자. 이래저래 하다보면 언젠가는 좋은 품질의 테스트케이스를 얻을 수 있을 것이다.