QA이론문서

Game QA이론

■ C o n f i d e n t i a l

Version 1.6

D a t e 2 0 1 2 . 0 2 . 1 3

N a m e 주 건 영

Ⅰ. 품질관리의개요

Ⅱ. Game QA의개요

Ⅲ. 품질보증활동

Ⅳ. 테스팅활동

0. Document Maps

Ⅰ. 품질관리의개요

- 품질관리의업무

- 품질관리의역사와발전

- 품질비용산출

1. 품질관리의 업무

QA(Quality Assurance)

프로세스 관리(연구,개발,출하)

연구.개발.자산 관리

표준/기준의 정립

국제, 국내 표준인증의 업무

QC(Quality Control)

수입 검사, 출하 검사

공정 검사

표준/기준의 정립

고객 클레임 확인

품질관리

[결함의 발견]-슈하트

• “생산제품의 경제적 품질 향상”• 통계학의 도입• Control Chart를 적용• 엄격한 검사

[통계적 품질관리]-닷지와 로믹

• 샘플링 검사법”• ASTM 매뉴얼• 체계적인 관리 도입

[통계적 프로세스 통제]- 데밍• 경영관리 14개 포인트• 데밍 사이클

[품질을 위한 경영관리]- 쥬란

• “전사적 품질관리”주장• “비용”의 정의

(실패/예방을 통한 비용)

[종합적 품질관리]- 파이겐 바움

• “품질보증”• “무엇이 필요하고, 어떻

게 해야 하는가?”• 전략적 측면• 고객에 의한 품질 정의

[2차 세계대전]

• 군수품의 품질관리• 품질관리에 과학적

학문의 도입의 시작

품질관리 품질경영

2. 품질관리의 역사와 발전※ 품질관리의 역사

※ 품질관리의 발전

발생하기 전 대처발생 후 대처

전통적 방식 현대적 방식

예방, 과정 중심검사, 제품 중심

ZD 표준AQL 표준

품질과 비용의 동시추구품질과 비용의 양자택일

전사적인 문제개발 파트만의 문제

품질비용

품질 비용의 3대 원칙

불량품은 처음부터 만들지 않는다.

불량품이 고객에게 전달되지 않게 한다.

예방비용

평가비용

전달될 경우 신속하게 조치 한다.내부비용

외부비용실패비용

준수비용 (품질을 지키기 위한 비용)

비준수비용 (품질을 지키지 못해 발생한 비용)

3. 품질비용 이론과 비용의 산출

비용 산출 항목을 설정 (내부 / 외부)

품질 비용 산출 (변수 및 예외비용 포함)

비용 측정 단계 설정 (항목의 비율 조정)

예상비용 산출 (실제 비용 산출)

※ 품질비용의 산출

※ 쥬란의 품질비용 이론

Ⅱ. Game QA개요

- Game QA의등장배경

- Game QA의업무

- Game QA의대화법과조직

- Game QA의자세와기타업무

• “팩맨”과“E.T”출시 사례• 낮은 품질 및 수준• 무조건적인 다량생산• 무리하게 조정된 일정• 기존 성공에 대한 자만심

• “패미콤” 출시 사례- 게임을 엔터테인먼트로 인식- 품질 및 수준의 향상

• 닌텐도 가이드라인 작성(Game에 엄격한 기준을 제시)

아타리 쇼크의 문제점 닌텐도의 패미콤

Game QA의필요성 인식

※ 닌텐도 가이드라인 : 닌텐도에 게임을 출시하기 위해 제시한 10가지의 기준으로 부정적이고 좋지 않은 콘텐츠를 사전에 배제하는 기준.

1. Game QA의 등장과 도입단계※ Game QA의 등장

※ 개발팀에 QA업무를 도입시키는 단계

비 주기 이슈

공유

정기 이슈

공유

문서공유

테스트 진행

문서 피드백

집중 테스트

품질

의견제시

품질

권한위임

프로세스

최적화

콘셉트 단계(콘셉트 확정)

프로토타입 단계(프로토타입 제작)

알파 단계(알파 버전 개발)

서비스 단계(서비스 버전 개발)

• 협업 제반사항 구축- 형상/버전관리 툴 구축- QA 프로세스 협의

• 버전 기능 검증- 기능/시스템/퍼포먼스

• 버전 게임성 검증- PIT 진행- 데이터 분석 진행

• 장르, 아이디어 확정• 재미요소 확정• 개발툴, 그래픽콘셉 선정

• 장르 선호도 조사• 개발툴 검토 및 분석

• 기획서 작성• 그래픽의 시각화• 기본적인 기능 구현• 개발에 필요한 툴 개발

• 협업 제반사항 협의• 기획서 검토 (리뷰작성)• 게임 방향성 검증 작업• 개발 툴 구매 지원

• 기획명세서 작성• 그래픽 리소스 작성• 클라이언트 / 서버 제작

• 업데이트 버전 개발• 유지 및 보수• 유저 요구사항 확인

• 업데이트 버전 검증- 기능 검증- 게임성 검증

• 유저 요구사항 분석• 서비스 데이터 분석• 이슈관리

개발팀

QA팀

2. 개발 단계별 Game QA의 업무

품질 예방

프로세스수립 및 관리

개발 지원

개발 자산 관리

사전 리뷰 활동

게임 개선 요소 추출

게임 품질 평가

개발 / QA /사내 표준프로세스의 수립

리스크 관리 : 문제점을 발견하고 이를 이력으로 관리

프로세스의평가/개선

프로세스의문제점 발견

개발팀 육성(인큐베이팅)

개발 S/W 구매검토

S/W 구매 및개발팀이 모르는 전사

적 이슈공유

개발의방향성을 정립

이슈관리 및 공유 개발/연구 자원 관리

게임 개선 리뷰(기획명세서 등의 문서)

개발 프로세스 리뷰

업무 수행 후 제대로진행되었는지 리뷰로

검토

문제 / 개선사항의 도출

게임성 분석(평가지표, 사용성 테스트, 통게적 검증, 문서적 검증 등)

오류에 대한개선사항 제시

3. Game QA의 품질 예방 업무

품질 검증

테스트 프로세스

사전 리뷰

테스트 업무

테스트 진행관리

테스트 랩 관리

테스트 리스크 관리

테스트 계획수립

