“살충제 패러독스”에 빠지지 않으려면 어떻게 해야 하나요?

질문

살충제 패러독스”에 빠지지 않으려면 어떻게 해야 하나요?

ISTQB 버전

ISTQB Syllabus 2018

답변

본 글은 「소프트웨어 테스팅의 7가지 원리」와 관련되어 있으며, 테스팅의 원리 5번과 연관이 있습니다. 링크된 글(Episode 1편, Episode 2편)을 먼저 읽어 보시고 이 글을 읽으신다면 좀 더 도움이 될 거라 생각됩니다.

1. 살충제 패러독스(Pesticide Paradox)란 무엇인가요?

살충제 패러독스란 "같은 테스트 케이스를 가지고, 테스트를 계속해서 반복하는 경우 어느 시점부터는 더 이상 결함을 발견하지 못한다."라는 이론입니다. 테스트의 주요 목적은 소프트웨어의 다른 부분을 테스팅하여 잠재적인 결함을 발견하기 위한 활동이기 때문에 새로운 테스트를 하기 위한 활동을 해야 합니다.

The Pesticide Paradox – the blend between Software Testing and Agriculture

패러독스 논리학에 이런 말이 있습니다. 패러독스를 풀기 위해서는 논리적인 사고가 필요하며, 상식을 거스른다 해도 대부분의 문제는 그 상식을 논리적으로 풀어내야 한다는 것입니다. 예를 들면, '어떤 백조의 앞에는 백조가 두 마리, 어떤 백조 뒤에는 백조가 두 마리, 가운데에도 백조가 한 마리, 백조는 총 몇 마리일까요?'와 같은 쉬운 문제로부터 패러독스에서 빠져나오기 위한 방법을 찾아야 하는 것입니다.

그럼 소프트웨어 테스팅의 패러독스에서 빠져나오려면 어떻게 해야 하는 걸까요?

결론부터 말씀드리면 살충제 패러독스에 빠지지 않기 위해서는 동일한 테스트 케이스가 아닌 수행했던 테스트 케이스에 대해서 지속적으로 리뷰하고, 수정하여 다음 테스트를 수행할 때는 수정된 테스트 케이스를 이용하는 것입니다.

그럼 살충제 패러독스에 빠지지 않도록 테스트 케이스를 효율적으로 관리하면 되는데, 왜 자꾸 패러독스에 빠지게 되는 걸까요? 패러독스에 빠지지 않는 방법은 무엇일까요?

2. 테스트 케이스 이야기를 잠깐 해 볼까요?

위키백과에서 말하는 테스트 케이스란 「입력, 실행 조건, 테스트 절차 및 특정 프로그램 경로를 실행하거나 확인하는 방법으로 특정 소프트웨어 테스트 목표를 달성하기 위해 실행할 단일 테스트를 정의하는 예상 결과의 사양」으로 정의되어 있습니다.

테스트 전문가는 테스트 케이스를 소프트웨어 제품의 특정 요구사항을 기준으로 필요한 기능/비기능 요건을 준수하도록 작성합니다. 제품이 가져야할 특성과 기준, 기능의 작동 여부, 비기능의 충족 여부 등을 모두 테스트 활동으로 기획하게 됩니다. 그렇기 때문에 테스트 케이스는 체계적인 테스트 활동의 기초가 될 수 있습니다.

그러나 매번 모든 소프트웨어 버전에 대한 테스트 케이스를 작성하면 너무 오랜 시간이 걸리기 때문에 테스트 케이스 역시 효율적으로 재사용하기 위해 일종의 '패턴(Pattern)'이 필요합니다. 소프트웨어 개발 중 발생하는 모든 버전에 대해 테스트 케이스를 작성하면 너무 많은 인력과 시간이 필요하게 됩니다.

