자꾸만 상황이 변하는 프로젝트, 어떻게 대비해야 할까? 성공적 테스트를 위한 준비사항
상태바
자꾸만 상황이 변하는 프로젝트, 어떻게 대비해야 할까? 성공적 테스트를 위한 준비사항
  • 김현동
  • 승인 2022.01.10 09:10
  • 조회수 396
  • 댓글 0
이 콘텐츠를 공유합니다

 

시작하면서..

프로젝트를 성공했다? 실패했다는 언제 알 수 있을까?

프로젝트의 성공과 실패는 판단 기준을 무엇으로 정하는지에 따라 프로젝트 오픈 이후 결정된다. 단, 프로젝트 참여자들은 시험단계에 수행되는 여러 테스트의 결과를 통해 프로젝트의 성공 또는 실패를 느낄 수 있으므로, 진정한 성공과 실패가 가시화되는 시점은 시험단계라고 말할 수 있다.

 

대규모 프로젝트의 시험단계는 업무/영향도, 넓은 테스트 범위, 다양한 종류의 테스트 수행, 다수의 참여자그룹 등으로 인해 고객사와 수행사 모두 쉽지 않은 과정이다.

프로젝트 오픈 여부가 점점 가시화되고, 내/외부 이해관계자의 관심도가 점차 높아지는 시기다. 반대로 시험단계를 시행착오 없이 수행하게 된다면 성공적인 프로젝트 오픈에 한발 더 가까워질 수 있다. 시험단계의 여러 테스트를 성공적으로 수행하기 위한 준비사항은 어떤 것들이 있는지 상세히 알아보자.

 

테스트 진입 기준

테스트 진입을 정하는 기준은 고객사와 수행사 모두 민감한 사항이며, 충분한 협의과정을 거쳐 테스트 진입기준을 설정하게 된다.

크게 2가지 측면에서 기준을 정하며, 프로젝트 상황에 따라 기준을 추가할 수 있다.

  • 구현단계 종료 측면
    - 개발 완료율 : 개발모수 대비 개발완료 비율(100%)
    - 단위시험 수행률 : 단위시험 모수 대비 수행사 단위시험완료 비율(100%)
    - 단위시험 성공률 : 단위시험 고객수행 대비 단위시험 성공 비율(100%)
    - 결함 조치율 : 결함모수 대비 결함조치 확인 비율(100%)
  • 시험단계 준비 측면
    - 테스트시나리오/케이스 작성률 : 대상 목록 대비 작성 비율(100%)
  • 추가 기준(예시)
    - As-Is시스템의 변경관리(SR)에 따른 변경 프로그램 개발 반영
    - 단위시험 판정기준이 ‘성공/실패’ 이외에 ‘조건부성공’ 관리시 대상 물량 조치
    - 각종 표준(개발표준, UI/UX표준 등)의 변경에 따른 기완료 프로그램 조치

 

현실적으로 시험단계 직전에 모든 기준을 충족하기란 불가능하므로, 측정 기준일을 정하고 그에 따라 수행사가 준비하고, 고객사가 점검하는 절차로 진행한다.

합의된 테스트 진입기준은 구현단계 종료지표 및 총괄시험계획서에 반영하고, 해당 진입기준은 프로젝트 전체 공지를 통해 전체 프로젝트 참여자가 숙지하는 것이 중요하다.

 

총괄테스트계획(Master Test Plan)

총괄테스트계획은 특정 테스트의 수행 계획이 아닌 모든 테스트를 총괄적으로 관리하기 위한 상위 계획이다. 테스트별 세부수행계획을 수립하기 전, 프로젝트에 적용할 테스트 목표, 범위, 일정(로드맵), 수행전략, 수행조직, 수행환경, 관리방안, 제약사항, 종료기준 등 시험단계에 대한 큰 방향성을 제시하게 된다. 추후 테스트별 세부수행계획의 뼈대가 되는 역할을 하게 되므로 계획 수립 시점에 현업의 참여시점 등 준비 과정상 영향도가 큰 의사결정 사항은 총괄테스트계획 수립 기간에 정해야 한다. 모든 테스트의 총괄 계획이므로 고객사-수행사간 의견 조율 등 준비 과정이 길고, 담아야 하는 내용이 많으므로 충분한 기간을 가지고 준비하는 것이 중요하다.

또한, 모든 테스트에 대한 개괄적인 개념과 방향성을 담고 있으므로 대규모 프로젝트를 처음 접하는 고객사 담당자들의 이해를 높이기에 효과적으로 활용된다. 총괄테스트계획이 완성되면 큰 틀에서 전체 테스트 목적과 범위, 일정, 참여자 등이 정해지므로 테스트별 세부수행계획을 상세화하기 쉬워지는 효과도 있다.

 