일정/계획 수행/피드백 업무 규정개선

적용

테스트 계획 진행 결과 분석결함 보고 및수정 확인

계획서Test-Case 및Check-List

결과 보고서 리뷰문서

형상관리 툴을 통한 형상관리 BTS를 통한 결함 관리

테스트 S/W 및 H/W 관리테스트 관련 툴 관리(성능/패킷 측정 도구)

4. Game QA의 품질 검증 업무

직책에 따른대화 상대

QA 리드 테스트 리드 테스트 엔지니어

임원급관리자

AnotherQA 리드

Another테스트 리드

Another엔지니어

개발팀장(기획/프로그램/그래픽)

개발자(UI/프로그램/그래픽)

QM/PD/PM

유관부서실무담당자

언어적 대화 방법• 테스트 엔지니어 : 검사한 항목에 따라 정확하게 현상을 설명.• 테스트 리드 : 현재 테스트 상황에 대하여 숙지.• QA 리드 : 현재 품질 상황에 대하여 어느 수준인지 정확하게 표현할 수 있어야 함.

기술적 이해 방법 • 모르는 기술적 용어에 대하여 항상 학습 및 메모하는 습관 필요.• 솔직하게 기술자에게 물어보거나, 유추하여 질문.

발표 설명 방법 • 일 대 다의 상황일 경우 보고내용(이슈 및 보고서)를 발표하면 즉각적인 대응을 얻는데 효과적이다.• 발표의 주제 및 내용을 짧은 시간 안에 정확히 전달한다.

암묵적 이해 방법 • 반복적인 업무를 통한 업무적 호흡이 맞는 사항.• 암묵적 이해가 형성되었더라도, 업무에 대한 책임자를 지정해 업무 누락을 방지 함.

리더십 기술 • QA는 프로젝트의 관리자이면서 조언자이기 때문에 리더십이 매우 중요함.• QA의 필요성을 심어주고, 품질에 대한 인식을 전환시키기 위한 주기적인 교육 역시 QA리더십의 숙제.

5. Game QA의 대화방법

품질과 테스트 중점 QA조직

테스트 엔지니어 공유 조직

QA

QM

QA 리드

테스트 리드

테스터

일반적인 QA조직

기술과 재미 중점 QA조직

QA

QM

QA 리드

테스트 리드

테스터

QA

테크니컬 QA

펀 QA

QA 리드

테스트 리드

테스트 엔지니어

QA

QM 품질계획 QP

테스트 디자인TD

테스터

6. Game QA 조직

QA팀 구성

테스트 엔지니어 테스트를 수행하는 역할. 처음 QA팀 입사 시 맞게 되는 역할

리드 테스트엔지니어

테스트 수행 시 계획에 따라 테스트를 주도하고, 우선순위를 정하는 역할.

테스트 리드 전체 테스트 계획을 세우고, 진행을 관리. 품질을 높이는 방법을 연구.

테스트 매니저 일정, 비용, QA팀 을 관리. 테스트 진행에 대한 방향성을 제시하고 이끔.

분야별 전문가 성능, 보안, 시스템, 리뷰어 등의 각 분야별 전문가.

분석 전문가 게임성, 통계 분석, 재미 연구, 사용성 분석가.

업무 외적인 실무

자산관리 돈과 인력 뿐 아니라 산출물 및 모든 개발 리소스 등을 관리함.

개발지원

• S/W 라이선스 관리 / 개발툴 검토 / 종료 프로젝트의 리소스 열람 권한 관리• 개발 소프트웨어 구매 및 관리(소프트웨어 구매 검토서 기입) - 부록참조

- 구매 검토서 기입 항목[구매부서/제조사/가격/기술지원절차/구매사유/타당성분석/검토결과]

• 소프트웨어 분석 (소프트웨어 분석서 기입) - 부록참조- 소프트웨어 분석서 기입 항목[분석배경/제조사/주요기능/유사기능의S/W와비교/분석결과]

• 소프트웨어 관리 (구매현황표, 소프트웨어 이슈관리)

교육지원 • 전사적 품질관리 및 품질보증을 위해 QA가 실행• STEN, 한국표준 정보망 등이 있음.

7. Game QA 의 구성과 기타 업무

잘못된 인식의 원인

반복적 방법으로 업무 진행

QAer의 능력의 부족

업무 내/외적 능력의 향상

원인에 대한 해결 방안

업무 내적인 기술(Test + S/W공학 + 품질공학)

• Test 지식• 게임 개발 지식(C/Java/C++)• 소프트웨어 공학 지식• 통계학적 지식 (데이터 활용능력)• 게임에 대한 이해와 분석능력

(재미, 영향, 게임성, 버그등)• QA 업무의 문서화

(계획서, 결과서, 분석서)• 끊임없는 공부

업무외적인 기술(협업을 위한 커뮤니케이션)

• 끈기있는 자세• 인내하는 자세• 긍정적인 자세• 새로운 해결 방법의 강구• 꼼꼼하고 섬세함• 논리적이고 명확한 사고

8. Game QA 의 자세와 발전방향

테스트 기본 원칙과테스터의 기본자질

테스트기본원칙

• 테스팅의 시작은 사용자의 동작을 상상하는 것이고,목표는 사용자의 만족도 향상이다.• 중요 기능과 그렇지 않은 기능을 분별하여 기본 기능을 우선으로 테스트하라.

테스터의기본자질

• 테스트 기본 지식 및 분석 능력• 문서화, 의사소통 능력• 열정 및 자기 관리

Ⅲ. 품질보증활동

- 품질보증계획의수립

- 게임개선요소추출

- 형상관리

- 버전관리와빌드정책

계획 수립 시기 마일스톤 CBT OBT 상용화서비스업데이트

필요 산출물1. 단계별 개발 계획서(개발 목표 및 일정이 명시됨)

2. 세부 기획서(기획 설계 문서, 리소스 및 데이터 테이블)

품질보증계획의 절차

개발 목표 및 일정확인

세부기획 확인

품질목표 설정

보증 방법 도출

테스트 계획수립

품질보증 계획서 작성

• 단계별 개발 목표 및 일정 확인• 일정 미 확정 시 예상일정으로 진행 -> 계획서 갱신

• 개발 목표에 맞는 세부 기획을 확인

