열린 공간, 누가바닷컴

게임 테스트라 하면 굉장히 막연하게 느껴지게 됩니다. 가뜩이나 소프트웨어 공학이나, 테스팅 서적을 들여다 보면, 뭔가 복잡한 표나 도식들을 냅다 보여줍니다.

가령 아래처럼 9가지의 항목들을 처음 들어오는 사람에게 보여준다고 합시다. (틀린게 무지 많지겠지만 서두요.. 흐음..)

1 테스트할 시스템 및 제품에 대한 관찰 및 분석 후 구상합니다.

1. 초기구상 목표 확인 : GUI, 스크립트, 양식, 웹
2. 구상단계: 언어적인 문제, 사이드 이펙트
3. 백데이터 구성 : 데이터베이스 항목 검사 (오라클, SQL 서버로그 등등등)

      

4. 범위 : 얼마나 어떤 범위까지 테스트해야할지 확인 해야 합니다.
5. 초기 기초자료 및 요구사항 및 성능 문서 작성
6. 해당 담당부서별로 개발 일정 협의 및 진행

3  이 시스템 및 제품에 대한 테스트 계획을 수립합니다.
- 응용 프로그램 대한 요구사항 및 성능 문서
- 그 외 참조 자료들 (리서치, 외부 매체, 언론 인터넷 게시판 등)
- 범위 및 미검출(테스트를 해야 하는 항목 인지, 테스팅이 되지 않은 항목인지)여부 확인
- 지원 가능한 자원 매체(치트 코드, 혹은 데이터 백로그 등)
- 예약 및 외부 미팅이 필요한 경우

4. Testcase : 주어진 DATA 인지, 테스트 기법은 무엇인지, 실제로는 어떠한 조치가 이루어졌으며, 예상 결과와 실행결과의 차이는 어떤지를 적용한 항목입니다.

 - 테스트 케이스의 항목으로 구성되는 것들의 예시
- 버전 릴리즈 번호:
- 사전 조건 혹은 경로 :
- 설명 :
- 예상 결과 :
- 실제 결과, Statuc, 비고 (선택 사항)

5. Testcase 리뷰 : 해당 테스트케이스를 내부 리뷰를 하는 과정입니다.

- 체크리스트를 팀 내부로 전파.

- 실제 테스트 케이스에 대한 제품의 기능으로 이동.

- 테스트 케이스 인지 유즈 케이스 인지 팀 내부 회의로 의하여 도출

- 유즈 케이스의 경우 별도의 시나리오로 작성하여 관리

6. Testcase 실행

- 테스트 케이스를 살펴봅니다.

- 테스트 케이스가 해당 테스팅에 적용 되었을 때 구현 가능한 유효한 케이스인지 확인합니다.

- 결함을 발견하여 등재하거나, 테스트 케이스가 정상 동작하지 않는다면 다시 리뷰합니다.

7. 결함 처리 도표를 첨부합니다.

8. 마지막으로 발견된 결함간의 격차를 분석합니다. 기존 모델이나 전 유사 모델에서

나온 것인지 아니면, 해당 제품에만 해당하는지에 대한 회고가 필요합니다.

 그림 1-1

이론을 알아야 현업에 적용을 한다고 하였습니다. 하지만, 입문자 에게는 그게 굉장히 어려운 장벽이 될 수 있습니다. 그야말로 당황스럽죠. 이걸 어떻게 적용하지? 라면서 갸웃 하게 될거 같지 않습니까?

책을 보다보니 참 참신한 그림이 한 개 나왔습니다. 너무 축약해서 잘 못하면 모든 과정이 빠질 수 있지만.

알아보기는 쉽습니다.

그림2.1:게임 테스팅의 활동에 대한 그림

올인원 책에서 또 적절한 그림과 문구 등을 긁어줬습니다. 뭔가 단순하지만 바로 저게 단계를 잘 축약한 그림이라고 생각합니다.

여기서 중요한 건 과연 무얼까요. 처음 테스터 하시는 많은 분들이 말합니다." PLAY나 Testcase(testify) 가 중요한게 아닌가요?"

물론 중요합니다. 이는 기본이지요. 저는 조금 의견이 다릅니다. 아무래도 amplify 즉 상세하게 설명하는 부분이 가장 중요하다고 봅니다. 이유는 간단합니다.

앞서서 있었던 "Don't Panic" 에서 그 Panic은 잘 몰라서 오는거도 있지만 반대로 잘 알려주지 않아서도 생기기 때문이겠죠.

또한 아무리 증상을 내부에서 재연하였다 하더라도 이를 어떻게 나온 지 설명하지 못 한다면, 상당한 시간과 자원을 사용하게 될 것이 분명하다고 봅니다.

 다음 포스팅은 뭔가 스샷과 함께 해봅시다. 실전이 중요하니까요