소프트웨어 테스트 시작 - 테스트 계획서 작성하기 Part 1

지금까지는 테스터와 QA의 업무에 대해 다루었다

이제부터는 테스트를 어떻게 계획하고 요구사항을 어떻게 분석하고 테스트를 수행하는데 있어 어떤식으로 문서를 작성해야하는지 정리하려고 한다

소프트웨어 테스팅은 소프트웨어의 결함이 있는지를 발견하는 행동이지만 소프트웨어의 결함이 없다는 것을 증명하는 사실이 아니다.

QA의 업무 중 일부는 테스트 계획 설계부터 테스트 수행단계까지의 일련의 보고서와 문서의 작성이 50%를 차지한다.

---

우선 테스트 일정을 산출하기에 앞에서 테스트의 과정을 알고 가야한다.

테스트의 과정은 테스트 설계 > 테스트 분석 > 테스트 디자인 >테스트 설계 > 테스트 수행 순으로 테스트기 이루어지며 

테스트가 완료가 되면 시점을 QA Sign-off라고 한다 .

테스트의 단계는 5단계이지만 테스트 수행에 구현을 같이 포함시켰다

신입 주니어의 QA 엔지니어 중에서 테스트 결과서나 테스트 계획서를 작성해보지 않은 경험이 있을 수 도 있을 수도 있다.

테스트를 수행하기 전, 테스트 케이스를 작성하기 전에 반드시 시행해야 하는 단계가 테스트 일정 산출과 테스트 분석 단계이다.

또한 입사 사전 과제로 테스트 계획서 또는 테스트 결과보고서가 과제로 수행이 되는 경우가 많다.

테스트 산출과 계획이어야말고 QA에 있어 가장 큰 업무이다.

필자의 경우 2년의 경험이 있는 1인QA  프리렌서이지만.  용역보고서 및 테스트를 혼자 진행하면서 보고서까지 고객사에 제출한 경험을 토대로 QA의 업무에 있어 과정을 다시 정리해보려고 한다. 

우선 테스트 계획서는 테스트 목적과 테스트에 필요한 리소스(단말,인력)과 테스트에 소요예상되는 리스크를 모두 담아야 한다.

테스트를 왜 하는지 , 이 테스트가 통과되려면 어떤 기준으로 하는지, 테스트는 누가 할 것인지 , 테스트 문서는 어떻게 관리하였는지

테스트 리스크는 어떻게 관리 할 것인지에 대해서 최대한 상세하게 다르는 문서로 단순한 테스트 케이스 작성보다 고도화된 문서이므로

메뉴얼적인 테스터들이 이 문서를 작성할 일은 어쩌다가 있다.

테스트 계획 설계는  테스트 숙련도 평가 모델 TMMi(Test Maturity Model Integration)을 기반으로 작성하였다.

 

TMMi의 5단계 

Level1 초기(Initial)	테스팅이 정의되지 않음 테스팅과 디버깅을 한 부분으로 인식 테스트는 조직원의 능력과 자신감에 의존
Level2 관리(Managed)	테스트와 디버깅이 구분 결함 발견 활동의 집중 테스트가 SDLC에서 하나의 독립된 단계로 정의 테스트 정책을 문서화하거나 정책의 일부분으로 정의 전략·접근법 근거하여 테스팅 고 있다는 것을 증명	테스트 정책과 전략 테스트 계획 테스트 모니터링 및 제어 테스트 설계 및 수행 테스트 환경
Level3 정의(Defined)	테스팅이 개발생명주기와 통합되는 단계 별도의 테스트 전담조직 보유 조직차원에서 테스팅을 내재화	테스트 조직 테스트교육/훈련 프로그램 테스트 수명주기와 통합 비기능 테스팅 동료 검토
Level4 관리&측정(Management & Measurement)	동료 검토 활동 수행 요구사항 분석 단계부터 예방적 테스팅 테스트를 관리하고 측정하는 단계 메트릭을 이용한 테스트 수치화, 정량화	테스트 측정 소프트웨어 품질 평가 발전된 동료 검토
Level5 최적화(Optimization)	결함 예방과 품질제어 활동에 초점 테스트 프로세스가 정의·관리되며, 비용과 효과 모니터링 테스트 프로세스가 지속적으로 개선·조정 활동이 통계적 방법과 다양한 평가 기준에 의해 측정	결함 예방 테스트 프로세스 최적화 품질제어

 