• 개발 팀과 협의하여 품질목표 설정• S/W 품질 특성을 정량적 측정이 가능하게 설정

• 품질 목표 확인을 위해 정량적 측정방법을 도출

• 품질 목표 확인을 위해 테스트 계획을 수립

• 품질보증 계획서의 필수 항목에 부합하게 작성

1. 품질보증 계획의 수립

FUN QA의 역할• 게임성 검증 및 게임 개선요소 추출을 담당하고 진행함.• 정직하고, 긍정적인 자세가 필요함.• 개발팀을 설득할 수 있는 정확한 데이터를 제공할 수 있어야 함.

P.I.T

정의 게임 콘텐츠의 효과를 사전에 미리 확인하는 테스트

진행과정

검증 포인트추출 및 제안

개발팀과진행여부 상의

테스트계획 수립

테스트 진행

테스트 결과 및개선안 도출

결과 확인및 개선

감성분석

• 컨셉/세계관• 그래픽• 사운드

난이도분석

• 학습성• 레벨 디자인• 스킬/캐릭터• 조작방법

사용성분석

• 접근성• 플레이 편의성• 플레이 간결성• 플레이 효율성

※ 검증포인트의 분류 및 분석항목

• QA팀 : 테스트 진행 계획수립, 인원 선별 등• 개발팀 : 테스트를 위한 제반 작업 진행

감성분석

• 설문조사• 인터뷰• 생리학적 측정• 레퍼런스 조사• 비교조사분석

난이도분석

• 직접관찰테스트• 설문조사• 인터뷰• 생리학적 측정• 레퍼런스 조사• 비교분석조사• 통계적 분석

사용성분석

• 직접관찰테스트• 설문조사• 인터뷰• 생리학적 측정• 레퍼런스 조사• 비교조사 분석• 통계적 분석

※ 항목별 테스트 진행 방법

※ PIT : Product Innovation Test의 약자로 원 뜻은 제품 향상 테스트이지만, 본 문에서는 게임성 검증 테스트를 뜻 함.

2. 게임성 검증 방식

문서적 검증의종류와 진행방식

• 게임비교 조사분석 : 3개 이상의 자사 혹은 타사 게임과의 유사 시스템을 분석함.• 레퍼런스 조사분석 : 논문, 학술지 등의 자료를 대상으로 게임의 시스템을 분석함.

진행방식분석 계획

수립 및 공유분석진행

개발팀과 분석포인트 협의

분석 결과도출 및 공유

직접 관찰 테스트의종류와 진행방식

• 추론 관찰 테스트 : 미리 추론을 세워두고, 추론에 맞게 플레이가 진행되는지 확인하는 테스트.• 특정 상황 테스트 : 시스템 별로 포인트를 잡아 사용자의 플레이 패턴을 확인/검증하는 테스트.• 타임 체크 테스트 : 특정 부분에 대한 소요 시간을 확인할 때 사용하는 테스트.

진행방식

추론 관찰 테스트 특정 상황 테스트 타임 체크 테스트

개발팀과 분석 포인트 협의

개발팀의포인트에 대한 추론

타임 체크 필요부분 확인

특정 상황에 대한시나리오 작성

테스트 계획 수립 (상세 테스트 계획서 작성/공유)

테스트 진행

테스트 결과 도출 및 결과 공유

※ 직접 관찰 테스트 진행 시 유의사항 : 개선사항을 확인할 때는 1차 테스트 참여 인원의 최소 30% 이상을 2차에 참여시켜야 한다.

3. 문서적 검증 방식

일반 설문 조사의정의와 종류

• 포괄적이고, 가벼운 의견 파악을 위한 설문조사• 선호 장르, 이미지 등 개인 성향을 데이터로 활용하기 위해 테스트 없이 진행이 가능• 사전설문과 사후 설문으로 나뉨

테스터의 성향, 게임테스트 이전 검증 사항, 게임 전/후 비교 등사전 설문 조사

테스트 이후 게임에 대한 직접적인 의견을 조사사후 설문 조사

세부 설문 조사의정의와 진행방식

• 전문적인 의견을 받기 위한 설문조사• 항목이 많고, 상세하며, 객관식 위주의 답변을 요함.• 설문이 많으므로 문항당 시간이 오래 걸리지 않는 수준으로 배치하는 것이 중요함.

개발팀과분석포인트 협의

설문 대상선정

설문조사 계획및 세부 항목 작성

상세 테스트계획서 공유

사전 설문조사 진행 테스트 진행 사후 설문조사 진행

테스트 결과 도출 결과 공유

4. 설문 조사 검증 방식

인터뷰의정의와 유의사항

• 테스트 이전이나 이후에 특정 포인트를 확인하기 위해 테스터를 대상으로 진행• 실행방법에 따라 전체, 그룹, 개인 인터뷰로 나눌 수 있음.

개발팀과분석포인트 협의

인터뷰 대상선정

인터뷰시나리오 작성

상세 테스트계획서 공유

도입 인터뷰(Warming-UP)

테마 인터뷰

인터뷰 분석결과 도출

결과 공유

인터뷰의진행방식

• 진행자는 진행하는 프로젝트에 대한 사전 지식이 풍부해야 한다.• 진행자는 참석자들을 통제하여 목적한 정보를 얻을 수 있어야 한다.• 진행자는 참석자들을 통제하여 토의 주제에서 벗어나지 않도록 한다.• 진행자는 적절한 시간분배가 가능해야 한다.

유의사항

5. 인터뷰 검증 방식

6. 데이터 분석 업무

제품 데이터 분석

서비스 데이터 분석

데이터 분석진행과정

제반 준비

• 분석DB구축 기획• 통계시스템 기획• 의견취합 기획

[산출물]데이터분석 기획서

제품 데이터 분석

• 로그/트래킹 코드를 활용한 분석• 게임 콘텐츠 문제 사항 파악• 게임 콘텐츠 이용 현황 분석• 유저 소비패턴 분석• 게임 내 아이템 소비패턴 분석• 매출 현황 분석을 토대로 유료

아이템 소비패턴 분석

PIT 진행

• 작업물을 토대로리서치 진행

• 사용성 테스트기획/진행

[산출물]데이터 정리 문서

PIT 진행분석

• 사용자 관찰• 통계/분석 인터뷰• 로그 분석• 트래킹 코드 분석

