(NDC2014) QA에서 적용할 수 있는 테스팅 기법과 패턴 활용

(NDC2014) QA에서 적용할 수 있는 테스팅 기법과 패턴 활용

1. 테스팅 기법 적용 사례

- 터키 카운터 스트라이크 온라인 사례

> 1~10레벨은 듀얼 베레타

  11~20레벨은 데저트 이글

  21~30레벨은 AWP를 받는다.

> 최소 레벨은 1이고, 최대 레벨은 30레벨이다.

- 동등분할 기법

: 몇 레벨이든, 각 구간 내에서는 어떤 값을 대입해도 결국 결과는 같다.

  몇 레벨이든, 각 구간 내에서는 같은 아이템을 받을 것이다.

- 경계값 분석 기법

: 각 구간 내 의미있는 값(레벨)은 1,10,11,20,21,30이다. 실제로 아이템이 바뀌기도 하고, 프로그램 할 때도 1과 10 관련된 숫자를 넣을 것이기 때문.

  따라서 많은 작업이 들어가는 이들 각 구간의 경계값에서는 결함이 발생한 가능성이 높다.

- 생각해볼 문제

> 레벨다운이 있다면? 또는 특정 기간에만 아이템을 받는다면?

> 이렇게 복잡해지는 경우엔 문제가 발생하여 앞의 기법만으로는 어렵다.

- 탐색적 테스팅 접근법(exploratory testing)

> 일반적인 단계별 개발 프로세스 : 요구 분석 > 분석 설계 > 상세 설계> 개발 코딩

> 일반적인 단계별 QA 프로세스 : 기획서 확인 > 요구사항 분석 > 기획서  리뷰 > 테스트 계획 > 테스트 설계> TC 작성 

                                     > 테스트 수행 > 결함 리포트 > 결과 보고

> 그 외의 모델 : 폭포수, 애자일 개발 모델, V 모델 등

                  모델별 설명 링크 http://dreamrugi.tistory.com/758

> Test Charter - Time-Boxing - Debrefing이 유기적으로 구성되어 계획과 실행을 동시에 진행

> Test Charter

ㆍ테스트 목적이 뚜렷하고 테스트 시간이 명확해야 한다.

ㆍ콘텐츠에 대한 추가설명이나 관련자료를 기입해도 무방

ㆍ계획 세션, 완료 세션, charter 구성 시간, 이슈 및 문의, 결함 수 등

                 

> Time-Boxing : 몰입 테스트, 그 시간에 집중해서 최대한 많은 결함을 발견하는 것. 다른 업무는 모두 중지한다.

> Debrefing

ㆍ요약 보고, 결과를 보고하는 것.

ㆍ결과에 대한 간단한 언급, 버그 처리 방법, defaulting을 했는지, 앞으로 수행할 것, 테스트 하지 못한 것들 등

- 리스크 분석 기법(risk-analysis)

> 제품 리스크와 프로젝트 리스크가 있으나 프로젝트 리스크는 독립적으로 관리하는 것이 효과적이라 PM과 협의

> 제품 리스크 : 제품 자체, QA할 대상, 테스트할 대상

> 프로젝트 리스크 : 그 대상이 가지고 있는 인력 문제, 인원 보충 문제, 개발 노하우, 개발 숙련도 등

> 진행과정

ㆍ리스크 식별 단계 : 리스크 아이템(항목) 선정, 어떤 항목이 위험 요소를 가지고 있는가?

ㆍ리스크 분석 단계

  *리스크 요소 : 장애발생 가능성, 영향력, 복잡도, 상호관계, 테스트 난이도, 사용 빈도 등, 유동적으로 변경 가능

  *스케일 선정 : 각 리스크 요소의 중요 정도를 숫자로 분별, 정리해서 표로 만든다.

  *매트릭스 작성 : 앞서 선정한 스케일을 통해 매트릭스를(분포도, 그래프) 만든다.

                   1>2,4>3 사분면 순서로 테스트해야 할 영역이다. 각 사분면에 걸친 것은 협의를 통해 결정할 것

                   장애발생 가능쪽은 개발팀에서, 영향력 쪽은 인수테스트, 즉 QA팀에서 주로 한다.

ㆍ리스크 계획 단계 : 분석한 것을 기반으로 한 리스크 전략 수립 단계

                        만약 개발 테스팅 중심이라면 2사분면 보다 4사분면(장애발생 가능)쪽에 중점을 두는 것

ㆍ리스크 추정 단계 : 리스크 모니터링, 제어 단계

2. 패턴 분석

- 유형 : 변수 타입 관련, 음수 예외 처리 관련, 동기화 관련, 리소스 관련

- 변수 타입 관련 : 2의 16승, 65536!

> 실수 패턴에다가 처리를 제대로 안해서 나타나는 버그들이 많다.(꼭 2의 16승만 되면 버그가 나더라.)

> 변수 타입에 고나한 패턴은 테스트할 때 반드시 체크하고 넘어가야 한다.

- 음수 예외 처리 관련

> 예외적인 입력을 받았을때 처리하는 것들 중, 간단한 음수입력을 처리하는 것은 기초 중의 기초라 한다.

> 보통은 애당초 특수문자의 입력을 막기도

> 그러나 이런 기초적인 실수가 빈발하는 경우가 많다.

> 그러니 음수 예외처리는 반드시 체크하고 넘어가야 한다.

- 동기화 관련 패턴

> 접속 종료가 곧 테스트 시작! : 동기화 문제로 접속 종료, 재접속하면 버그가 생기는 문제

> 접속 종료를 했다고 해서 테스트가 끝났다고 생각하지 말고 종료 후 바로 다시 테스트해보자.

> 동기화 관련 문제도 반드시 체크할 것

- 리소스 관련 패턴

> 체형이 다른 캐릭터가 같은 아이템을 공유할 경우 그래픽이 깨지는 현상

> 인벤토리 체크 누락 : 인벤토리 여유를 체크 안 해서 보상 아이템을 지급했는데 아이템이 유실

> 이벤트 연장

> 기타 등등

> 그래픽 리소스 관련 패턴도 확인할 것

- 코드 리뷰 항목을 만들어서 점검하면 패턴 관련 버그를 사전에 막을 수 있을 것이다.

3. 테스트 자동화

- 결함 패턴 분석을 이용하여 테스트를 자동화할 수 있지 않을지 생각해볼 문제

4. 마치며

: 게임 QA실무에 소프트웨어 테스팅 기법과 패턴을 적용하면 만족스러운 결과를 얻을 수 있다.

  이와같은 이론이나 결함 패턴을 적용하는 것은 대단한 것이 아니며 체계적으로 연구하고 프로젝트에 맞게

  최적화한다면 QA 업무의 완성도를 올릴 수 있을 것이다.

5. 참고문헌

- 소프트웨어 테스트 실무 가이드

- 소프트웨어 개발의 모든 것

- 개발자도 알아야 할 소프트웨어 테스팅 실무 제2판

- 위험천만 테스팅

- 소프트웨어 테스팅 용어사전

- 누가바닷컴

- 애자일 이야기

- ikooyAs note

- 뷰티풀 테스팅