소프트웨어의 특정 범위를 테스트하기 위해 테스트 전문가는 테스트 스위트(Test Suite, 특정 범위 기준 테스트 케이스의 묶음) 혹은 테스트 사이클(Test Cycle, 테스트 반복 수행 기준)을 수립할 수 있습니다. 이렇게 패턴화된 테스트 묶음과 반복 기준은 프로젝트 내에서 테스트 전문가들의 테스트 수행 시간을 줄여주고, 효율화하여 소프트웨어 내의 문제점을 더 많이/쉽게 발견할 수 있게 해줍니다. 이런 식으로 테스트 전문가/전문팀이 공식적으로 정의한 테스트 케이스를 사용하면 소프트웨어 버전이 바뀌어도 동일한 테스트를 반복적으로 실행할 수 있으므로 효과적이고, 일관된 리그레션 테스트가 가능합니다. 이를 「테스트 케이스 재사용성 확보」라 합니다.

테스트 케이스 작성에 관련해서는 아래의 링크를 참고하시기 바랍니다.

자, 다시 살충제 패러독스 이야기로 돌아오겠습니다.

프로그래밍 작업의 결과는 항상 유기적으로 변화하는 게 아니며 수정하지 않은 내용, 영향받지 않는 컴포넌트들은 사실상 변경이 없으므로, 테스트 케이스를 반복적으로 적용하여 테스트를 수행하면, 어느 순간부터 동일한 방법의 테스트로는 이슈가 발생하지 않게 됩니다. 그래서 테스트 케이스를 반복적으로 재사용하면 명확히 살충제 패러독스에 빠지게 된다는 의미입니다. 테스트를 효율적으로 수행하기 위한 테스트 케이스의 재사용성 향상이 패러독스를 불러오는 상황으로 나타납니다.

바로 이 지점에서 테스트 전문가가 아닌 사람들이 테스트 활동에 대해 가지는 흔한 오해가 있습니다. 테스트 케이스를 아주 잘 만들고, 잘 작성한 테스트 케이스를 반복적으로 테스트하면 모든 결함을 찾아서 0%의 결함 상태로 출시할 수 있을 것이라는 믿음입니다. 이는 절대 불가능합니다. 그게 불가능한 이유는 0%의 결함을 보여주려면 100점짜리 테스트 케이스가 작성되어 있을 때나 가능한 일일 것입니다. 하지만 필자들이 본 블로그에서 몇 번 언급한 바와 같이 100점짜리 요구사항은 있을 수 없습니다. 요구사항이 완벽하지 않기 때문에 완벽한 프로그래밍 결과물도 있을 수 없으며, 완벽한 테스트 결과도 당연히 존재할 수 없습니다.

하지만 테스트 전문가로서의 역할은 그런 어려움이 존재함에도 소프트웨어 제품에서 최대한 결함이 나오지 않도록 그물망을 좁혀 발생 가능한 이슈를 줄이기 위한 노력을 하는 바입니다. 또한, 사용성이나 신뢰성 등을 높이기 위한 활동도 테스트 전문가의 몫이라 할 수 있습니다. 그리고 이런 살충제 패러독스가 발생할 수밖에 없는 상황 속에서도 효율적으로 테스트 케이스를 수정/변경/개선하고, 이를 기반으로 테스트를 수행하여 높은 수준의 제품 품질을 만들기 위해 테스트 전문가가 필요합니다.

3. 다시 한번 테스트의 목적을 상기해 볼게요.

이렇게 테스트케이스를 효율적으로 활용하는 이유는 테스트의 목적 때문입니다. 이번에는 테스팅을 왜 하는 것이고, 우리는 무슨 목적을 가지고 테스트를 해야 하는 것인지 알아야 합니다.

[ISTQB Syllabus 1.1.1]에서 제시하는 테스팅의 일반적인 목적은 아래와 같습니다.

잔존 결함의 발견
개발 시스템 / 소프트웨어에 대한 자신감 부여
결함을 미연에 방지
명세 충족 확인
사용자 및 비즈니스의 요구 충족 확인
비즈니스 리스크를 감소시키는 정보 제공(발견된 결함 기반의 수치 데이터 제공)

그 외, ISTQB Syllabus에서 소개하는 기타 이유는 아래와 같습니다.

개발 프로세스 점검
논리적 설계의 구현 검증
시스템 / 소프트웨어가 적절히 동작함을 확인