[산출물]분석 결과서

유사 장르 사용자 현황 분석

• 사용자 성별, 나이 파악• 사용자 성향 조사[산출물] 계획서, 데이터 정리 문서 , 분석 결과서

유료 아이템 소비 패턴 분석

• 유사 게임의 유료 아이템 소비 패턴 조사

• 경제 밸런스 및 사용자 수요조사

게임 시장 동향 조사 분석

• 경쟁 게임 조사• 장/단점 확인

적용가능 데이터범위 확인

데이터 항목 추출데이터 항목적용 협의

데이터 분석제반 과정

데이터분석과정

분석 계획및 공유

분석 진행 결과도출 및 공유

데이터 분석의팀 간 업무 R&R

개발팀의 책임과 의무

• QA팀과 데이터 검증 항목 협의 및 제반 사항 준비• 항목이 적용된 버전을 QA팀에 전달• 데이터 분석 결과서 확인 후 개선 의견 전달

QA팀의 책임과 의무

• 개발팀과 데이터 검증 항목 협의 및 제반 사항 준비• PIT 혹은 서비스 실시하고 데이터 취합• 데이터 분석 결과서 작성, 개선 사항을 개발팀에 공유

※ R&R (Roll and Responsibility) : 업무를 진행함에 있어, 맡은 책임과 의무.

형상 관리(Configuration Management)

형상의 변경을 기록하고 적절히 제어하여 개발요건에 맞추는 검증작업 (= 변경점 관리)

형상 관리의필요성과 목적

산출물의 체계적인 관리 무절제한 요구사항 통제 유지보수성의 증가

프로젝트의 원활한 통제

개발에 입력된 산출자원의 완전성, 일치성, 정확성의 보장

현재 사용되고 있는형상관리 툴의 개요

SVN : 무료 툴로 커밋 단위로 리비전을 관리함.

GIT : 무료 툴로 로컬에서 커밋과 푸쉬하여 서버에 저장이 가능함.

Perforce : 유료 툴로 속도가 빠르고, 용량을 적게 사용. SVN과 병행사용.

기타 툴 : VSS(NFS방식의 파일공유), ClearClass(기능이 많음), CVS(파일단위의 리비전)

형상관리 툴의 기능

7. 형상 관리의 개요

• 형상식별 : 형상관리의 대상을 구분• 형상통제 : 설정된 기준에 포함되게 통제하는 기능• 형상감사 : 형상 항목의 변경이 제대로 이루어졌는지 무결성을 검토/승인하는 기능.• 형상기록 : 형상의 상태를 기록하고 보고하는 기능.

형상 관리 계획

형상 관리 절차

프로젝트 시작부터 개발의 단계마다 형상 관리 계획을 설정해야 한다.

항목의 식별문서와 코드 : 프로젝트에서 생성되는 모든 리소스(기획서/결과보고서/리뷰/원화/그래픽리소스/사운드리소스/개발툴 등)

형상통제

버전의 식별

자원접근 및 변경권한의 설정 (QA팀에서 서버를 관리)

변경의분석과 통제

이전 버전과의 비교하여 평가 및 변경사항을 분석 (SVN 의 Diff 기능)

형상 상태의기록

완전성(형상항목의 변경에 의한 문제점 미발생)의 유지 = 리비전의 설정

기록양식을 아래처럼 간단하게 구분자를 사용하여 기입(추가 : 기능설명/연관기능, Bugfix : 현상/원인/해결법 기록)

형상 평가• 기획서 및 개발명세서의 리뷰를 통한 평가• 단위 테스트 및 회귀 테스트 등을 통한 바이너리 파일의 평가

※ 바이너리 파일 : binary란 2진수라는 의미로서 바이너리 파일은 0과 1, 즉 2진수로 이루어진 파일을 의미한다

8. 형상 관리 공정 (1/2)

※ 브랜치(Branch) : 개발 중 정기적으로 릴리즈할 때 해당 소스를 따로 저장하기 위한 디렉토리

8. 형상 관리 공정 (2/2)

공표 및 인도진행과정

코드 프리즈(Code Freeze)

메인 트렁크 (= 기본개발 디렉토리)

브랜치(Branch)Code Freezing

브랜치 생성머지(Merge)변경내용 적용

코드 프리즈의 정의

개발팀에 요청 시전달 항목

1) 시행할 리비전 2) 코드프리즈 목적3) 예외적용 및 변경 범위

Test 진행 전, 소스의 무결성을 위해 작업을 중단하는 것

※ 브랜치 관리 절차• 브랜치에서 머지까지의 기간을 최소화한다.• 생성된 브랜치는 최소 1년간 유지한다.

1. 메인 트렁크에서 모든 개발을 완료2. 브랜치 Test 시점을 개발팀에 통보

3. 개발팀에서 리비전브랜치 생성 후Test 서버 구성

4. Bugfix 제외 후브랜치 코드 프리징

5. 회귀테스트 진행(긴급 수정 시 재 배포)

개발 및 기능구현(신규개발)을위한 순환반복

기획데이터

그래픽리소스

프로그램리소스

작업물 취합용 저장소

빌드 무결성 및 통합을 위한코드 프리즈

통합빌드버전이 부여된빌드로 테스트

테스트 보고 /버그 보고

별도의 저장소 사용.버전 번호 혹은 리비전 사용

품질의 향상(안정성 등)을위한 순환반복

통합 작업 마감

사람 혹은 허드슨, 팀 시티, 크루즈 컨트롤 등의툴을 활용한 주기적인 통합이 필요

9. 통합 빌드의 순환

개발 코드 반영개발 코드 반영

주기적 빌드 테스트

통합 테스트

코드 픽스 & 디버그

[개발 Testing & 주기적 빌드]• 개발 Testing• 기능 Testing & Unit Testing

[통합 테스트]• 사용자 배포용 Install File 검증• 클라이언트 서버 포함• Install / Un-Install Test 등

팩&인스톨 버전 공표관리&릴리즈

일정에 따른 진행

10. 빌드 및 배포 버전 정책

※ 배포용 버전 정책 (예시)

[기입시기]• CBT, OBT• 시즌 변경• 대규모 업데이트

[기입시기]• 콘텐츠 추가• 유료아이템 추가/삭제/변경• 이벤트 사항

