[실전 포트폴리오 No.1] 이론 기반 소프트웨어 테스트 계획서 작성법

테스트 계획서 작성하기(마이피플.apk)

NOTICE

본 문서의 내용은 LQDQ사의 자산으로 개인의 동의 없이 배포 또는 복사할 수 없습니다. 아래 모든 내용은 App의 Spec 문서 없이 저의 임의대로 작성 되었음을 알려 드립니다.

 

본 문서를 샘플로 사용하셔도 무방합니다.

Copyright© 2020 LQDQ All Rights Reserved.

 

문서 변경 이력(가정)

날짜	작성자	버전	내용
	이정민	Ver. 0.0	Mypeople 테스트 계획서.
	홍길동	Ver. 0.1
	김철수	Ver. 0.2
	김철수	Ver. 1.1	김영희 수석에게 최종 리뷰를 맡기기 위한 전체 검토 / 용어 뒷부분으로 이동 .
	김영희	Ver. 2.1	전체적인 Review 테스트(주요 변경 내용: 테스트 절차 추가 , 결함관리 및 결함유형 추가 , 테스트관리 항목 추가 )
	김철수	Ver. 2.2	전체 검토(내용간 불일치성 제거, 내용 순서 수정)
	김철수	Ver 2.3.0	업계 전문가로부터의 피드백 반영

 

테스트 계획 승인(가정)

승인자	이름 및 서명	승인 날짜
테스트 리더	이정민 팀장
개발 리더	배철수 팀장
테스트 팀장	김영희 팀장
개발 팀장	김철수 팀장
프로젝트 관리자	홍길동 팀장

 

1. 개요

1.1. 범위(Scope)

1.1.1. 테스트 대상 어플리케이션

어플리케이션 테스트의 대상은 다음과 같다.

 

“마이피플 – 내사람들”: Ver. 2.3.1

 

- 무료 음성 & 영상통화(Beta)/무료 메시지

3G, Wi-Fi 데이터 망을 이용하여 친구들과 무료로 통화하고 문자를 나눔 ü 음성/영상 통화 모두 지원

ü 마이피플 음성통화(mVoIP)기능은 통신사 정책상 데이터 무제한 요금제에 가입되어 있지 않은 경우 차단 될 수 있음

 

- 언제 어디서나 편리하게 이용

ü 스마트폰 전용앱

ü PC 브라우저

ü 크롬앱 어플리케이션

ü 원하는 곳 어디든 자유롭게 이용

 

- 원하는 스타일의 화면도 내 마음대로

ü 다양한 스킨

ü 독특한 벨소리

ü 내 마음대로 내 스타일대로 마이피플 꾸미기

 

1.1.2. 테스트 항목

- 마이피플.App 테스트의 항목은 다음과 같다.

- 마이피플 기능에 대한 원활한 동작에 대한 기대결과를 충족

- 요구사항에 명시된 성능 충족(동시 사용자 고려) 확인

- 사용자 평가원칙(Heuristic Evaluation)에 준하여 사용성 평가

- 실 사용 환경과 유사한 테스트 환경에서의 정상적인 기능 보장

- OS별 환경에서의 호환

 

마이피플.App 테스트에서 제외되는 항목(Item not to be tested)은 다음과 같다

- 타 어플리케이션(카카오톡, 트위터, 유투브 등)과의 연계성

- 다양한 입력 데이터의 허용성

- 신체 장애자 접근성

 

1.2. 목적(Objectives)

마이피플.App의 목적은 언제 어디서나 친구들과 즐기는 무료 메시지, 무료 통화의 즐거움, Daum 마이피플.App 하나면 편리한 커뮤니케이션의 시작을 하기 위함이다.

- 기대결과 및 실제결과 간 차이점 보고

- 마이피플.App가 요구사항에 적합한지에 대한 결정

- 상품화 가능한 수준의 사용성 및 성능 확보

- 소셜네트워크 기능으로써의 자리매김

 

1.3. 전제조건(내부)(Preconditions(internal))

마이피플.App 테스트 수행을 위하여 테스트 팀은 다음의 전제 조건이 필요하다.

- 테스트 실행은 테스트 대상이 성공적으로 테스트 시작 조건(Entry criteria)을 만족할 때 시작함

- 주요 기능(Main Functions)의 정상 동작 여부(주요 기능 체크리스트 기준)

- 요구명세(Requirement Specification)의 테스트 용이성(Testability) 평가(테스트 용이성 평가 체크리스트 기준)

- (선택적) 단위 및 통합 테스트 결과(리스크 레벨에 따른 코드 레벨의 커버리지 측정치기준)

- 선행 테스트 단계에서 발견된 겸함의 80%이상 조치 완료

- 요구명세는 테스트 시작 한달 전 테스팅 팀에 공식적으로 전달되어야 함

- 테스트 시작 조건은 시작일까지 충족되어야 함

- 테스트 베이시스(Test basis) 또는 테스트 대상(Test object)의 인도 지연은 테스트 관 리자에게 즉시 보고되어야 함