---

본 테스트 계획서는 필자(지스)가  신입 저연차 QA엔지니어에게 역량을 키워주고 발전시키기 위해 테스트 계획서를 작성가이드를 공유하기 위해 공유하는 것으로 외부 공유 시 사전문의 부탁드립니다. 

지스의 동의 없이 배포 또는 복사, 배포를 금지하며, 공부목적 이외 사용시 반드시 사전 문의 하시기 바랍니다.

 테스트 계획서는 먼저 업체명(프로젝트명) / 문서명 / 담당자를 구별하고 문서를 시작한다.

1) 목적

테스트 계획서에 대한 목적과 작성 이유에 대해서 서술한다. (임의로 만든 내용) 

즉 이 문서가 왜 쓰인지 어디에서 쓰이는 지 가이드 하는 프로젝트 공수 산정에 있어 문서 표준을 정립하는 것이다.

만약 QA프로세스가 없다면 문서 양식과 프로세스 부터 체계화해야 하므로 문서부터 만들어 나가야한다.

 

예시)

1. 개요

 1) 목적

당사 지스케어의 쇼핑몰의 상품관리에 있어 타사 온라인 이커머스 플렛품 쿠팡,스마트스토어,옥션,11번가의 플렛품에 동시에 등록하여 판매팀과 CS팀의 효율적인 업무를 위해 당사 몰과 타사몰의 서비스를 연동하는데 있음

당사 몰의 경우는 스마트스토어가 아닌 자체적인 마켓을 구축되어있어 별도로 플렛품화가 필료함 

2) 범위

이번 프로젝트 테스트이 범위가 어디까지 적용되는지를 적는다

예) 앱이면 앱 웹이면 페이지명 컴포넌트별로 나눈다.

2-1 대상

본 문서는 전사 프로젝트에서 공용으로 쓰일 수 있도록 단일화하는 목적으로 제작하였다.

21.1 테스트 대상 서비스

자사몰(지스케어몰)과 타사몰(무좀사)와 연동자사몰과 무좀사와의 쇼핑물의 상품 데이터 동시에 상품이 등록되는 서비스로 모바일과 웹 환경에서 오류없이 api 연동이 되어야한다.

2.2 테스트 항목

 - 모바일 환경과  PC브라우저 환경에서 원할한 연동되는 지를 확인한다

 - 요구사항과 기획서에 명시된 기능되로 각 상품별 카테고리가 동일하게 연동되었는지 확인 

-각 브라우저,OS환경 별 호환성 테스트  

- 타사 몰의 api 서버문제로 당사의 api와 연동되지 않았을 경우의 비기능 테스트 당시의 상품과 타사몰간의 상품데이터를 통합으로 연동하는데 있어 제외하는 조건은 아래와 같다 

- 스토어 몰에 상품이 등록되어 있지 않은 경우  -

타사몰의 데이터를 가져오는 중 해당 몰의 카테고리가 자사몰에 있지 않은 경우     ( 해당 기능의 경우 개발,기획 회의를 거쳐 구현가능한지 확인 필요) 

2.3  전제조건

두개의 연동 몰 사이에 api가 정상적으로 연결되어야 함

등록된 상품이 한 개 이상 있어야함

테스트 시작 전 연동에 필요한 api서버와 환경이 준비되어 있어야 함

타사몰과 사전에 협의가 있어야함

테스트 시작조건은 테스트 완료일까지 조건이 되어하며 준비되지 않을 시 QA일정을 조율해야 한다.