[기입시기]• 기존사항변경• 보안 프로그램 업데이트• 버그 수정 및 그 외 사항

[기입시기]• 빌드 번호

정기적 품질보고

정의• 품질 최고 책임자(CQO) 및 품질보증 대리인을 주체로 하는 보고.• 주기적이고, 개발부터 서비스까지 전 기간에 걸쳐 공유됨.

• 게임 콘텐츠로서의 제품을 미리 측정해보는 목적의 보고• 정해진 내부 평가기간에 보고. (마일스톤 완료에 따른 단계보고)

보고항목(개발)

• 개발 기술 관련 이슈 공유• 개발 엔진/이슈/동향, 사내이슈, 내부기술발표, 외부분석, 교육 등.• 프로젝트QA 진행현황, 품질문제처리현황, 리스크 진행사항, 기타 등.

보고항목(서비스)

• 고객클레임 : 클레임이슈/처리현황/처리시간• 서비스 품질 관련 : 서비스 및 품질저하 이슈/해킹/매크로/서비스품질• 서비스 패턴 분석 : 문제점 개선목표/개발 중인 프로젝트 반영 사항

비정기적 품질보고

정의

개발QA보고

완성품질목표설정

게임 컨텐츠품질목표설정

기능완성도

신뢰성

플랫폼 관련종합 품질보고서

완성 품질보고서

게임 품질보고서

•일반적인 S/W Test•특성에 따른 기능 Test

•게임성 분석•PIT 진행

11. 품질보고

Ⅳ. 테스팅 활동

- 활동준비사항

- 테스팅프로세스

- 테스팅기법

버그의 정의 게임의 질을 저해하는 요소. 모든 부적절한 오류(오타, 오작동) 및 기대하지 않은 현상.

버그의 등급

Critical

Major

Miner

개선등급

게임 실행이 불가능. 비정상종료. 게임 수익에 불리한 영향.

게임 기능에 중대한 영향을 주지만 게임은 정상적으로 실행이 가능.

게임에 경미한 영향을 주며, 정상적인 플레이에는 영향을 주지 않음.

건의 및 게임을 개선할 수 있는 요소에 대한 제안

버그의 발생빈도

항상 발생

가끔 발생

불규칙적 발생

다시 시도되지 않음

다시 만들 수 없음

재현방법이있는가?

버그 발생시점과환경이 변하였는가?

현재 재현이가능한가?

100%재현이 되는가?

예

아니오

예 예

아니오 아니오

아니오

예

버그의 우선순위(심각도)

즉시(대응 : 긴급 릴리즈)

서버 크래쉬, 해킹, 서비스 진행 불가, 클라이언트 비정상종료

긴급(대응 : 긴급/정기 릴리즈)

높음 / 낮음 / 보통(대응 : 정기 릴리즈)

기능 오작동, 디스플레이적 오류, 오류로 인한 유저 클레임

높음:이용 불편, 오탈자 / 보통:발생빈도가 낮은 오류 / 낮음:텍스쳐오류

※ 동일한 심각도를 가지는 버그의 우선순위 결정 : 발생시기, 고객요구사항, 사용빈도 및 심각도/우선순위 관계 테이블 활용하여 선정.

1. 버그의 정의와 분류

게임버그의 종류

• 인공지능 관련 : 캐릭터의 이동/행동이 예측하는 패턴대로 나타나지 않음. • 물리 관련 : 중력, 충돌 등의 상황이 현실과 다르게 나타나는 현상.

• 디스플레이 오류 : 화면이 까맣게 되고 입력이 불가능하게 되는 현상.• 로딩 오류 : 접속, 맵 이동 중 시스템에서 정지 상황이 발생하는 현상.• 멈춤 현상 : PC 충돌, 메모리 부하 등의 상태로 인해 발생하는 현상.• 데이터 전송 오류 : C - S간의 데이터가 비정상적으로 전송되는 현상.

• 프레임 저하 : 시각에 맞게 영상이 전송되지 않고 끊겨서 보이는 현상.• H/W, S/W 호환성 문제 : 특정 PC에서만 발생하는 일그러짐 현상 등.

• 화면 렉 현상 : 동기화 오류, 일시적 네트워크 장애, 방화벽 충돌 현상.• 보이지 않는 플레이어 : NPC 혹은 PC가 보이지 않는 현상.

• 맵 끼임 현상 : 코너, 상자 사이에 캐릭터가 끼어 이동할 수 없는 현상.• 맵 뚫림 현상 : 충돌박스로 접근되지 않아야 하는 곳에 캐릭터가 접근되는

현상.

• 폴리곤 겹침/중첩 현상 : 폴리곤이 다른 폴리곤을 뚫거나 겹치는 현상.• 텍스쳐누락 현상 : 텍스쳐가 빈 곳을 엔진이 채워진 상태로 인식하는 현상.

• 소리관련 현상 : 소리 끊어짐, 튐, 왜곡, 음향효과 누락, 크기 오류 등.

인공지능과 물리

안정성

퍼포먼스

네트워크

맵 버그

시각적인 오류

소리

2. 버그의 종류

BTS의 정의 테스터와 개발자, 혹은 개발자와 개발자간 커뮤니케이션을 위한 도구.

BTS의 종류

• 멘티스 (무료) : Web기반으로 검색기능이 편리함. 가장 많이 활용되는 툴.• 버그질라 (오픈소스) : Web기반으로 IIS서버가 필요함. 가장 많이 활용되는 툴.• 트랙 (오픈소스) : Subversion을 연동되어 형상관리 툴로 쉽게 버전관리가 가능한 툴.• 지라 (유료/오픈소스) : Bug의 통계 산출이 용이, 이슈에 관한 워크플로우 작성이 가능.

버그생명 주기흐름(Bug Life-Cycle)

등록(Open)

할당(Assign)

해결(Resolve)

확인(Verify)

재발생(Reject)

폐쇄(Close)

• 테스터에 의해 가장 최근에 등록된 것.

• 개발 관리자가 담당자에게 할당.• 빌드 버전/원인/수정내용을 기입

• 해결된 버전에서 보고자가 확인.• 개선버전에서 수정사항을 확인.

• 회귀테스트를 거쳐 수정이 확인되었을 때 폐기.

• 해결/확인된 버그가 다시발생할 때 재발생 상태로변경

