개발팀 테스팅과 테스트팀 테스팅

* 그림과 표가 들어가지 않아 퍼온글인데 제대로 올라가질 않네요...

요약설명 -
개발하고있는 소프트웨어를 개발자가 어떻게 테스트 하는 것이 효율적인지에 대해 한번쯤은 관심을 가져볼만 하다. 테스팅은 개발과 마찬가지로 체계적인 프로세스가 존재하며 계획과 검증된 기법 및 지식없이 진행할 경우 테스팅이 제대로 되지 않아 결과물의 품질이 낮거나 프로젝트 자체를 실패할 수 있다.

본 아티클에서는 개발자가 어떻게 테스트 해야할지에 대해 세부적으로 다루고 있지는 않지만 해당 아티클이 개발자가 테스트에 대해 진지하게 생각하게 하는 기회는 제공해 줄 것이며, 세부적인 내용은 시간을 두고 살펴보도록 한다.
 
본문 -

테스팅은 V-모델에서와 같이 개발팀에 의한 테스팅과 테스트팀에 의한 테스팅으로 구분되어질 수 있다. 통상적으로 테스트팀이 테스트를 모두 수행해야하고 개발팀은 개발에만 전념해야 한다고 생각할 수 있는데 실상은 그렇지가 않다. 개발 과정에서 테스트팀 또는 QA (Quality Assurance) 조직으로  단계로 넘어가기 전까지는 개발팀에서 테스팅을 해줘야 전체적인 테스팅이 효율적이된다. 개발팀에서 테스팅을 제대로 해주지 못하면 테스트팀에서 테스트해야하는 부담이 클뿐만 아니라 개발되는 소프트웨어나 시스템이 전반적으로 불안정할 위험이 매우 높다. 그뿐만 아니라 개발팀 전체에 개발하는 소프트웨어나 시스템에 대한 자신감 (Confidence)이 없어 개발팀의 사기가 저하될 가능성이 크다. 추가적으로 개발팀 테스트가 중요한 또다른 이유는 초기에 결함을 많이 찾아내면 수정하는 비용이 적게들어 최종적으로 프로젝트 비용을 크게 절감할 수 있기 때문이다. 한마디로 개발팀이 효과적이고 효율적인 테스트를 해주지 않으면 개발 프로젝트가 전체적으로 실패하거나 개발 과정 중 또는 개발 후 비용이 높아지게 된다.

 
                            개발팀 테스팅                              테스트팀 테스팅
 
테스팅 레벨            단위테스트, 통합테스트                  시스템테스트, 인수테스트
 
목적                      안정한 시스템을 개발하는 것          시스템이 요구사항을 충족시킨다는 확신 제공
 
특징                      테스트 프로세스가 상대적으로 단순  복잡한 테스트 라이프사이클 및 활동
 
이상적 테스트        위험 기반 테스팅 기법과 함께 위의 두가지 테스트 접근법을 잘 조합하여야 중요 결함을 발견 가능
 

개발팀에서 주로 관여하는 V-모델에서의 테스팅 레벨은 단위테스트와 통합테스트인데 위와 같은 이유로 효율적이고 효과적으로 테스트하는 것이 매우 중요하다. 개발팀은 안정한 시스템을 개발하기 위해 테스트하는 것이고 가능한 테스트 프로세스를 단순화하여 진행하며 단위테스트 보다는 통합테스트에 집중하는 것이 일반적으로 더 효율적이다.

반면, 테스트팀에서 관여하는 V-모델에서의 테스팅 레벨은 시스템테스트와 인수테스트이며 시스템이 요구사항을 충족시킨다는 확신을 갖기 위해 수행한다. 테스트 프로세스는 테스트팀의 참여자 규모와 소프트웨어/시스템 규모, 지원 기반 환경 (Infrastructure) 등에 따라 달라지나 개발팀 테스트 프로세스에 비해 상당히 복잡한 테스트 프로세스를 가지고 있다. 아래 그림에서 보는 바와 같이 5단계의 큰 프로세스 (절차)와 각 단계별 프로세스별로 세부적인 절차를 가지고 있다. 테스트팀의 규모, 프로젝트의 규모가 작아지면 프로세스를 단순화시킬 수는 있지만 큰 골격은 변하지 않는다. 반면 개발팀 테스트 프로세스는 5단계 중 준비단계와 완료단계를 보통 생략하거나 다른 단계에 포함시켜 크게 3단계정도의 프로세스를 따르며 세부적인 절차도 단순화시켜 효율성을 기한다.

개발팀에서 수행하는 단위테스트는 소프트웨어/하드웨어 각각의 단위(모듈, 컴포넌트)를 다른 부분과의 연계성을 고려치 않고 격리하여 테스트하는 것이고, 통합테스트는 단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트(모듈)간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 하는 방법이다. 단위테스트와 통합테스트는 주로 소스코드를 직접 다루면서 테스트를 진행하며, 제어 흐름 테스트 (Control flow test), 개선된 조건/결정 커버리지 테스트 (Modified condition/decision coverage) 또는 최소단위 비교 테스트 (Elementary comparison test), 자료흐름기반 테스트 (Data flow based test), 기본 경로 테스트, 도메인 테스트 (Domain test), 뮤테이션 테스트 (Mutation test), 상태전환 테스트 (State transition test) 기법 등을 이용한다. 이들 테스트 기법의 선정은 테스트 대상 소프트웨어의 특성과 테스트 요구사항, 개발 설계 문서 등의 테스트 베이스 (Test base)의 성격과 존재여부 등을 고려하여 결정한다. 각각의 테스트 기법에 대해서는 뒷부분에서 자세히 다루도록 한다.

테스트 팀에서 수행하는 시스템 테스트와 인수 테스트는 다음번 아티클에서 다룰 계획이다.

정리

    일반적으로 개발자는 본인이 개발한 또는 동료 개발자가 개발한 모듈을 모듈단위, 통합단위에서 테스트하게된다. 이러한 테스팅은 코딩만을 검토하고 동작하는 것만을 확인하는 것에 제한되지 않는다. 테스팅은 개발과 마찬가지로 체계적인 프로세스가 존재하며 계획과 검증된 기법 및 지식없이 진행할 경우 테스팅이 제대로 되지 않아 결과물의 품질이 낮거나 프로젝트 자체가 실패할 수 있다.