테스팅을 위한 조직은 별도의 독립된 조직으로 존재하고 그로 인해 개발과 테스팅이 독립된 각각의 단계로 인식되고 업무가 진행되고 있다. 개발팀에서 개발한 소프트웨어가 목표치에 도달했다고 판단되면 이를 검증하기 위해 QE팀에 전달하게 되고 이를 QE팀이 테스트 하게 된다. 출시를 위해 소프트웨어가 품질 기준을 만족하는지를 검증하는 것을 주 업무로 생각하지만 소프트웨어 품질 및 생산성 향상을 위한 관점으로 보았을때는 전혀 품질 및 생산성 향상을 위한 활동으로 보이지 않는다. 문제를 안고 있는 소프트웨어 구조로 개발을 하고 아무리 많은 반복 테스트를 한다 하더라도 궁극적으로 품질이 좋아지는 것은 아니다.
품질이 좋아지는 것에는 조금의 영향을 줄 수 있지만 생산성 측면에서는 테스팅 단계에서의 수정은 너무나 많은 비용을 지불하게 되는 것이다. 소프트웨어 문제는 구조적인 문제와 소스상의 문제가 있을수 있는데 이러한 구조적인 문제와 소스의 문제점을 빨리 발견하고 해결한다면 개발 기간의 단축과 품질 향상 효과를 얻을 수 있다. 테스팅과 유지보수에 많은 프로젝트 기간을 차지하여 중요한 부분으로 여겨지지만 다르게 생각하면 리스크를 미리줄일 수 있고 효과적으로 테스팅 업무를 확대해 간다면 개선의 여지가 가장 많은 부분이라고 생각된다.
테스터가 프로젝트 전 단계에 관여하여 개발자가 발견하지 못한 리스크를 발견하고 테스트 용이성을 높여 조기에 문제를 발견하고 해결하므로 개발기간 단축 효과를 갖어 올 수 있다.
테스트 관련 업무를 정리해보자
- 유스케이스(요구사항)을 기준으로 테스트케이스 작성 (테스트케이스를 통해 누락된 시나리오나 테스트 어려운 부분 도출
- 테스트 용이한 구조 설계
- 테스트를 위한 Mock Object 설계 및 개발 (테스트 코드 재사용 가능)
- 테스트 가이드 제시 및 소프트웨어 소스 또는 성능 목표치 설정 및 제시
- 테스팅 지원
테스팅 업무 단계는 아래의 그림과 같다.
그림에서 보는것과 같이 테스팅을 하고 Defact Tracking 까지도 해야 한다. 테스팅시 발생하는 문제는 독립적으로 발생할 수 있지만 다른 기능의 수행 이후에 이전 모듈의 문제로 발생하는 경향이 있다. 이를 찾기란 힘들다. 테스트할 때 간헐적으로 발생하는 것이고 발생해서 갔을때는 재현 하기란 여간 까다로운 것이 아니다. 테스트를 하면서 테스트 전 후 상태를 명시하는 것은 도움이 될 수 있다. 테스트케이스를 작성하고 여러사람이 무작위로 순서없이 테스트 하지만 문제가 발생하는 정확한 순서가 있으므로 이를 항상 재현가능 하게 한다면 문제를 찾고 해결하는데 많은 시간을 줄일 수 있다.
Filed under: Test & Verification | Tagged: Tester, Testing
