본 시리즈에서는 QA / Test에 관한 주요 내용을 이어나가봅니다..
테스트의 7 원칙
1. 테스트는 결함이 있는 것만 증명한다.
테스트에 의해 결함이 있다는 것은 알지만, 결함이 없다는 것은 증명할 수 없습니다. 테스트를 통해 소프트웨어에 남은, 발견하지 못한 결함을 찾아내는 것은 가능하지만, 결함을 찾아내지 못한 상태라도 그것이 문제없다고는 말할 수 없습니다.
2. 모든 테스트는 불가능하다.
모든 입력조건의 조합을 테스트하는 것은 매우 단순한 소프트웨어가 아니라면 비현실적입니다. 전수 테스트를 하는 대신에 리스크나 우선순위를 고려하여 테스트의 관점을 다시 확인하고 집중하는 것이 필요합니다.
3. 초기 테스트를 해야한다.
빨리 결함을 찾아내기 위해, 테스트는 SDLC (Software Development LifeCycle, 소프트웨어 개발 생명주기) 에서 되도록 상위 단계(요구사항 정의, 소프트웨어 설계 등)부터 실시해야합니다. 이렇게된다면 실제 개발이 완료된 후 찾아내는 결함을 수정하는 Cost보다 훨씬 더 절약하여 결함을 수정할 수 있습니다.
4. 결함의 편재
결함을 모든 곳에서 골고루 확인하는 경우는 드뭅니다. 테스트는 모듈별로 결함의 밀도의 예측이나, 직전 테스트의 결과에 비례하여 테스트 초점을 바꾸어나가야만합니다. 릴리즈 직전의 테스트에서 찾아내는 결함의 대부분으 어떤 특정 모듈에 집중되어 있습니다.
5. 살충제의 패러독스
벌레들에게 같은 살충제를 계속해서 사용하다보면, 어느샌가 살충제에 대한 내성이 생기고 맙니다. 테스트에서도 이와 마찬가지로, 같은 곳을 계속해서 집중적으로 같은 테스트 방법으로 테스트를 진행하다보면, 개발자들도 이것을 알아채어 해당 테스트에 익숙해지게됩니다. 때문에 테스트방법, 테스트 케이스는 주기적으로 확인하여 수정해줄 필요가 있습니다.
6. 테스트는 상황에 따라 다르다.
테스트 조건이 바뀐다면, 테스트하는 방법이나 테스트 케이스도 달라져야만 합니다.
예를 들어 높은 가동안전성(신뢰성)이 요구되는 24시간 가동 시스템의 테스트는, 단순한 E-commerce 시스템의 테스트와는 달라야합니다.
7. 오류-부재의 궤변(결함 제로의 함정)
결함이 없다는 것이 고품질의 소프트웨어라는 것으로 직결되지 않습니다. 결함을 찾아 수정하여도 결국 시스템을 사용할 수 없게 된다거나, 유저 요건이나 기대를 충족시키지 못하는 소프트웨어는 별 쓸모가 없습니다.
