테스트 계획서 구성 항목 by Myers

출처: The Art of Software Testing, G. J. Myers, 1979년, 페이지 120~122

 

---

 

Myers에 따르면 적절한 테스트 계획서(a good test plan)는 아래와 같은 항목을 포함해야 한다.

1. 목표(Objectives): 각 테스트 단계의 목표를 정의해야 한다.
2. 완료기준(Completion criteria): 각 테스트 단계가 완료되었다고 판정하는 기준을 지정한다.
3. 일정(Schedules): 각 테스트 단계의 달력 날짜를 지정한 일정이 필요하다. 이 일정은 테스트 케이스를 설계하고, 작성하고, 실행하는 시점을 나타내야 한다.
4. 책임자(Responsibilities): 각 단계에서 테스트 케이스를 설계, 작성, 실행 및 검증 할 사람과 발견된 에러를 수정 할 사람을 식별해야 한다. 대규모 프로젝트에서 특정 테스트 결과가 에러인지 아니지에 대한 분쟁(예, 명세서 상의 애매모호함 또는 정의 누락 때문)이 종종 발생하므로 중재자를 식별해야 한다.
5. 테스트케이스 라이브러리 및 표준(Test-case libraries and standards): 대규모 프로젝트에서는 테스트케이스를 식별, 작성 및 저장하는 체계적인 방법이 필수적이다.
6. 도구(Tools): 필요한 테스트 도구를 식별해야 한다. 이것들을 누가 개발 또는 조달할지, 어떻게 사용할지, 언제 필요한지 등을 다룬 계획도 있어야 한다.
7. 컴퓨터 시간(Computer time): 각 테스트 단계에 필요한 컴퓨터 시간량을 계획해야 한다.
8. 하드웨어 구성(Hardware configuration): 특별한 하드웨어 구성 또는 장치가 필요한 경우 그 요구사항, 어떻게 요구사항을 충족할지, 언제 필요한지를 기술한 계획이 필요하다.
9. 통합(Integration): 어떻게 프로그램 조각들을 하나로 만들어나갈지 정의한다(예, 점진적 하향식 테스팅). 주요 서브시스템/프로그램을 포함하는 시스템이 점진적으로 하나로 조립되는 경우(즉, 빌딩 블록이 모듈이라기 보다는 프로그램 또는 서브시스템인 경우) 시스템 통합 계획이 필수적이다. 시스템 통합 계획은 통합 순서, 각 시스템 버전의 기능적 수행 능력(functional capability), "scaffolding(존재하지 않는 컴포넌트의 기능을 시뮬레이션하는 코드)" 생성 책임자 등을 정의한다.
10. 추적 절차(Tracking procedures): 테스팅 진척의 다양한 측면을 추적하기 위한 수단을 식별해야 한다. 예) 에러가 발생하기 쉬운 모듈 위치, 일정/리소스/완료기준 관련 진행 상황 추정
11. 디버깅 절차(Debugging procedures): 발견한 에러를 보고하고, 수정 상황을 추적하고, 수정된 버전을 시스템에 추가하는 메커니즘을 반드시 정의해야 한다. 일정, 책임자, 도구 및 컴퓨터 시간도 디버깅 계획의 일부여야 한다.
12. 회귀 테스팅(Regression testing): 회귀 테스팅은 프로그램의 기능을 개선하거나 수정 한 후에 수행하는 테스트이다. 그 목적은 변경으로 인해 프로그램의 다른 측면이 퇴보하지 않았는지 확인하는 것이며, 대개 프로그램 테스트케이스의 일부 부분집합을 다시 실행함으로써 수행한다. 회귀 테스트가 중요한 이유는 프로그램의 원래 코드보다 변경 및 에러 수정에서 훨씬 더 에러가 발생하기 쉬운 경향이 있기 때문이다(대부분의 신문 철자 오류가 원본의 에러라기 보다는 마지막 순간 편집 변경의 결과로 생기는 것과 유사). 회귀 테스팅을 위한 계획(예, 누가, 어떻게, 언제)도 필수적이다.