- 테스트에 필요한 모든 필수적인 툴과 테스트 환경 등의 테스트 기반구조는 테스트 실행 동안 가용해야 함.

- 테스트 베이시스 상의 변경은 테스트 관리자에게 즉시 전달되어야 함

 

- 테스트 중단 조건

ü 테스트 대상 빌드에서 사전에 발견된 결함의 70% 이상이 조치되지 않음

ü 리그레션 결함으로 인해 마이피플.App의 주요 기능이 정상 동작하지 않음

ü (선택적) 단위/통합 테스트 결과가 리포팅 내용과 불일치함

 

- 테스트 재개 조건

ü 테스트 중단 사유가 해결됨

ü 타 부서의 긴급한 테스트 요청 사항이 있을 경우, 해당 테스트의 한계성을 인정한 범위 내에서 사안을 감안하여 제한적인 테스트 수행

 

1.4. 문서 승인(Approval Authority)

테스크	담당자
테스트 계획서 작성	테스트 매니저, 테스트 리더
테스트 계획서 리뷰	PM, QA 리더, 개발 리더
테스트 계획서 승인	프로젝트 PM

 

2. 테스트 베이시스(Test basis)

마이피플.App 테스트 단계의 테스트 베이시스는 다음과 같다.

1. 마이피플.App 요구 명세서(마이피플.App Requirement specifications)

- 마이피플.App 각 기능 및 비기능적 요소에 대한 요구사항

 

2. 과년 기준 또는 표준(Standards)

- 테스트 대상(마이피플.App) 제품 개발을 위한 내부 표준

- 테스트 프로세스 및 방법론 기준 – ISTQB 지식체계 근간

 

3. 설계 명세서(Design specifications)

- 마이피플.App의 아키텍처(Project plans)

- 마이피플.App 설계 기준 및 상세 설계 내용

 

4. 프로젝트 계획서(Project plans)

- 마이피플.App 구축 프로젝트 계획서

 

 

3. 테스트 전략(Test strategy)

테스트 전략을 기능(Functional) 테스팅 전략과 비기능(Non-functional) 테스팅 전략으로 구분하여 수립한다.

※ 기능 테스팅 전략 수립에 비기능성을 반영하여 한가지로 전략을 수립할 수도 잇다. 반대로 품 질 특성(Quality characteristics)에 기능성이 포함되어 있으므로 비기능 테스팅 전략에 기능성을 포 함시켜 한가지로 전략을 수립할 수도 있다.

 

※ 단위 테스팅 또는 통합 테스팅 레벨에서 테스트 전략을 수립하였을 경우, 이를 감안하여 중복 을 최소화하고 제한된 시간과 인력으로 최대의 효과를 볼 수 있는 테스트 전략을 수립한다.

 

리스크 분석에 근거한 테스트 전략 수립의 목적과 의도는 아래와 같다.

테스트 리소스와 노력의 합리적 분배 – 테스트에 투입되는 리소스와 노력을 합의된 리스크 레벨에 따라 차별적이고 현명하게 분배 한다.

 

테스트 진행의 투명성 확보 및 제공 – 리스크 합의 과정에서 테스트의 중요성에 대해 이 해관계자(개발 관련자 및 사용자, 마케팅 및 기술지원 관련자 등) 들에게 주지시키고 어 떻게 테스팅이 진행될 것인지에 대해 제시한다.

 

경영층의 테스팅과 품질에 대한 예측 및 이해 증진 – 리스크 관리 측면에서의 테스팅으 로 (최고) 경영층이 테스팅을 이해하고 소프트웨어 시스템 개발의 진행과 최종 결과물의 품질과 리스크를 예측할 수 있도록 의사소통하고 정보를 제공한다.

 

3.1 기능 테스팅 전략

마이피플.App은 다른 테스트 레벨에서와 마찬가지로 리스크 기반 테스팅을 전제로 테스트의 강도 및 우선 순위를 조절하여 수행한다. 리스크 영역을 STA(Severs Test Area), STTA(Strong Test Area), ITA(Intensive Test Area), FTA(Fundamental Test Area)의 4개의 구역으로 구분하고 각각의 영역별 차별적으로 테스트 한다.

 

3.1.1. 리스크 분석

리스크 분석은 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석하여 테스트의 우선 순위를 결정하는데 활용한다. 리스크는 아래와 같은 공식으로 표현되며 리스크 분석을 위한 리스크 요소(Risk factor)는 다음과 같은 것을 사용하였다.

- 리스크(Risk) = 장애 발생 가능성(Likelihood) * 장애로 인한 영향(Impact)

- 리스크 요소 – 장애 발생 가능성(Likelihood)

- 복잡성(Complexity)

- 새로운 개발의 정도(기존에 개발된 것의 재사용 수준)

- 상호관계(Interrelationship, 인터페이스 개수)

- 크기

- 사용된 기술의 난이도/최신성

- 개발팀의 경험 미흡

