안녕하세요.
오랫만의 테스팅 관련 글입니다.
그동안에 뭘 했냐면 구글 드라이브의 스프레드시트를 이용한 무료 Testcase 서식을 만들었습니다.
: 안녕하세요. 성장이 없는 8Bit Dog의 주인 하선생입니다.
: 죄송합니다. 바로 질문으로 넘어가죠. 왜 이 문서를 만들게 되었죠?
: 공동 작업을 할 수 있다는 건 동시에 일을 할 수 있다는 것인가요?
: 테스트에 생소한 분들에게 쉽게 다가가기 위함이란 건 무슨 말인가요?
: 지금까지 주구장창 장점만 얘기 하셨는데 단점은 없는 겁니까?
: 파워풀이요? 이건 무슨 보그병신체인가요..
: 그렇군요. 그럼 마지막으로 하실 얘기 부탁 드리겠습니다.
문서를 열면 Summary 페이지가 먼저 보입니다. 아래 탭을 확인하면 Summary Data, Testcase, Bug List의 4개 탭이 있습니다.
우선 Summary 페이지부터 보겠습니다.
맨 위에는 진행중인 프로젝트 명이 들어가고 아래에는 진행된 테스트중 나온 버그들중 중요한 이슈를 담고 있는 버그 리스트를 넣습니다. 중요도 높음인 문제가 주로 들어 갈 수 있겠지요. 문서를 보는 사람에게 중요한 문제를 각인시키는데 필요한 내용입니다.
참고로 버그의 중요도는 사전에 개발자들과 어느정도 합의가 되어 있는 것이 좋습니다. 물론 문제란게 그 합의된 범위 외에서 나오는 경우도 많습니다만. 사전 상의를 통해 개발자들과의 불필요한 커뮤니케이션 시간을 줄일 수 도 있습니다.
그 아래에는 진행된 테스팅 차수에 대한 결과를 볼 수 있습니다. 예제 문서에는 버전별 결과물로 나오지만 사정에 따라 차수별로 바꾸셔도 됩니다. 문제의 중요도별 변화량과 Testcase의 차수별 성공율 변화를 확인 할 수 있습니다.
막대 그래프는 아래로 깔릴 수록 좋은 것이고 Test 성공율은 올라갈 수록 좋은 것입니다.
해당 그래프에 데이터를 반영하기 위에서는 아래의 탭중 Summary data 탭으로 이동해야 합니다.
Summary Data탭의 화면입니다. 매우 단순합니다. 그냥 셀에 맞는 내용을 적어주시면 반영됩니다. 반영이 잘 안 될 경우에는 챠트의 고급수정에서 데이터 영역을 다시 지정해 주면 됩니다. 엑셀과 거의 동일하니 엑셀을 좀 다루 실 줄 아시면 쉽게 수정 가능합니다.
다음은 Testcase 탭입니다.
프로젝트 이름은 당연히 해당 프로젝트의 이름을 적습니다. 오른쪽에는 Version을 넣는 곳이 있습니다. SVN의 Revison으로 관리하는 곳이 있기도 하니 입맛에 맞춰서 수정하면 됩니다.
아래를 보면 pass, fail, block의 수와 함께 총 Testcase 갯수, Test 성공률이 나오는 영역이 있습니다. 이쪽은 자동으로 입력이 되도록 만들어져 있습니다.
그럼 그 아래가 진짜 Testcase 입니다. 참고로 해당 Testcase는 게임 도메인에서 주로 쓰는 서식입니다. 그리고 위에 대중소분류 및 조건 결과와 같은 내용이 있는데 해당 내용은 꼭 맞춰서 쓰지 않아도 됩니다. 적당히 수정해서 사용하면 됩니다.
테스트 결과는 o,x,b만 입력가능하게 되어 있습니다. 조건부서식과 데이터 확인 옵션이 들어가 있는데 역시 환경에 맞춰 수정해서 사용하시면 됩니다. 참고로 열을 추가하거나 삭제 할 경우 테스트결과를 참조하여 위에 테스트 결과 영역이 자동으로 입력되도록 한게 어긋 날 수 있습니다. 기본 엑셀을 다룰 줄 아신다면 쉽게 고치는 법을 아실거라 생각합니다.
마지막 Bug list 탭입니다.
테스트 중 발견된 Bug를 정리하는 부분입니다.
왼쪽부터 입력되는 내용은 다음과 같습니다.
- no. : 번호
- Version: 문제가 발생한 Client Version 을 기록합니다. Revison을 사용하기도 합니다.
- Tester : 해당 문제를 발견한 테스터의 이름을 적습니다.
- 담당자 : 해당 문제를 담당한 사람의 이름을 적습니다. (ex: 프로그래머, ui, 아티스트 등등)
- 분류 : 문제를 분류 할 수 있다면 분류를 적어 두는 것이 좋습니다. (ex: UI, 파티 시스템, 채팅 시스템, 성장 시스템 등등)
- 중요도 : 문제의 중요도를 기록합니다. 당연하지만 심각 일 수록 바로 수정되어야 하는 문제입니다. 모든 문제를 심각으로 할 경우 개발팀과 살인 피구가 벌어 지기도 합니다.
- 상태 : 문제의 상태를 기록합니다. BTS의 기본 시스템을 따르고 있습니다.
- 새로운문제: 테스터가 새로운 문제를 등록 시 지정
- 문제확인: 담당자가 해당 문제를 확인 했을 경우 지정. (담당자가 직접 변경)
- 문제수정: 담당자가 해당 문제를 수정 했을 경우 지정 (담당자가 직접 변경)
- 완료: 테스터가 해당 문제가 수정 된 것을 확인 했을 때 지정 (테스터가 직접 변경)
- 재수정요청: 테스터가 해당 문제가 수정 되지 않은 것을 확인 했을 때 지정 (테스터가 직접 변경)
- 내용 : 문제의 내용을 상세하게 기록합니다. 문제를 적는 방법은 이전 포스트 "당신의 버그 리포트에 꼭 들어가야 할 내용들"을 참고 합니다.
- 담당자 comment는 필요할 경우 담당자가 Comment를 남길 때 사용합니다.
: 안녕하세요. 성장이 없는 8Bit Dog의 주인 하선생입니다. 기시감 : (사료통을 흔든다)
: 죄송합니다. 바로 질문으로 넘어가죠. 왜 이 문서를 만들게 되었죠?
기시감 : 이유는 여러가지가 있습니다만 현재의 목표는 2개 입니다. 편하게 공동 작업을 할 수 있도록 하는 것과 테스트에 대해 생소한 분들에게 쉽게 다가가기 위한 이유 입니다.
: 공동 작업을 할 수 있다는 건 동시에 일을 할 수 있다는 것인가요?
기시감 : 게임 테스트의 경우 게임의 장르에 따라 한 게임에 몇십명이 되는 테스터가 같이 테스트를 하는 경우가 많습니다. 아마도 대부분의 작업 환경은 테스터 모두 따로 엑셀 문서에 테스트 결과를 작성하고 그걸 lead에게 보내면 lead가 취합하는 경우 일 것입니다. 하지만 구글 드라이브 문서를 이용하면 동시에 여러명의 사용자가 하나의 문서를 열어 동시에 작업을 하는게 가능 하더군요. 거기에 작업 내용또한 수시로 백업이 됩니다. 온라인에서만 사용 할 수 있다는 제약이 있지만 효율성 높은 작업 환경을 만들어 준다고 생각합니다. 그리고 모바일 디바이스에서도 쉽게 문서를 작성 하고 수정 할 수 있다는 점도 장점입니다. 클라이언트와 엑셀을 왔다갔다하며 작업 하는 것보다 외부 디바이스에서 테스트 결과를 바로바로 처리 할 수 있다는 점은 분명한 장점입니다.
: 테스트에 생소한 분들에게 쉽게 다가가기 위함이란 건 무슨 말인가요? 8 Bit Dog : 해당 문서를 만들던 초반에 운 좋게도 한 모바일 게임 스튜디오의 테스트 업무를 도와주게 되었습니다. 개발자 분들은 QA에 대해서 처음 경험하는 상황이었고 저는 간단하게 그분들과 커뮤니케이션과 업무를 할 수 있는 Tool 이 필요하게 되었죠. 맨티스나 레드마인과 같은 툴도 있습니다만 그런 걸 준비할 환경은 안되었기 때문에 작업중인 문서에서 해당 툴의 기능을 최소한적으로 적용 할 수 있도록 해봤습니다. 그 결과 거창한 툴보다는 오히려 최소화 되었지만 집중된 기능이 더 낫다는 생각을 가지게 되었습니다. 기본적인 테스트의 프로세스를 경험 시켜 드릴 수 있었으며 엑셀 문서와 가깝기 때문에 친숙했죠. 아마도 맨티스, 레드마인 툴을 사용하게 될 기회가 오더라고 금방 적응 하실 수 있을 거라 생각합니다.
: 지금까지 주구장창 장점만 얘기 하셨는데 단점은 없는 겁니까? 기시감 : 물론 있습니다. 온라인 상태에서만 제 역활을 할 수 있다는 점이지만 요즘 같은 시대에 이정도는 커버 되겠죠. 그리고 또 단점을 꼽자면 간략화 되어 있기 때문에 파워풀하게 사용 할 수는 없다는 것입니다.
: 파워풀이요? 이건 무슨 보그병신체인가요..
기시감 : 죄송합니다. 파워풀하다는건 예를 들자면 이 문서의 Bug list는 맨티스와 같은 전문 BTS 툴과 비교하자면 트래킹 기능에서 매우 약합니다. 이런 부분은 전문 툴만이 가질 수 있는 강점이죠. 뭐 그런 걸 얘기하는 거였습니다.
: 그렇군요. 그럼 마지막으로 하실 얘기 부탁 드리겠습니다.
기시감 : 모바일 디바이스 시장이 활짝 열리며 작은 개발 스튜디오가 매우 많이 생겨 났습니다. 모두들 좋은 게임을 만들기 위해 노력하고 있다고 생각합니다. 테스트라는 것은 언제나 성공 이후에 따라오는 것이었습니다. 하지만 그건 이제 과거 이야기라 생각합니다. 성공하기 위해서 더욱 필요한 것이 테스트입니다. 여러분들이 만드는 좋은 게임에서 버그가 1개가 있으면 그 버그를 체험하는 유저가 1000명이라면 1000명의 실망하는 유저가 생겨나는 것입니다. 테스트는 어려운 것이 아닙니다. 제 문서가 조금이라도 도움이 되어 좋은 게임이 좋은 품질로 완성 되었으면 합니다. 감사합니다.
반응형
'QA' 카테고리의 다른 글
| 게임QA로 게임회사 시작하기 (5) | 2014.02.24 |
|---|---|
| 버그의 추억 (1) | 2013.07.18 |
| 게이머 구분하기 (2) | 2013.03.04 |
| 확률을 어떻게 테스트 할까? (5) | 2013.01.06 |
| 당신의 버그 리포트에 꼭 들어가야 할 내용들 (5) | 2012.07.28 |
