테스트 크기에 따라 테스트 커버리지 선정하기 | 언젠가 당신은 테스트 리더가 되어 하나 이상의 제품에 대한 품질을 관리하고 담당하는 역할을 맡게 될 것입니다. 경험과 노하우가 많은 시니어에게는 테스팅 계획에 따른 테스트 커버리지를 선정하는 것이 매우 쉬운 일일 것입니다. 하지만 일을 갓 시작한 신입이나 경험이 부족한 주니어에게는 테스팅을 계획하고 테스트 범위를 선정하는 단계부터 큰 벽에 가로막히게 됩니다.
테스트 리더로서 테스트가 누락되어 검증되지 않은 영역이 없도록 가장 적절한 테스팅 방법을 선택하고 계획을 설계해야 한다는 부담은 매우 큽니다. 물론, 주변의 선배나 조력자에게 배우거나 또는 실무 현장에서 테스트를 수행하면서 발생하는 시도나 실패를 경험하며 배울 수도 있습니다. 하지만 많은 경우 이런 도움을 받을 수 있는 경로나 실패를 경험하며 배울 수 있는 시간조차 주어지지 않을 때가 많습니다.
지식을 얻기 위해 웹 사이트나 책을 통해 관련 정보를 찾아보려 하지만, 테스트 종류와 각 종류별 수행 방법에 대한 정보만 있을뿐 테스트 크기에 따라 커버리지를 어떻게 선정할 수 있는지에 대한 가이드를 찾는 것은 쉽지 않습니다. 이는 아마도 주어지는 임무에 따라 시스템의 크기가 다양하고 각 회사의 테스트 조직 크기와 테스트 인원이 보유한 역량이 다르며 테스트를 위해 지원되는 자원들이 다르기 때문일 것입니다. 이 글에서도 여러분이 처한 상황과 환경 내에서 가장 적절한 커버리지를 선정하는 방법을 가이드할 수는 없습니다. 대신 예시 사례로 테스트 범위를 계획하는 방법으로 풀어보려 합니다. 이를 참고하여 실무에 적용해보거나 아이디어를 얻을 수 있는 도구로 활용해 보기 바랍니다.
-------------------- ♣︎ --------------------
테스트 커버리지를 선정한다는 것은 간단히 말해 무엇what을 어떻게how 테스트할지 결정하는 것입니다.
좋은 커버리지를 확보하는 방법은 테스트할 제품을 먼저 이해하고 고객의 요구사항과 시스템 크기, 리스크 요소, 주어진 일정, 투입 인원과 인원이 보유한 역량, 프로젝트의 목표, 지원되는 자원(테스트 도구, 테스트 환경 등) 등 여러 조건을 고려해서 테스트 범위를 선정해야 합니다.
여기서는 다른 조건들은 제외하고 주어진 소프트웨어의 크기와 목적에 따라 테스트 수행을 위한 커버리지를 분류하는 방법을 살펴보겠습니다.
◼︎ Small Size Test
* 하나의 메소드 또는 클래스 수준의 신규 기능 추가
* 단위 테스트
하나의 모듈이나 프로그램, 클래스, 메소드 등 가장 작은 단위의 소프트웨어를 대상으로 요구사항대로 작동되는지 확인하는 테스트.
* 운영중인 소프트웨어의 유지보수
- 이슈 수정 패치 (간단한 버그 수정)
- 기능 또는 UI 개선
Small Size Test는 모듈 간 상호 작용이 없는 독립된 하나의 기능을 테스트 하는 수준으로 봅니다. 테스트 반경을 확장하더라도 테스트하는 기능에 영향을 받는 주변 기능 또는 시스템이 범위에 해당됩니다.
예를 들어, 기존에 운영되는 소프트웨어 시스템에서 결함이 발견되어 이를 수정 패치하고자 할 때 첫째, 수정되는 결함에 대한 확인 테스트만 수행하거나 둘째, 디바이스나 운영체제별로 수정 패치가 동일하게 적용되었는지 호환성 테스트를 수행하거나 셋째, 수정되는 결함에 연관된 주변 기능에 대한 리그레션 테스트를 수행할 수 있습니다.
Small Size Test를 수행할 경우 선정되는 테스트 종류는 단위 또는 기능 테스트(수정되는 기능에 제한된), 호환성 테스트, 리그레션 테스트 로 테스트 커버리지를 선정할 수 있습니다.
Q. “하나의 기능"만 패치할 때 작은 사이즈 테스트가 적용되는 것인가? 회사의 유지보수 패치 노트에는 여러 건의 이슈 수정 목록이 있는데 이런 경우에도 small size test를 활용 할 수 있을까요?
A. 테스트해야 할 기능에 모듈간 상호 작용이 포함되어있지 않는 경우 small size test 범위로 수행할 수 있습니다. 유지보수 패치 빌드노트를 보면 대부분 개별 결함 수정 목록이나 건별 개선내용이 나열되어있고 목록간 모듈 통합은 높은 확률로 포함되어있지 않은 경우가 많습니다.
“하나의 기능"에 포커스를 두는 것이 아니라 “모듈간 상호 작용이 없는 독립된 기능을 테스트" 하는 것으로 이해하시기 바랍니다. 즉, 패치 노트에는 여러 건의 수정 결함과 개선건이 있지만 각각이 독립된 하나의 기능에 해당되는 것이고 각 기능에 대한 작은 사이즈 테스트가 진행되는 것입니다.
◼︎ Medium Size Test
* 하나 이상의 신규 기능과 모듈간 인터페이스가 존재하는 기능 추가 시
* 운영중인 소프트웨어 유지보수
- (운영중인 소프트웨어 내 신규 또는 변경에 대한) 통합 테스트, 시스템 테스트
- 하드웨어 OS, 서버, DB 등 시스템 업데이트 또는 변경
- 소규모 신규 프로젝트 출시
* 이전에 수행하지 못했던 테스트 유형에 대한 추가 검증
기존 운영 중인 소프트웨어에 하나 이상의 기능이 포함되어있고 모듈간 인터페이스가 존재하는 기능이 추가되는 경우 mediun size test로 범위를 선정하여 테스트를 수행합니다.
예를들어 운영중인 배송 시스템을 새로운 시스템으로 변경하거나, 결제 기능 내 신규 결제 시스템이 추가되거나, 로그인 인증에 신규 인증 시스템이 추가되는 등 출시 당시 컴포넌트에 대한 품질 검증이 완료되었으나 이 후 폐기 또는 신규 서비스로 교체되는 경우나 서버/DB/OS 등 시스템 업그레이드로 인해 전체 서비스 품질에 대한 영향도 체크가 필요한 경우 그리고 기존에 존재하지 않았던 완전히 새로운 기능 추가로 테스트 대상 범위에 대한 전체 품질 검증과 기존 시스템과의 상호 작용 확인이 필요한 경우가 해당됩니다.
여기에는 기존 시스템에 추가되는 기능 외 운영툴과 같은 외부 시스템과 연계도 포함될 수 있습니다.
mediun size test를 수행할 경우 선정되는 테스트 종류는 맡겨진 임무(테스트 객체, 크기, 리스크, 영향도 등)에 따라 변동될 수 있습니다. 예시로
① 운영중인 소프트웨어의 서비스 국가가 신규로 추가되는 경우
* 네트워크 테스트
* (해당 국가 주 사용 단말기/OS) 호환성 테스트와 클라이언트 성능 테스트
* 리그레션 테스트
② 하드웨어 OS, 서버/DB 등 업그레이드 또는 변경되는 경우
* 마이그레이션 테스트
* 리그레션 테스트 (기존 운영 시스템 + 새로운 운영 시스템)
③ 기존 시스템을 새로운 시스템으로 교체하는 경우, 이 경우에는 기존의 품질 검증이 완료되었더라도 새로운 시스템에서 동일한 품질 검증을 재수행해야 합니다.
* 기능 테스트
* 비기능 테스트
* 통합 테스트
* 시스템 테스트
④ 기존에 없던 새로운 기능 또는 시스템이 추가되는 경우
* 기능 테스트, 비기능 테스트
* 통합 테스트, 시스템 테스트
* 리그레션 테스트 (기존 운영 시스템 + 새로운 운영 시스템)
위와 같이 테스트 커버리지를 선정할 수 있습니다.
◼︎ Large Size Test
* 신규 출시Brand new 소프트웨어
- 시스템 전체에 대한 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
* 기능 테스트, 비기능 테스트, 스모크 테스트, 리그레션 테스트
large size test는 한번도 출시된 적 없는, 품질에 대한 검증이 이뤄지지 않은 전체 소프트웨어에 대한 테스트를 진행할 때 적용되는 범위입니다.
medium size test가 기존 운영 중인 환경 내에서 대규모 패치나 신규 기능 추가가 발생할 시 해당 범위에 대한 통합~시스템 테스트가 수행된다면, large size test는 전체 소프트웨어가 대상이 되어 모든 테스트 유형으로 모든 테스트 단계를 통과하는 테스트가 수행됩니다.
대형 사이즈 테스트를 수행할 때 선정되는 테스트 종류는
* 기능 테스트
전체 시스템의 기능과 특징 확인
* 비기능 테스트
전체 시스템의 (클라이언트/서버)성능, API, 호환성, 네트워크, 예외처리(앱 공존성 등) 확인
* 통합 테스트
모듈간, OS/하드웨어/외부 시스템과 상호 작용 동작 확인
* 시스템 테스트
사용자가 실제 사용하는 환경에서 시스템 기능과 통합간 인터페이스 전체 확인
* 인수 테스트
실제 운영 환경에서 사용할 준비가 되었는지 확인
* 스모크 테스트
* 리그레션 테스트
마이그레이션을 제외한 모든 테스트 활동이 수행됩니다.
좋아요 4 • 저장 7