- 개발 및 사용자 조직과의 의사소통

- 리스크 요소 – 장애로 인한 영향(Impact)

- 사용자에 의한 취급 중요도(잘 팔리는 아이템)

- 경제적, 안전적, 회사 이미지적 피해

- 사용 강도(Usage intensity)

- 외부적 가시성

 

3.1.2. 리스크 테이블(Risk Table) - ( 가정)

 

리스크 테이블

3.1.3. 리스크 매트릭스(Risk Matrix) – ( 가정)

개발 테스팅에 집중 장애발생 가능성

 

리스크 매트릭스

- STA(Severs Test Area): 반드시 테스트 해야 함

- STTA(Strong Test Area): 테스트 해야 함

- ITA(Intensive Test Area): 테스트 함

- FTA(Fundamental Test Area): 테스트하지 않을 수 있음

 

리스크 매트릭스의 STA에 해당하는 부분은 우선적으로 주어진 시간과 자원을 고려하여, 공식적인 기법을 적용한 강력한 테스팅을 진행 해야 하고, FTA에 해당하는 부분의 경우 자유롭게 시간이 허용하는 범위에서 테스팅을 진행하면 됨

 

3.2. 비기능 테스팅 전략

품질 특성의 상대적 중요성 – (가정)

품질 특성(Quality characteristics)	상대적 중요성(%)(Relative importance(%))
사용성(Usability)	37
신뢰성(Reliability)	13
유지보수성(Maintainability)	20
이식성(Portability)	15
효율성(Efficiency)	15
합계	100

※ 보안성 관련 테스팅은 본 비기능 테스팅에서 다루지 않고 별도의 테스팅으로 분류하여 보안성 테스팅 전문 업체에 맡기고자 한다. (보안성 테스팅 외주 계획서_0000_000000_Ver.0.0 문서 참고)

 

3.2.1. 비기능 테스팅 리스크 분석(전략 매트릭스(Strategy matrix) 생성)

분류명	내용
프로젝트관리	프로젝트(타입) 및 사용자의 추가, 삭제 및 전급 권한을 부여
요구사항관리	대상 소프트웨어 제품의 요구사항 입력 및 리스크 아이템, 테스트 케이스와 연계관리
테스트전략관리	도출된 리스크 아이템에 대한 리스크 분석 및 우선순위 제시, 참여자간 리스크 협의 도출괸 리스크를 최대한 커버할 수 있는 리스크 레벨 별 테스팅 접근법을 제공 리스크 레벨 별로 테스팅을 차별적으로 접근하도록 관련 항목을 추가, 검색, 수정, 삭제 함
테스트 설계 관리	리스크 분석 후, 각 레벨에 적용 가능한 테스트 설계 기법 선택 및 관리
테스트 케이스 관리	리스크 아이템에 대한 테스트케이스를 생성, 검색, 수정, 삭제함
결함관리	결함 리포트를 생성, 검색, 수정, 삭제 및 리스트를 확인함(결함 수명주기 관리)
리포팅	기록된 내용을 근거로 리포트를 자동으로 생성
시작페이지	프로젝트 전체일정 및 세부일정 관리, 최근 참여 프로젝트 및 기타 참여자 개개인이 해야 할 업무에 대한 관리

3.2.2. 비기능 테스팅 전략 수립

특성 테스팅 기법을 활용하여 리스크 및 상대적인 중요도가 높은 부분 기능군과 품질 특성의 조 합에 대해서는 다양한 매트릭(Metrics)을 활용하여 테스트 케이스를 생성한다.

 

또한 해당 부분 기 능군의 리스크와 중요도가 높은 부분은 차터(Charter)를 상대적으로 많이 만들어 테스팅의 강도를 조정해 가며 탐색적 테스팅(Exploratory testing)을 수행한다.

 

리스크와 중요도가 높은 부분은 경험 적인 테스트 케이스도 상대적으로 다수 작성한다. 특정 테스팅 기법 적용 또는 차터 작성시 필요한 매트릭은 ISO/IEC 9126 품질 모델 : ‘소프트웨어 공학 – 소프트웨어 제품 품질’ 국제 표준을 참 고한다.

 

3.3. 투입될 노력 추정(Effort Estimation, 테스팅 규모 산정) – ( 가정)

투입될 공수 산정

 

별첨. 참고 문헌

1. 권원일, 이공선, 임준섭, “개발자도 알아야할 소프트웨어 테스팅 용어”, ㈜STA테스팅컨설팅, 2007

2. 권원일 외, “개발자도 알아야할 소프트웨어 테스팅 실무”, ㈜STA테스팅컨설팅, 2006

3. 김익환, 전규현, “ 소프트웨어 개발의 모든 것” , 페가수스, 2010

 

 

테스트 계획서 대표 이미지

요약 : 애자일 프로세스, 배포 프로세스, 프로세스, 업무 프로세스 관리, 프로세스 마이닝, web site test, 웹 qa, test web, 넥슨 qa, 앱 qa, 소프트웨어 qa