테스트 총괄 담당

최신 기술을 활용하는 프로젝트를 수행하더라도 결국 일은 처음부터 끝까지 사람이 준비하고 결정하고 만들어 간다. 초기 제안요청-업체평가-우선협상 과정에서부터 테스트 수행 역량을 갖춘 경험자 투입에 대한 요구사항은 필히 관철시켜야 한다. 테스트 총괄은 테스트에 필요한 모든 사항들을 고객사와 상세화하는 과정을 통해 총괄테스트계획을 작성하고, 준비하고, 실행할 수 있도록 이끌어야 한다. 수행사 내부적으로도 응용/아키텍처/데이터 등 타 영역과의 원활한 소통, 업무 분담을 통해 일이 진행되도록 하는 리더십과 실행력이 필요하다. 하지만 테스트 준비는 테스트 총괄 혼자서 할 수 있는 일이 아니다. 테스트 총괄은 영역간 그레이존은 없는지? 테스트별 간섭이나 누락은 없는지를 점검하고, 각 영역 담당자들과의 끊임없는 의사소통과 협업을 통해 전체적인 테스트 준비 상황을 챙겨야 한다. 테스트 총괄은 구현단계 초기에 투입되어야만 방대한 테스트 준비 사항을 하나씩 정리할 시간이 확보된다.

 

테스트 시나리오/케이스

테스트 시나리오/케이스는 구축된 시스템의 기능 품질을 검증하기 위한 네비게이션 역할을 하는 문서다. 업무 흐름 누락이나 잘못된 흐름으로 작성될 경우, 테스트 목표를 달성할 수 없다. 특히, 현업의 업무 수행 흐름에 따라 값을 검증해야 하는 통합테스트는 시나리오/케이스의 품질에 따라 테스트 성패가 좌우된다. 테스트 시나리오/케이스 품질 확보를 위해 현업 업무 수행 흐름, 분기/예외조건 등을 충실히 담을 수 있도록 작성 양식을 검증하고, 작성 가이드는 일관되고 쉽게 제공됐는지 등을 사전 점검하고 보완해야 한다. 수행사가 일반적으로 작성하는 방식인 시스템 기능 흐름 중심의 시나리오/케이스 수준으로는 충분한 업무 흐름을 검증하기 어렵다. 그러므로 테스트 시나리오/케이스 작성은 업무 흐름을 알고있는 고객 주도로 작성되는 것이 바람직하며, 수행사는 시나리오/케이스별 프로그램 매핑 및 수행 데이터를 준비해야 한다. 다만, 고객사의 수행 인력 및 역량 부족으로 작성이 어려울 경우, 선행 사업(ISP/PI)의 업무 산출물(프로세스/맵)을 활용하는 것도 대안으로 검토해야 한다.

 

통합테스트 수행방식

합동방식과 릴레이방식의 통합테스트는 쉽게 설명하면 참여자가 모여서 테스트를 수행하는지, 수행사-고객사 순서로 각자 수행하는지 정도 차이다. 수행방식의 의사결정에 따라 수행 결과와 참여자의 노력은 크게 차이가 나게 되므로 통합테스트는 합동방식으로 합의하는 것이 중요하다. 그러나 합동방식의 테스트가 익숙하지 않은 고객사나 수행사는 합동방식이 다수가 모여서 수행사의 시연으로 수행하는 것에 대해 각자 테스트를 하는 것보다 테스트 효율이 떨어진다고 오해한다. 이는 단위테스트와 통합테스트의 점검 목적을 정확히 이해하지 못해서 발생하는 오해다.

단위테스트는 화면 구성요소(설계기준), 화면 표준 준수여부, 단위기능 동작 정도를 점검하므로 각자의 자리에서도 충분히 점검 가능하다. 하지만 통합테스트는 구현된 전체 기능에 대해 업무 흐름에 따라 값을 검증할 수 있는 마지막 테스트 기회다. 개발자가 구현한 프로그램이 대상 업무와 요구사항을 모두 반영했는가를 참여자 전체가 함께 검증한다. 합동테스트 중 발생한 결함은 수행사 참여자(PL/개발자)와 고객이 함께 확인하고, 소통함으로써 양자간 불필요한 의사소통 비용도 줄어든다. 또한 고객이 직접 테스트 데이터를 준비하기 어려우므로 수행사가 테스트 데이터를 이중으로 준비하는 노력이 필요하다. 마지막으로 각자 테스트 수행 시 발생한 결함은 수행사에서 결함 재연이 불가능하거나 결함 재연을 위해 과도한 노력을 쏟게 된다.

 