• 개발 관리자는 재발생 된버그를 담당자에게 다시할당.

※ 수정하지 않음에 대한 유의사항 : 버그 아님이 너무 많을 경우에는 개발자가 제대로 일을 하고 있는지 한 번쯤 의심해보자!

3. 버그 추적 시스템 (BTS : Bug Tracking System)

버그 리포팅의 정의 발견된 버그를 BTS에 정해진 규정에 맞게 등록하는 것.

버그 리포팅 시주의사항

• 카테고리와 동작에 의해 분류하여 정확히 기록할 것 – 동작에 대한 간단한 메모 필요.• 중복된 버그의 등록 여부에 대하여 확인 – 다른 테스터와의 교류 및 등록된 버그 검색 활용• 적절한 정보를 포함하고, 정보가 확실한지 다시 한번 확인 및 검토한다.• 개발자는 본인의 S/W에 대한 자부심이 강하므로 감정이입이나 과장은 배재해야 한다.

버그 리포팅 항목

요약 버전/버그 현상에 대한 간략한 기재.

버전 발생 당시 버그 기재

테스트 환경 재현이 손쉽게 될 수 있도록 도움.

사전 조건 재현 전, 특수상황을 만들어야 할 때 기재.

재현 방법 짧고 간단하게 누구나 따라 하기 쉽게 기재.

실행 결과 실제 결과로 사실적인 실행 결과만을 기재.

기대 결과정상적으로 수정할 수 있게 정상 값 기재. (기획/기능 명세서에서 확인)

요약 : [9075] XX 상태일 때 XX 키입력 시 덤프 메시지 출력 됨.버전 : 9075테스트 환경 : (OS/CPU/GPU/RAM 등 상세 스펙)

<사전조건>XX 조건의 방 생성 후 풀 방인 상태.

<재현방법>방장 [시작] 버튼 클릭XX 상태일 때, A-Player가 XX키 입력

<실행결과>덤프 메시지 출력 후 클라이언트 종료. (덤프 파일 첨부)<기대결과>XX키 입력 실행됨.

4. 버그 리포팅

※ 버그 리포팅 작성 예

※ 모듈 (Module) : 독립되어 있는 하나의 소프트웨어 또는 하드웨어 단위를 지칭.

V – 모델다이어그램

요구사항 분석

시스템 설계

아키텍쳐 설계

모듈설계

코딩

인수 테스팅

시스템 테스팅

통합 테스팅

단위 테스팅

증명

검증

정적 활동인 워크쓰루와인스펙션으로 오류 증명

동적 활동인 인수/시스템/통합/단위테스팅으로 오류검증

요구사항분석

시스템 설계

아키텍쳐 설계

모듈 설계

사용자 요구사항

시스템 요구사항(기능명세+비기능명세)

상세명세서 인수 테스팅

문서화 타당성 분석• 시나리오 기반• 잠재적 문제 검증

시스템(통합) 테스팅기능/보안/호환/네트워크 등 시스템 전반적 사항 테스팅

모듈 통합으로 인한 모듈 간 상호작용 테스팅(디버깅 환경이 구축되어야 함.) 통합 테스팅

단위 테스팅입력 변수에 따른 루틴의 호출, 클래스, 함수, 메소드등을 검증하는 단계

5. V-Model (검증 강조형 모델)

기획/명세서리뷰작성 목적

테스트를 진행하기 전 문서 상의 오류를 찾는 것이 목적.

기획/명세서 리뷰검토 항목

검토항목 설명

명세 부족

조건 불일치

건의

문의 사항

규칙, 조건, 예외 처리에 대한 상세 명세가 부족한지 검토.

흐름상 오류 및 정의된 조건과의 불일치를 검토.

고려사항 및 사용상 추가적인 건의사항이 발생시 기술

문서 상으로 이해되지 않는 부분에 대한 질의

리뷰 회의 기법[워크쓰루&인스펙션]

• 비공식적 Review 기법. 진행 전에 질문서/오류명세서를 작성.• 목적 : S/W의 예상 결점과 UI를 검토• 진행 : Preparation (질문서, 오류명세서)->Analysis(분석 결과 문서)• 참석자 : 실무자, 책임자, 다음 책임자, 의뢰인 대표, SQA Group

워크쓰루[Walk Through]

• 공식적인 Review기법. 진행 전에 검토항목에 대한 체크리스트를 준비.• 목적 : 버그 발견을 주 목적으로 함.• 대상 : 요구사항문서, 설계문서, 코드를 대상으로 함.• 참석자 : 리더(중재자), 기록자, 개발자, 검토자, 관리자 (5인 구성)

인스펙션[Inspection]

6. 기획, 명세서 리뷰 작성 및 리뷰 기법

이벤트 대기 착지점프 (정상바위, 금간 바위) 착지 착지충돌 (상대와 충돌, 돌과 충돌) 추락 추락점프 (점프거리<바위간의 간격) 추락 추락떨어짐 (금간 바위에서 떨어짐) 추락떨어짐 (경사 바위에서 미끄러짐) 추락도착 (도착점 도착) 도착

Test Case와Check List의 정의

Test Case

• 모든 동작을 세분화하고 나눠서 검증하는 데이터• 개발 단계에 따라 작성하는 범위가 달라짐

- 개발 초기 : 단위 모듈을 기반으로 작성- 개발 중기 이후 : 모듈 간 연동을 고려하여 작성

• 상태 전이 테스팅, 결정 테이블 테스팅, 동등 분할, 경계값 분석, 조합 테스팅

Check List

• Tset Case 를 함축시켜 놓은 카테고리• 주 기능에 부 기능의 점검까지 내포하는 형태.

- 상위 기능 부터 단위 기능까지 포함 (그룹핑)- 기능 분류 및 범위 명시 필요

상태 - 전이 테스팅다이어그램

대기 상태추락

(Game Over)

착지도착점

Ev 점프/점프 거리<바위간의 간격()Ev 충돌 / 상대와 충돌(), 떨어지는 돌과 충돌()

Ev 점프 [정상바위, 금 간 바위]

Ev 도착[도착점 도착]

Ev 점프 [정상바위, 금 간 바위]

Ev 떨어짐 / 금 간 바위, 떨어짐()/ 경사바위, 미끄러짐()

Ev 점프 / 점프거리<바위 간의 간격()Ev 충돌 / 상대와 충돌()