위와 같은 목적은 테스트의 정황이나 관점에 따라 달라질 수 있습니다. 간단하게 말씀드리면 개발과정, 인수과정, 품질평가, 유지보수, 운영 등 소프트웨어 전체 생명주기의 시점에 따라 달라질 수 있습니다. 개발 진행 과정에서는 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시키는 데에 중점을 둡니다. 인수과정에서는 예상했던 결과대로 시스템이 동작하는지 확인하고, 요구사항에 맞게 개발되었는지 확신을 얻는 과정입니다. 그리고 품질평가 단계에서의 경우는 특정 시간에 시스템을 출시함의 리스크를 개발 프로젝트 관련자에게 전달하기 위함이며, 유지보수 단계에서의 경우 변경사항을 추가적으로 개발하는 중에 새로운 결함이 유입되었는지를 확인하는 테스팅 과정이라 할 수 있습니다. 운영 단계의 경우 신뢰성 또는 가용성과 같은 시스템의 특성을 평가하기도 합니다.

이렇게 소프트웨어 제품/서비스의 전체 생명주기 안에서 유입되는 다양한 수정/개선 내역, 혹은 요구사항들은 소프트웨어의 전체적/세부적인 기능과 모양을 변경시킵니다. 테스트의 목적을 다시 한번 상기하고 명확히 살펴본 이유는 살충제 패러독스에 빠지는 근본 원인인 테스트 케이스를 반복적으로 사용하는 부분에 대한 개선점을 상기하기 위함입니다. 테스트 케이스를 효율적으로 개선함은 살충제 패러독스에 빠지지 않을 수 있는 핵심적인 방법이며, 바로 이 부분이 소프트웨어 개발팀이 역량 높은 테스트 전문가를 확보해야 하는 이유입니다.

아래의 이미지는 요구사항이 최종적으로 어떻게 변하는지에 대한 가장 대표적인 이미지입니다.

프로젝트에서는 일정과 비용이 무제한으로 주어지지 않기 때문에 테스트 케이스를 반복적으로 사용해야 함은 프로젝트 인력/일정의 효율적 활용을 위해 반드시 필요합니다. 테스트 전문가들은 요구 명세 충족을 확인하기 위해서 스토리보드나 화면 설계서, 요구사항 명세서, 기능 명세서 등을 기반으로 테스트 케이스를 설계하고 작성합니다. 그리고 이런 부분들은 소프트웨어의 생명주기 내에서 지속적으로 변화/발전합니다. 그래서 테스트 케이스를 작성/수정하는 과정은 무척 시간이 오래 걸리는 일이며, 수준 높은 분석 역량이 필요한 작업입니다. 그렇기 때문에 소프트웨어 전체 생명주기 내에서 변경/개선되는 내역을 이해하고, 테스트 케이스에 효율적으로 반영하는 역량이 테스트 전문가가 반드시 갖추어야 할 역량 중 하나라 할 수 있습니다.

요구사항 명세를 기반으로 작성된 화면 설계서나 스토리보드를 기반으로 테스트 케이스를 설계하여 작성 후 개발 산출물을 확인하는 활동이 바로 '요구 검증 활동'입니다. 요구 검증은 소프트웨어의 품질 활동 중 필수적인 테스트 활동의 하나이지만 살충제 패러독스에 빠질 수 있는 가장 치명적인 위험도 내포하고 있습니다. 버전이 새로 나올 때마다 리그레션(Regression) 목적으로 작성된 테스트 케이스를 이용하여 테스트를 수행할 수는 있지만, 리그레션 테스팅은 새로운 결함을 찾기에 적합한 방법이 아닙니다. 리그레션 테스팅의 목적은 기존 기능에 문제가 없는지, 예전에 발견되었던 이슈가 다시 발생하지는 않는지 여부를 확인하는 목적이기 때문입니다. 리그레션 테스팅에서 발생할 수 있는 살충제 패러독스의 문제점을 해결하기 위해 매번 기획/요구사항과 시스템의 전체 내역을 모두 보면서 테스트하는 건 일정/인력의 문제가 있기 때문에 현실적으로 어렵습니다. 아니, 불가능합니다.