테스트 수행환경

계획된 일정까지 준비가 안될 경우 프로젝트 전체 일정에 큰 영향을 줄 수 있는 준비요소다.

테스트 수행환경은 테스트를 수행하기 위해 필요한 인프라(HW/SW/솔루션 등) 설치, 서버(개발/테스트/운영) 구성부터 소스/데이터의 형상/배포관리(정책), 데이터 전환, 데이터 변조, 권한 적용 등 많은 부분이 준비가 필요하다.

구현단계까지는 대체로 ‘개발자PC-개발서버’ 환경에서 개발과 단위테스트가 진행된다. 시험단계로 전환되고, 모든 테스트 종류를 수행하기 위해서는 환경이 ‘개발자PC-개발서버-테스트서버-운영서버’ 구성으로 확대 구축이 필수적이다. 이때 중요한 점검사항은 각 서버별 환경 구성 일정과 해당 환경에서 수행될 테스트간 일정을 맞추는 것과 모든 테스트간 수행환경으로 인한 간섭이 일어나지 않도록 조정하는 것이다.

 

테스트 관리 도구

시험단계에서는 테스트 참여자의 역할에 따라 수행한 활동(테스트 실행/결과판정, 결함 등록/조치/확인)을 실적으로 관리해야 한다. 이런 활동 실적은 팀/업무/담당자별 진척으로 이어지며, 테스트 진척 현황을 모니터링하고, 이를 각종 보고자료에 활용한다. 수행사가 제공하는 테스트 관리도구(PMS)는 프로젝트 규모에 따라 상당히 많은 사용자가 동시에 사용하게 되므로, 체계적이면서 편해야 한다. 또한, 시험단계에 수행되는 다양한 테스트 종류별로도 실적/결함/진척 관리가 가능해야 한다. 만약, 관리 도구의 제공 기능이 프로젝트에서 정의한 관리 기준과 부합하는지 사전에 점검하고, 개선이 필요한 기능은 시험단계 진입 전에 개선하고, 다시 확인해야 한다.

 

테스트 의사소통

테스트 준비/계획수립/검토/의사결정을 수행하는 과정에서 의사소통을 위한 채널이 반드시 필요하다. 본격적인 테스트 준비가 진행되는 시점에 “테스트협의체” 구성은 필수적이다. 테스트협의체 활동을 중심으로 핵심 안건을 선정하고, 정기적인 협의와 의사결정 과정을 통해 순서대로 정리해야 한다. 협의체의 운영은 모든 안건들에 대해 정기, 수시 보고를 통해 안건 별 진행 현황을 모니터링함으로써, 지연되는 안건이 없도록 신속한 의사결정하는 것이 중요하다. 자칫 테스트에 참여하는 많은 이해관계자들에게 영향이 미칠 수 있다. 협의체를 통해 결정된 각종 테스트 수행 기준, 방식, 일정, 범위, 환경, 지침, 절차 등 프로젝트 전체 구성원에게 공유되어야 할 정보 흐름이 지연되는 것은 주의해야 한다. 테스트 진행 과정의 정보 변경 역시 꾸준히 공유되는 것이 중요하다. 특정 인력만의 정보 독점과 공유 부족은 그레이존을 유발하는 요소이므로 프로젝트의 관리자들이 지속적으로 신경 써야 할 부분이다. 시험단계 이후부터는 더 많은 이해관계자들이 프로젝트에 직간접적으로 참여하게 된다. 의사소통에서 누락되는 대상은 없는지, 적절한 시점에 참여할 수 있도록 점검하고 준비해야 한다. 예를 들자면, 대외연계테스트를 위한 대외기관담당, 대내 대응개발시스템 담당, 시스템운영부서, 현업부서 등이 그러하다.

 

마무리하면서..

프로젝트는 항상 여러가지 변수로 인해 상황이 변한다. 테스트 수행 역시, 철저한 준비를 했다고 해도 바뀔 수 있다. 다만 앞서 말한 테스트 준비사항들에 대해 충분히 고민하고, 잘 준비했다면 변경 요인이 발생해도 적절히 대응이 가능하다. 하지만 충분한 고민과 준비되지 못했을 땐, 점차 줄어들어가는 프로젝트 시간 속에서 빠른 대응이 어렵다. 철저한 준비 과정없이 좋은 결과를 바라는 베짱이의 마음가짐으로는 추운 겨울을 피하기 어렵다는 교훈을 되새겨 차곡차곡 준비해야 한다. 철저한 준비만이 프로젝트를 성공으로 이끌 수 있다.

 

댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.