/ 떨어지는 돌과 충돌()

7. Test Case와 Check List

상태 – 이벤트테이블

번호 범위 사전조건 동작 기대 결과 실행결과 상태특이사항

시스템 분류

기능 분류

ST-PR-001채팅 창 이용으로파티 초대 팝업 확인

1. 본인이 파티장2. 다른 PC2 가 파티없는 상태

1. 입력 창에 '/파티 (PC2 캐릭터명)' 입력초대받은 클라이언트에파티 초대 창이 팝업됨

초대 받은 클라이언트에아무런 창이 팝업되지 않음

실패 (Fail) -

번호 범위 동작 동작 결과 상태 특이사항

시스템 분류

기능 분류

ST-PR-001 파티 초대 확인 파티가 없는 상대에게 파티 초대가 이루어지는지 확인 - 성공 (PASS) -

항목별 부가설명

※ Test Case 작성 예

1. 번호 : 어떤 프로젝트의 T/C 인지 식별할 수 있게 내부 기준에 맞게 코드를 부여.2. 범위 : 해당 케이스의 구체적인 범위, 기대 결과의 범위를 활용하여 작성 (초대 팝업 창)3. 사전 조건 : 케이스 수행 전에 만족되어야 하는 조건을 명시, 7단계 이하로 작성4. 동작 : 재현 스텝, 최소한의 단위(모듈)로 나눠 기술, 테스터의 동작을 기준으로 작성5. 기대결과 : 동작 수행 후의 정상적인 기대 값, 기획서/기능 명세서를 분석해야 확인가능.6. 실행/동작 결과 : 수행 시 기대결과와 다른 값이 나왔을 때 그 결과 값을 사실대로 기재.7. 상태 : 결과값과 일치하면 정상(Pass)으로 표시, 다른 값이라면 실패(Fail)로 표시.

※ Check List 작성 예

8. Test Case와 Check List 작성방법

기능 테스트

분 류

통합(기능) 테스트

Ad-Hoc 테스트

회귀 테스트

밸런스 테스트

시스템 테스트

호환성 테스트(OS, H/W, S/W, Network)

성능 테스트(Server, Client, Network, 보안)

서비스 테스트

인증(로그인) 테스트

웹 스타트 테스트

빌링 테스트

게임 로그 테스트

GM Tool 테스트

통합(기능) 테스트

입력물 산출물

• 기능 명세서(개발팀)

• 릴리즈 노트(개발팀)

• 테스트 계획서(QA)• 기능 명세 리뷰서(QA)• 테스트케이스와 리뷰서(QA)• 테스트 결과 보고서(QA)

• 버그 리스트(QA)

• 테스트 계획서(QA)• 테스트 결과보고서(QA)

• 테스트 계획서(QA)• 체크리스트(QA)• 테스트 결과 보고서(QA)

• 버그 리스트(QA)• 릴리즈 노트(개발팀)

• 상세협의(QA-개발팀)

• 시스템 정보(개발팀)• 상세협의(QA-개발팀)

9. 게임 테스트 산출물

※ Ad-Hoc 테스트 : Adhocracy Test의 약자로 특정 계획이나 규칙을 두지 않고, 플레이 및 유저의 관점에서 진행하는 테스트

테스트 프로세스 계획 및 준비 수행결과

분석 및 개선

테스트 계획 항목

테스트 진행 도구및 제반 사항

목적

범위

테스트 수행조건

테스트 종료조건

테스트케이스

테스트 환경

테스트 방법

테스트 일정

테스트 인원

버그 보고

결과 도출

테스트를 진행하는 목적을 정의.

테스트의 범위를 설정.

최소한의 환경 조건의 기준을 정의. (기능 구현 정도 / 서버다운의 정도)

테스트 종료 기준을 정의. (만족여부/계획된 절차/기간 or 횟수의 기준)

Test Case/ Check List 의 준비. 기타 테스트 범위에 대한 정보 습득.

테스트 특성에 맞는 물리적 환경 구성의 정의.

어떤 테스트를 어떤 방법으로 진행할지에 대한 정의.

테스트에 소요되는 일정 및 인원을 구체적으로 정의.

테스트에 참여하는 인원과 역할에 대한 정의.

테스트 진행 중 발생한 버그의 전달 및 처리 절차에 대한 정의.

테스트 종료 후 결과에 대한 산출물을 정의.

개발자와의 협의

• 일정, 빌드주기, BTS에 대한 이해 협의.

• 추 후 개발로 인한 테스트 일정 지연 방지.

기획/명세서 리뷰

• 기획 산출물 리뷰• 오류, 기술적 구현, 예

외처리 등.• 결과를 개발팀과 공유.

Test Case 작성• 리뷰 후 기능/ 컨텐츠

단위로 T/C 작성.• 개발팀과 문서 공유.• 개발팀의 중점사항에

대하여 협의.

테스트 환경 구축• 효율적인 테스트를 진

행하기 위해 구축.• 특성에 따라 개발팀

및 유관부서의 지원을받음.

10. 테스트 계획 프로세스

테스트 프로세스 계획 및 준비 수행결과

분석 및 개선

필수 수행 항목

버전 릴리즈• 개발팀이 QA팀에 변경 이력서

제출• 빌드의 변경에 따라 T/C 수정.

테스트 수행

• 빌드 버전이 나오면 Test Case, Check List에 따라 테스트수행.

버그 보고• 수행 중 발생 버그를 BTS 에

등록.• 발견부터 대응까지 이력관리.

버그 보고 항목

버그 분류 프로젝트에 적합한 버그 분류를 선택

단계 버그가 발생한 개발 단계

심각도 버그에 의한 파급 범위의 경/중으로 판단.

우선순위 발생 버그의 대응 우선순위

발생 빈도 버그가 발생하는 빈도를 체크하여 재현율을 알려줌.

테스트 환경정보 버그 발생시 PC 및 네트워크 환경 정보

빌드(버전)정보 버그가 발생한 버전 정보

버그 요약 문제 현상의 요약 설명

버그 현상 설명 문제를 재발시키는 재현 방법, 실행 결과, 기대 결과를 설명.

최종 리뷰 항목버그 리뷰

이슈 공유

