통합테스트는 수행사보다 발주사의 역할이 더 중요하다

소프트웨어 개발 단계별로 소요되는 기능점수(Function Point) 비중은 분석단계 19%, 설계단계 24%, 개발단계 32%, 테스트단계 25%이다(출처: S/W대가산정가이드, 한국소프트웨어산업협회, 2019). 테스트 단계는 개발 시스템의 성공 여부가 판가름나는 중요한 단계이다. 

테스트를 얼마나, 어떻게 할 것인가는 구축 대상 시스템 특성에 따라 달라진다. 주로 고려할 요소는 목표 시스템에 요구되는 신뢰성과 사용성, 안전성 등의 품질기준이다. 대상 프로그램 물량, 테스트 참여자 가용 규모, 수행할 수 있는 테스트 일정 등에 따라 테스팅 전략을 수립해야 한다. 테스팅 전략에 따라, 테스팅 방법과 횟수 등을 정한다.

결함은 식별과 조치가 용이한 것이 먼저 도출되고, 식별은 용이하나 조치가 어려운 것이 그 후 도출되며, 이어서 식별은 어려우나 조치가 용이한 것이 도출되고, 식별과 조치가 어려운 것이 가장 나중에 도출되는 경향이 있다. 따라서 테스트 횟수는 4회 이상으로 잡는 것이 바람직하다. 프로그램 결함 수정, 또는 새로운 개선사항 반영 시, 정상적으로 테스트 완료된 프로그램에 추가로 결함이 발생되는 경우가 있으므로 추적 테스트 수행도 감안해야 한다.

1차 통합테스트에 수행사만 참여하여 자체 테스트를 수행하는 경우가 있다. 이후에 진행되는 통합테스트에는 발주사가 반드시 주도적으로 참여해야 한다. 수행사 업무이해도와 관점의 차이로 수행사만의 테스트로는 응용시스템의 품질이 보장될 수 없기 때문이다.

통합테스트시나리오와 테스트케이스 작성 주체 및 준수사항

업무 이해도가 높지 않은 수행사가 통합테스트시나리오/케이스를 작성하면 고품질의 테스트시나리오/케이스가 도출되지 않는다. 통합테스트시나리오/케이스가 부실하면 테스트 품질이 저하된다. 따라서, 업무프로세스를 기반으로 통합테스트시나리오/케이스 사례들을 작성하고, 발주사가 테스트시나리오/케이스의 주요 흐름을 정립한다.

통합테스트시나리오/케이스는 업무를 기반으로 Start 지점과 End 지점의 범위를 명확히 하는 것이 중요하다. PI(Process Innovation)를 수행한 경우, 정의된 목표프로세스를 기반으로 통합테스트시나리오/케이스를 구성하고, Activity별 화면을 맵핑하여 상품 및 데이터별 테스트를 수행하도록 테스트시나리오/케이스를 구성한다.

수행사는 발주사가 작성한 통합테스트시나리오/케이스 초안을 제공받아, 상세 내역(테스트 조건, 입력데이터, 예상결과 등)을 작성하도록 한다.
테스트케이스는 입력데이터와 예상된 결과를 필수로 정의해야 한다. 테스터는 자신이 원하는 것만 보는 경향이 강하기 때문에 잘못된 결과를 옳은 결과로 해석할 수 있으므로 예상된 결과를 상세히 기술하고 검토해야 한다.

수행되어야 할 기능만 테스트하지 말고, 프로그램이 동작하지 말아야 할 기능도 테스트되어야 하므로 테스트케이스에 반영한다. 또한 테스트케이스는 예상되는 올바른 값뿐만 아니라, 예상하지 못한 잘못된 값도 포함되어야 한다. 시스템 운영시 잘못된 값을 사용하는 경우가 자주 발생하며, 올바른 값을 사용할 때보다 더 많은 결함을 검출할 수 있기 때문이다.

테스트 대상 프로그램이 한번 쓰고 버릴 프로그램이 아니라면, 한번 쓰고 버릴 테스트케이스는 제외해야 한다. 시스템 운영시에도 결함 수정이나 프로그램의 개선으로 프로그램이 다시 테스트되어야 하는 경우 테스트케이스를 재사용할 수 있어야 한다.