그래서, 우리는 탐색적 테스팅을 병행해야 합니다.

4. 탐색적 테스팅(Exploratory Testing)이란 무엇인가요?

탐색적 테스팅이란 「테스트 리더가 설계한 제한된 세션 동안 차터의 목표를 자유로운 테스팅 기법으로 달성하고 팀 내 요약 회고로 학습/진화를 꾀하는 비계획적이며 사전 준비 없는 테스트 접근법」입니다. 간단하게 설명하면 동시 학습, 테스트 설계 및 테스트 실행 프로세스라고 할 수 있습니다. 테스트를 수행함과 동시에 계획, 분석 및 설계가 모두 함께 즉시 수행되는 것입니다.

소프트웨어 범위를 나누어 순차적/무작위적으로 테스트를 수행하고, 테스트를 수행하면서 발견한 결함들은 다시 리그레션 테스트 케이스로 작성하여 재사용하는 방식으로 살충제 패러독스를 최소화할 수 있습니다. 물론, 이를 다루고 수행하는 테스트 전문가의 역량에 많이 영향을 받는다는 점 때문에 초심자들에게 권하지는 않습니다.

탐색적 테스팅에 대한 자세한 내용은 인터넷 검색 혹은 아래의 도서를 통해 학습하실 수 있습니다.

필자 추천 도서 : 탐험적 테스팅 : 배우고 통찰하며, 개선하는 소프트웨어 테스트

구매처 : [ Yes24 ] [ 교보문고 ] [ 알라딘 ] [ 인터파크 ]

소프트웨어 테스팅 수행 중 탐색적 테스팅의 시간을 많이 확보하고 수행해야 하는 이유는 아래 이미지와 같습니다. 각 테스트 방식에 따른 결함 발견율을 수치화해놓은 테이블입니다.

"탐색적 테스팅(Exploratory Testing)"은 "경험 기반 테스팅(Experience based testing)"과 다릅니다. 이 둘은 서로 다른 방식의 테스팅 기법입니다. 현재 글은 ISTQB에 대한 글이므로, "탐색적 테스팅(Exploratory Testing)"에 대해서는 기회가 될 때 다시 한번 자세히 설명하겠습니다.

"탐색적 테스팅(Exploratory Testing)"에 관련해서는 본 블로그의 다른 글에서도 소개하였으나, 한 번 더 소개합니다. 탐색적 테스팅은 구글에서 개발자들이 사용한다고 알려져 있습니다. 이 지식 체계는 "정황기반학파(Context Driven Testing School)"에서 나왔습니다.

• 정황기반 학파의 기본 철학 : https://context-driven-testing.com/
• 정황기반 학파 주요 인물 1) Cem Kaner : http://kaner.com/
• 정황기반 학파 주요 인물 2) Bret Pettichord : http://www.pettichord.com/
• 정황기반 학파 주요 인물 3) James Bach : https://www.satisfice.com/rapid-software-testing-explored
• 정황기반 학파 주요 인물 4) Michael Bolton : https://www.developsense.com/
• 탐색적 테스팅의 원형 - 신속 소프트웨어 테스팅 : https://rapid-software-testing.com/

5. 살충제 패러독스에 빠지지 않기 위한 필자의 솔루션 제안.

필자가 다년간의 경험을 바탕으로 하는 제안 솔루션은 아래와 같습니다. 정답은 아니니 참고만 하시기 바랍니다.

