"시스템이나 문서에 대한 엄격한 테스팅"에 대한 의미는 무엇인가요?

질문

"시스템이나 문서에 대한 엄격한 테스팅은 운영 중에서 발생할 수 있는 문제를 감소시킬 수 있고(리스크 감소), 소프트웨어 시스템의 품질을 높이는데 기여할 수 있다(테스팅을 통해 발견되는 결함이 사용자가 시스템을 실제적으로 운용하기 전에 수정된다는 것을 전제함)." 이라고 되어 있는데, 문서를 테스트하는 건 어떤 의미인가요? 테스트는 프로그램을 대상으로 하는 게 아닌가요?

그리고, 문서를 테스트하는데 왜 소프트웨어 시스템의 품질이 향상되나요?

ISTQB 버전

ISTQB Syllabus 2018

답변

1. 리뷰란?

리뷰는 테스트의 일종입니다. 소프트웨어 테스팅과 관련된 지식들을 공부하다보면 정적 분석(Static Analysis), 혹은 정적 테스팅(Static Testing)이라고 부르는 활동이 있는데 이때 말하는 '정적(Static) 활동' 중 하나가 리뷰(Review)입니다.

리뷰 활동에서는 설계/기획 문서에만 수행하는 게 아니라, 코드나 테스트 케이스 등 여러 프로젝트 산출물들을 포함하여 포괄적으로 검토하게 됩니다. (IEEE 1028 - Generic process for formal review 참조.)

2. 리뷰의 목적

도서 "리뷰의 기술(모리사키 슈지 저)"에서 말하는 문서 리뷰 활동의 궁극적인 목적은 '수정 공수 줄이기'입니다. 즉, '리뷰'는 사업을 잘 하기 위해 '투자 대비 수익을 늘린다'에 관점을 둔 행위입니다. 흔히 말하는 ROI(Return on investment)에 대한 이야기입니다. 개발 공정의 마지막에 찾은 오류는 개발 공정 초기에 찾은 오류에 비해 수정 비용이 비싸다는 점에서 착안한 것입니다. '리뷰'는 분석/설계 단에서 이루어져야 효율이 높습니다.

문서를 리뷰하는 목적은 바로 개발하고자 하는 시스템의 잠재적인 문제를 미리 발견하는 데에 있다고 할 수 있습니다. 이는 우리의 테스트 실무 활동에서도 같습니다. 리뷰를 해야 하는 이유는 아래와 같은 이유가 있습니다.

오류가 있는 지 확인
작업이 완료되었는 지 확인
표준 및 지침을 준수하는지 확인

여기에서 오류란 단순히 '틀린' 것을 포함하여 전체 설계/기획 중 모순되는 부분이 있는 지를 확인하고, 제품/서비스 출시 후 사용자 단에서 발생할 잠재적인 위험이 있는 지를 확인하는 행위를 말합니다.

리뷰를 모두 설명하려면 너무 길고 복잡하기 때문에 이 정도로 '리뷰 활동'에 대한 목적 설명을 마치려 합니다.

3. 테스팅 시 리뷰 진행 방법

ISTQB에서 소개하는 소프트웨어 테스팅 시 리뷰 활동을 진행하는 방법은 아래와 같습니다.

Software Testing Genius - Stages of Formal Reviews

ISTQB에서 소개하는 공식 리뷰(Formal Review) 단계에 대한 설명은 향후 리뷰(Reviwe)에 대한 전문적인 소개가 필요할 시에 다시 진행하겠습니다.

조금은 더 한국 사람의 실무-Friendly하게 소개를 하자면, 아래의 내용과 같습니다. 물론, 꼭 아래와 같은 순서로 진행해야 한다는 의미는 아니며, 아래의 순서는 일종의 가이드라인 정도로 생각해주시면 됩니다.

기준을 정의: 체크리스트 여부 확인
산출물을 확인
체크리스트 대비 산출물과의 비교 결과 기록
변경사항을 공유, 토론
협의된 사안들을 구현
관련된 문서의 버전 관리
최종 문서를 산출물로 제공

다시 한 번 강조하지만, 프로젝트의 성격과 프로젝트 조직의 구성에 따라 프로세스는 바뀔 수 있습니다. 그러므로 위의 내용은 "리뷰를 위해서 해야 하는 일들에는 대략적으로 이런 일들이 있다" 정도로 이해하시면 좋습니다.

4. 리뷰의 장점

소프트웨어 개발 시 리뷰를 진행하면 다음과 같은 장점을 기대할 수 있습니다.

소프트웨어 결함은 개발 초기 단계(특히 공식 검토)에서 식별될 수 있습니다. 모든 결함은 조기에 찾을 수록 수정 비용이 감소하며, 늦게 찾을 수록 수정 비용이 높아집니다.
그러므로, 소프트웨어 문서 및 제품/서비스의 조기 검사를 통해 소프트웨어 유지 관리 비용을 절감 할 수 있습니다. 오류가 발생하여 대응하는 비용보다, 미리 사전에 검사하고 대응하는 비용이 더 저렴합니다.
기술 문서 작성자의 생각을 정리하는데 사용될 수 있습니다. 또한, 작성자가 미쳐 생각지 못한 관점을 다른 사람의 관점으로 채울 수 있습니다.
결함을 유발하는 프로세스 부족을 제거하는 데 사용할 수 있습니다. 인간의 인지능력은 완벽하지 않습니다. 아무리 훌륭한 프로세스를 사용할 지라도 이를 활용하는 인간은 완벽히 활동할 수 없습니다. 그러므로 그룹의 집단지성(Collective Intelligence)를 이용하여 인지부족으로 발생하는 결함을 상호보완하도록 할 수 있습니다.

이와 관련한 또 다른 내용은 본 블로그의 다른 필자들이 작성하신 테스팅의 원리[3] - “개발 초기에 테스팅을 시작하라.” 라고하는데, 테스트는 개발이 완료된 후에 하는거 아닌가요? 의 내용을 참고하세요.

5. 리뷰의 종류

ISTQB의 용어집에서 정의하는 대표적인 리뷰는 크게 3가지가 있습니다.

Peer review : A review performed by others with the same abilities to create the work product.
동료 검토 : 작업 산출물을 만들기 위해 동일한 수행 능력을 가진 다른 이들과 함께 수행 되는 검토.

Inspection : A type of formal review to identify issues in a work product, which provides measurement to improve the review process and the software development process.
인스펙션 : 작업 산출물 내에서 이슈들을 식별 하기 위한 정형적인 검토 방법중 하나. 검토 프로세스와 SW개발 프로세스의 개선을 위해 측정을 제공함.

Walk through : A type of review in which an author leads members of the review through a work product and the members ask questions and make comments about possible issues.
워크 스루 : 작성자가 본인이 작성한 산출물에 대하여, 멤버들을 이끌고, 질문 하고 코멘트를 주고 받는 리뷰 방법 중 하나.