• 버그의 중복을 피하고 테스트 리드가 현재 어느 정도 버그가 나오고 있는지 파악하기 위한 리뷰. 테스트 최종 종료 전까지 주기 별로 진행 및 관리

• 테스트 진행 중, 개발팀과 정기적인 회의를 통한 이슈를 공유.• 중요 테스트 중 릴리즈 버전의 변경 방지 및 이슈에 대한 공유.

11. 테스트 수행 프로세스

테스트 프로세스 계획 및 준비 수행결과

분석 및 개선

결과 분석 및 개선단계의 업무

테스트 결과 도출

• Test Case 또는Check List의 결과를취합하여 결과 보고서작성.

• 보고된 버그와 실패율을 통해 현 버전의안정성을 도출.

개발팀 및 관련자 공유

• 결과 보고서는 개발팀및 관련자에 모두 공유 되야 함.

• 현재 상황을 인지하고개선방향을 논의.

결과분석 개선안도출

• 개발팀과 QA팀은 결과 보고서를 분석하여개선이 필요한 부분에대한 안을 도출하고, 추후계획설립

12. 테스트 결과 및 분석 프로세스

13. 기능 테스트 (1/2)

단위 (기능) 테스트흐름 및 산출물

기획서/기능명세서

리뷰 기능 명세 리뷰서

테스트케이스

리뷰테스트케이스

리뷰서

테스트 테스트 결과 보고서

통합(기능) 테스트흐름 및 산출물

릴리즈 노트(패치 노트)

테스트필요항목 검토

테스트 계획서 리뷰테스트 계획서

리뷰서

테스트 실시

기획서/기능명세서단위 기능테스트단위 기능테스트단위 기능테스트

회귀 테스트 리스트 회귀 테스트

버그 리스트

테스트 결과 보고서

개발팀공유 및 평가 적용

※ 릴리즈 노트 : 개발팀에서 개발된 사항에 대한 추가/변경/수정 사항 등을 간략하게 기록하여 정리한 노트.

Ad-Hoc 테스트방법 및 산출물

회귀 테스트흐름 및 산출물

[테스트 수행] 사용자 관점으로 다양한 패턴을 만들어 버그를 찾음. 타 테스트와 병행하여 시행[버그 리스트] 테스트 중 발생한 버그를 BTS에 등록하여 개발팀과 공유 (산출물 : 버그 리스트)

과거에 발생한 버그의 재 발생 여부 확인.

릴리즈 노트(패치 노트)

버그 리스트

회귀테스트대상리스트

리뷰테스트

필요항목 검토

테스트 수행테스트 결과

보고서

밸런스 테스트흐름 및 산출물

유저 행동 패턴을 확인하여 기획의도에 일치하는 지 확인.

기획서/기능 명세서

테스트 계획서

리뷰테스트 계획서

리뷰서

체크리스트

테스트필요항목 검토

테스트테스트 결과

보고서

개발팀공유 및 평가 적용

기타 테스트

• 동선 테스트 : 유저가 이용하는 동선을 중심으로 기획과 부합하는 지 분석 (= 레벨 테스트)• 성장 테스트 : 플레이 시간에 따른 캐릭터의 성장속도를 확인하는데 사용.• 맵 난이도 테스트 : 맵의 난이도, 소요시간, 몬스터의 레벨/양, 사망지점, 체감도 등.• 아이템 상성 테스트 : 유저가 얻는 아이템들의 상성을 조사. 유료 아이템 차별화, 기능중복 예방.

13. 기능 테스트 (2/2)

시스템 테스트흐름 및 산출물

소프트웨어 자체에 대한 성능을 측정/평가하여 완성도를 높이는 것.

시스템 정보

테스트 계획서

리뷰테스트 계획서

리뷰서

개발 - QA팀 협의

체크리스트 테스트테스트 결과

보고서

개발팀공유 및 평가적용

게임 툴 지원

시스템 테스트의종류

호환성테스트

성능테스트 • 서버 성능 테스트 : 서버에 인위적 스트레스를 가해 성능 임계 및 안정성 확인.(개발팀 지원)

• 클라이언트 성능 테스트 : Client S/W가 점유하는 CPU, 메모리 등을 확인. (PC사양 책정)• Network 성능 테스트 : 환경을 인위적으로 조작하여, S-C/C-C 간 통신 부하 임계치 확인

• OS 호환성 테스트 : 여러 OS에서 실행/설치/삭제가 되는 지 확인. (언어별 OS도 확인)• H/W 호환성 테스트 : VGA, 사운드, 입력장치 등에 대한 호환성을 확인.• S/W 호환성 테스트 : 보안 툴, 백신, 메신저 등과의 충돌 여부 및 대중적 S/W와도 확인.• Network 호환성 테스트 : 여러 회선(내부/외부 회선)에서의 정상적인 동작 확인.

개발된 게임이 다양한 유저의 물리적 환경에 부합되는지를 테스트.

서버/클라이언트의 성능을 측정하는 테스트.

14. 시스템 테스트

15. 서비스 관련 테스트

서비스 테스트

S/W의 성능과는 별개로 서비스하기 위해 확인해야 하는 테스트.

퍼블리싱 테스트

인증(로그인) 테스트

런처 테스트

빌링 테스트

패치 테스트

로컬라이즈 테스트

실제 상황과 동일한 하게 로그인이 되는가 확인. 유저 별 권한 확인.

실행 시 런처가 정상 작동하는 것, 다른 S/W와의 충돌여부도 같이 확인

수익 모델에 따른 유료 아이템의 구매 등이 정상적인지 확인.

정상적으로 패치 되었는지 확인, 검증된 버전이 업로드 되었는지 점검.

문법, 오타, 표기법, 문화적/법적 차이에 대한 고려

사전 준비 사항

계획 및 협의 단계

개발 단계

검증 단계

제품적용 단계

조직체제구축,역할분담,계약사항협의,테스트 환경 구축/업무 프로세스 협의

1. 제품개발 계획 작성(개발내용, 일정, 범위)

산출물 제출 (게임 리소스, 제품, 설계문서, 릴리즈 노트, 기획서, 버그 리스트)

퍼블리셔에서 진행

2. 품질보증 계획 작성(품질목표, 품질보증범위, 일정, 위험대책 명시)

개발제품검증

기획서리뷰

대응버그확인

기능,성능테스트

기준적합측정