테스트 플랜에 들어가야 하는 내용에 대한 개관

테스트 플랜 (test plan)에 대해서 오해도 많고 실수도 많은 것 같다. 계획을 문서화 한다는 것은 어느 산업 분야나 이슈이며 어려운 작업임에는 틀림이 없는 것 같다.

이에 QA엔지니어가 테스트 플랜을 작성하는 데 있어 "블랙 박스"의 관점으로 접근할 때 필요한 내용을 서술해 보겠다.

1. 인수 테스팅 상황
   1. 상용 어플리케이션이라면 포장지를 뜯고 사용자 매뉴얼을 읽으며 CD(혹은 DVD)를 트레이에 집어 넣으면서 시작하게 될 것이다.
   2. 기업용으로 특화된 어플리케이션이라면 해당 설치 예정 부서의 네트워크 망을 이용해서 어딘가의 웹서버에서 파일을 다운로드 받아 본인들이 직접 설치하거나 또는 TCO Stream 등의 전사적 PC 제어 소프트웨어를 통해 자동 다운로드 후 설치 과정이 사용자 모르게 진행되는 시나리오가 될 것이다.
   3. 필자는 웹 서비스 분야에는 전문가가 아니지만, 웹 서비스를 오픈하는 경우라면 외부의 인터넷 라인을 이용해서 오픈한 서비스에 접속해 보고 실제 사용자처럼 서비스를 이용해 보는 상황이 해당될 것이다.
2. 데이터 흐름 및 무결성
   1. 정보 처리 시스템에서 중요한 것은 데이터의 입력, 처리, 전달이다. 이중 단위 기능 테스팅을 통해 데이터의 입력과 처리가 해결된다고 하면, 데이터의 전달은 개개의 단위 기능 여럿이 모여서 행해지는 동작이므로 특히 어렵고, 복잡하며, 중요하다. 또한, 데이터가 단일 머신 내가 아닌 여러 서비스, 미들웨어, 인터페이스들을 통해서 옮겨다닌다면 이 과정에서의 데이터의 무결성 또한 매우 중요한 이슈가 될 것이다.
3. 환경과 호환성
   1. 특정 기업만의 소프트웨어라면 환경과 호환성 이슈는 다수의 대량의 유저와 구동 환경 보다는 적을 것이다.
   2. 확실히 이 이슈는 논리적인 기능 테스팅과는 거리가 있는 별개의 이슈이다. 다만, 확실히 할 것은 단위 기능과 모두가 단일 테스트 환경에서 반드시 한 번 이상 동작 확인이 거친 이후에나 다양한 환경에서의 구동이 의미가 있을 것이라는 점이다.
4. 스트레스 테스트
   1. 단위 기능 테스트에도 스트레스의 개념을 이용하여 테스팅할 수 있겠지만, 일반적으로 스트레스는 다수의 단위 트랜잭션의 구동, 인터페이스 간 병목 현상을 유발해 두고 전체적인 시스템의 동작 관찰 등의 처리할 수 없는 비 정상적인 상황을 의도적으로 만들어 두고 시스템이 어떻게 반응하는가를 관찰해 테스트 하는 것을 말한다.
5. 회귀 테스트
   1. 이것이 테스트 플랜에 포함되어야 하는 항목인가에 대한 논란이 있을 수 있지만, 테스팅 리소스 확보나 일정에 반영하기 위해서 포함되어야 한다고 생각한다. 이것은 테스팅은 이루어 졌지만 이후의 수정에 의하여 테스팅 결과가 최종적으로는 훼손되는 상황을 방지하기 위함이다.
6. 성능 테스트
   1. 스트레스 테스트와 이것을 혼동하는 경우가 있는데, 스트레스 테스트는 부하에 얼마나 견디는지 확인하는 목적인 반면에, 성능 테스트는 구체적인 성능 지표를 설정해 두고 그것에 부합하는지를 확인하는 테스트이다. 즉, 경쟁 제품의 성능 지표가 있다면 그것이 바로 개발중인 소프트웨어의 지표가 될 것이고, 표준이 있다면 그 표준을 뛰어넘는 것이 지표가 될 것이다.
7. 베타 테스트
   1. 베타 테스트에 대한 목적과 의도 및 대상에 대한 설정을 한 후 시행하는 것이 좋다. 이러한 목적성 없이 단순히 릴리즈 일정을 맞추기 위해서 지나치는 임의의 개발 단계중 하나로 생각한다면 재앙은 불을 보듯 뻔하다.

이 이후에도 알파 테스트, BVT 등의 테스트 내용들이 있을 수 있다. 더 알고 싶은 분들은 필자의 이전 글들을 찾아 보기 바란다.