테스트차수 증가에 따른 테스트 범위

테스트 차수에 따라 테스트 범위는 전체를 동시에 수행하는 “빅뱅방식”과 차수가 늘어남에 따라 범위를 늘려가는 점진적 확장 방식이 있다. “점진적 범위확장 방식”은 1,2차 통합테스트에서 응용시스템별 핵심업무를 테스트하고 3, 4차 통합테스트에서 비핵심업무로 범위를 넓혀가는 방식이다.

일반적으로 통합테스트시나리오의 단위 메인화면 커버리지는 70% 정도이며, 마스터데이터 및 코드 관리화면, 관리자 화면, 단순조회 및 리포트 화면 등이 제외되기 때문에 “빅뱅 방식”이라고 하더라도 메인화면 전체가 포함되는 것은 아니다.

차수별 전체를 목표로 하더라도, 개발 미흡으로 연기 건이 발생한다. 물론 정보계(DW분석시스템), 채널계(인터넷뱅킹, 대민시스템 등) 시스템들은 계정계 테스트 선행후 수행되어야 한다.

각 방식별 장단점은 다음과 같다.

 

발주사와 수행사간 테스트 수행방식

“수행사 → 발주사 Relay 방식”과 “발주사/수행사 합동테스트 방식”이 있다.
“수행사 → 발주사 Relay 방식”은 수행사가 선행하여 테스트를 수행하고 수행 증적을 제시하면, 발주사가 증적 확인한 후 해당 테스트시나리오를 테스트하는 방식이다.

“발주사/수행사 합동테스트 방식”은 수행사와 발주사담당자가 한자리에 모여 테스트를 수행하는 방식으로, 수행사는 테스트시나리오를 기반으로 조작(Operation)을 수행하고, 발주사는 테스트 수행 현황과 결과를 점검 및 평가하는 방식이다.

각 방식별 장단점은 다음과 같다.

 

발주사 IT와 현업의 비중에 따른 테스트 수행방법

“전체 합동테스트”, “부분 합동테스트”, “현업 자체테스트” 등이이 존재한다.
“전체 합동테스트”는 발주사 IT, 현업, 수행사가 참여하는 방식이다.
“부분 합동테스트”는 합동테스트 물량과 현업 자체테스트 물량을 구분하여 수행하는 방식이다.
“현업 자체테스트”는 현업 자체 심화 테스트를 수행하는 방식이다.

각 방식별 장단점은 다음과 같다.

 

차수별 통합테스트 수행 가이드

통합테스트는 어떤 전략으로 접근하느냐에 따라서 성과에 큰 차이가 발생한다. 주어진 자원으로 일정 기간 내에 테스트를 완료하기 위해서는 다음 가이드들을 따르는 것이 바람직하다.

▶ 발주사가 To-Be 시스템과 테스트 방법에 빠르게 익숙해지고, 수행사에게 테스트 책임감을 부여하기 위해 통합테스트는 “합동테스트”를 전제로 수행한다. 

▶ 발주사의 인력은 응용 영역별 IT, 현업 각각 1명 이상이어야 하며, 테스트 진척으로 영역내 병렬테스트 수행 여부를 검토해야 한다. 

▶ 1차 통합테스트시 수행사 선행테스트후 발주사/수행사 합동테스트를 수행하며, 2차 이후는 수행사 테스트는 제외하고 발주사/수행사 합동테스트만 수행한다. 

▶ 수행사 선행테스트 목적은 사전 관통테스트를 통해, 이후 합동테스트시 원활한 테스트를 수행하기 위함이다. 

▶ 통합테스트 진입 전 사전통합테스트 혹은 1차통합테스트에서 수행사 선행테스트가 계획되어 있다면, 1차통합테스트부터 통합테스트시나리오 전체를 대상으로 테스트를 수행한다. 

▶ 통합테스트에 현업이 참여할 수 있다면 2차부터 참여하도록 가이드하고, 3차시에는 현업자체테스트 물량과 합동테스트 물량을 구분하여 “부분 합동테스트” 방식으로 진행한다. 

▶ 테스트차수 증가에 따라 현업자체테스트 물량을 증가시킨다.