요구사항을 기반으로 테스트 케이스를 설계 및 작성한다.
위 1번에서 작성된 테스트 케이스를 일부 시나리오 테스트 케이스로 작성한다.
위 2번에서 작성된 시나리오 케이스는 테스트 자동화한다.
베타 버전(최소한의 테스트 가능한 버전)으로 요구 검증을 위한 자동화 테스트를 수행한다.
....• 조건 : 기존 요구사항대로 시나리오와 베타 버전이 동일해야 한다. (현실적으로 불가)
베타1 버전으로 요구 검증을 메뉴얼 테스트를 수행한다. (보통의 현실)
....• 발견된 이슈에 대해서 테스트 케이스를 작성한다.
....• BTS를 사용하는 경우 결함과 테스트 케이스를 함께 생각하는 경우가 많으나 별개로 관리해야 합니다.
....• 결함은 결함대로 이력을 관리해야 하며 해당 결함에 대한 테스트 케이스는 별도로 관리되어야 합니다.
베타2 버전에서는 최대한 테스트 자동화를 이용하여 리그레이션 테스트를 수행하고, 발견된 이슈에 대한 확인 테스트를 선수행 후 탐색적 테스트를 수행한다.
베타N 버전에서는 5번을 반복합니다.
출시 이후에는 회고를 통해 발견한 결함이 아닌 결함에 대한 테스트 케이스에 대해서 리뷰하고, 놓진 테스트 케이스가 없는지 검토하며, 만약 놓진 테스트 케이스가 있다면 테스트 케이스를 추가하고, 해당 결함에 대한 리그레이션 테스트 수행 시 함께 테스트 될 수 있도록 해야 합니다.

결론은 반복적인 테스트 케이스는 최대한 시나리오 케이스로 설계/작성하여 테스트를 자동화하고, 소프트웨어 생명주기가 진행되면서 변경/개선되는 점에 대해 테스트 전문가가 이를 분석할 수 있어야 합니다. 또한, 탐색적 테스트 시간을 최대한 확보하고 수행하여 새로운 결함을 발견할 수 있도록 테스트를 수행한다면 살충제 패러독스에 빠지지 않을 것이라 생각합니다.

6. 테스트 케이스 리뷰는 어떻게 해야 하나요?

필자들은 살충제 패러독스에 빠지지 않기 위한 방법으로 테스트 전문가의 테스트 케이스 효율적 관리를 언급했었습니다. 테스트 케이스를 효율적으로 관리하기 위한 방법으로 테스트 케이스의 리뷰가 있습니다.

리뷰란 주요 개발 단계 완료 시 단계 완료를 공식적으로 인정하는 행위이며, 우리말로는 '검토'정도가 되지만 실제로는 검토회(의) 정도의 공식적인 행사로 이해하는 게 좋습니다. 그리고 테스트 케이스는 개발의 산출물이며 리뷰의 대상이 됩니다.

필자의 경험상 테스트 케이스의 리뷰의 시점은 2가지 정도 있습니다.

첫 번째는 요구 검증을 하기 전, 요구 명세서나 기능 명세서, 혹은 화면 설계서를 베이스로 테스트 케이스를 작성했을 때입니다. 이때는 테스트 케이스에 요구사항을 누락하지 않았는지를 주목적으로 리뷰하게 됩니다. 운이 좋다면 화면 설계서 내에 요구사항 누락과 예외 케이스 등을 발견할 수 있는 시간이 됩니다.

두 번째는 모든 테스트가 완료되고, 제품/상품/서비스가 출시된 이후입니다. 발견된 결함을 바탕으로 왜 결함을 발견하지 못하였으며, 어떤 부분에서 테스트 케이스를 작성하지 않아서 결함이 발견되었는지를 리뷰합니다. 이때는 결함에 관련된 테스트 케이스가 추가될 수도 있고, 소스 코드에 테스트 코드를 삽입할 수도 있으며, 화면 설계서를 수정하여 향후 개발 목록으로 작성되는 경우도 있습니다.

예외적으로 테스트 중에 테스트 케이스를 리뷰할 수도 있습니다. 방법은 두 번째 알려드린 리뷰의 방법이 되겠지만 현실적으로 시간과 인력이 부족하기 때문에 테스트 중에 테스트 케이스의 리뷰는 불가능하다고 생각하시는 게 좋습니다. 테스트 외주업체를 이용하여 테스트를 진행하는 경우는 당연히 그들이 작성한 테스트 케이스를 리뷰해야 하며, 이것은 보통 첫 번째 목적으로 요구사항이 누락되지는 않았는지 혹은 테스트를 수행하기에 효율적으로 설계되었는지를 리뷰를 하는 경우도 있습니다.