14편에서는 단위테스트, 통합테스트 계획서를 어떻게 쓰는지에 대해서 알아보왔습니다. 그 연장선상에 보면 다음으로 작성하는 것이 바로 단위테스트 및 통합테스트 시나리오를 작성하는 것입니다. 테스트 시나리오를 작성하는 목적은 시스템의 기능 검증, 예상되는 결과가 정확하게 반환되는지, 결함발견, 테스트의 재사용성 그리고 문서화, 품질향상이라고 할 수 있습니다. 오늘은 단위테스트 시나리오 및 통합 테스트 시나리오 작성법과 차이점 등을 알아보도록 하겠습니다.
단위 테스트(Unit Test)를 유닛 테스트라고도 합니다. 단위 테스트는 소프트웨어 개발에서 가장 작은 단위인 모듈 또는 컴포넌트를 개별적으로 검사하는 테스트입니다. 예를 들어, 행복재단 스마트협업시스템을 구축한다고 하면, 포털, 메신저, 그룹웨어, SSO, 통합검색, DRM, 메일, 게시판, 인사연계 등 다양한 기능을 구현할 것입니다. 이때, 해당 모듈 SSO나 컴포넌트가 의도한 대로 작동하는지 확인하는 것을 목표로 테스트 하는 것을 말합니다. 일반적으로 단위테스트는 프로그래머가 소스 코드를 작성한 후에 수행되며, 작은 부분에 대한 테스트 케이스를 작성하고 실행하여 코드의 정확성을 검증합니다. 단위 테스트는 소프트웨어의 기본 기능을 보장하고 코드 수정 및 결과의 변경없이 코드의 구조를 재조정함으로써 향후 유지보수의 안정성을 유지하는 데 중요한 역할을 합니다.
통합 테스트(Integration Test)는 단위 테스트와 달리 개별적으로 동작하는 모듈이나 컴포넌트들을 결합하여 시스템 전체의 동작을 테스트하는 것입니다. 통합 테스트는 다양한 모듈 간의 상호 작용, 인터페이스, 데이터 흐름 등을 확인하여 시스템이 예상대로 작동하는지 확인합니다. 이러한 테스트는 개별적인 컴포넌트의 동작이 아니라 시스템의 통합된 부분들 간의 상호 작용에 초점을 맞춥니다. 통합 테스트를 통해 전체 시스템의 정합성과 안정성을 확인하여 사용자에게 신뢰할 만한 소프트웨어를 제공할 수 있습니다.
단위테스트는 개별 컴포넌트의 기능을 테스트하는 반면에, 통합테스트는 이러한 컴포넌트들이 결합되어 전체 시스템의 기능을 확인한다는 점에서 차이가 있습니다.
구분 | 단위테스트 | 통합테스트 |
정의 | 단위 기능 중심 | 업무 흐름 중심 |
테스트 범위 | 개별 컴포넌트 (함수, 메서드, 클래스) | 여러 컴포넌트 간의 상호 작용 |
작성자 | 개발자 | QA(품질관리자), 테스트 전문가, 개발PL |
시스템 | 개별 컴포넌트 외부 시스템 연계 배제 |
전체시스템 대상 외부 시스템간 및 데이터베이스와의 상호작용 |
단위 테스트 시나리오는 단위테스트ID, 기능 구분, 레벨1~3, 동작기능설명, 테스트 결과 이상유무, 비고 등을 각 단위모듈이나 컴포넌트별로 작성합니다. 아래의 표는 메일 기능을 테스트하기 위한 단위테스트 시나리오를 작성한 예시입니다.
통합 테스트 시나리오는 시스템명, 통합테스트ID, 시나리오명, 시나리오 설여, 시험절차, 업무내용, 시험항목, 사전조건, 입력자료, 예상결과, 확인자, 시험결과, 비고 등 각 시스템간의 연계가 정상적으로 동작하는지를 점검하도록 작성합니다. 아래의 표는 스마트협업시스템의 행복포털 시스템을 테스트하기 위한 통합테스트 시나리오를 작성한 예시입니다.
오늘은 구현 단계 산출물 중 단위 테스트 및 통합 테스트의 차이와 시나리오 작성법에 대해 알아보왔습니다.
단위테스트는 기능단위의 프로그램 모듈에 대한 테스트를 말하며, 통합테스트는 단위 테스트를 통해 단위 프로그램 별 업무 처리 기능과 데이터 처리 기능이 검증된 단위 프로그램에 대해 통합 시나리오에 따라 업무 흐름을 중심으로 정확히 실행되는가를 종합적으로 검증할 수 있도록 테스트 시나리오를 작성하여 검증하는 것이며, 검증이 되면 확인자가 시험결과에 대한 내용을 작성하여 피드백을 하게 됩니다. 이 피드백 되는 내용에 대해 다시 수정을 반복하고 완료되면 테스트가 끝나는 형태가 됩니다.
테스트 시나리오는 1차 QA 전문가나 개발PL이 작성하여 고객에게 전달하면, 고객은 고객요구사항과 비교하여 추가하여 테스트를 시나리오를 확정하고, 확정된 시나리오를 가지고 테스트를 시행합니다. 이 과정에서 고객요구사항에 없는 추가 요청사항이 들어올 수 있으니, 이 부분은 사전에 체크하여 제외하도록 해야 합니다. 하지만, 고객이 요구한 사항과 의도가 달라 개발이 누락되어 재개발을 해야 하는 상황이 발생할 수 있습니다. 따라서, 요구사항 분석 시 정확한 의도 파악을 명확히 하고, 지속적인 의사소통을 통한 점검이 요구되는 사항입니다.
실제 프로젝트를 하다보면 상당히 많이 도출되는 이슈 사항이기에 전체적인 프로젝트의 각 지점별 이슈사항 발생 지점들의 리스크를 사전에 파악할 수 있도록 PM의 능력이 요구되는 부분이라고 할 수 있습니다.
프로젝트에 대해 다른 사항이 궁금하시면 아래 링크를 클릭하세요
(1편) 프로젝트: 기술협상서 작성하기
(2편) 프로젝트: 사업수행계획서, WBS 작성하기
(7편) 분석 산출물 요구사항정의서 등 작성법 알아보기
(10편) 설계 산출물3: 프로그램 목록, 프로그램 명세서 작성법 알아보기
(11편) 설계 산출물4: 인터페이스 정의서 및 설계서 작성법 알아보기
(12편) 설계 산출물5: ERD 및 테이블 정의서 작성법 알아보기