[Episode 2/2] 소프트웨어 테스팅의 7가지 원리에 대해 설명해 줄 수 있나요?

질문

소프트웨어 테스팅의 7가지 원리에 대해서 설명해 줄 수 있나요?

ISTQB 버전

ISTQB Syllabus 2018

답변

본 글은 「소프트웨어 테스팅의 7가지 원리」에 대해 설명하지만, 글이 너무 길어져 2개로 나누어 구성하였습니다. 현재 보고 계시는 글은 Episode 2편이며, 원리 4~7까지를 설명합니다. Episode 1편에서 나머지 1~3을 설명하고 있으니 해당 부분도 함께 참고하여 주세요.

4. 결함은 집중된다.

Defects cluster together

흔히 「80-20 법칙」이라도 불리는 「파레토 법칙」은 "전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상"을 말합니다. 대부분의 일들이 전반에 걸쳐서 고루고루 나타나는 것이 아니라 어느 한곳에 집중되어서 발생함을 의미합니다. 단순히 소프트웨어에만 적용되는 법칙은 아닙니다. 이 법칙은 "20%의 고객이 백화점 전체 매출의 80%에 해당하는 만큼 쇼핑한다"라는 식으로 이미 다양한 연구결과와 통계를 통해 이 세상 전반적으로 적용됨이 증명되어 있습니다.

이를 소프트웨어 테스팅에 적용해 보면 "모든 문제의 80%는 20%의 모듈에서 발생한다"라고 표현할 수 있습니다. 발생하는 문제점들이 제품 전반에 걸쳐서 고르게 발생하는 것이 아니라, 대부분의 문제점들이 특정 모듈에서 발생하고 있다는 의미이며 이 모듈은 특정 기능이나, 특정 소스 코드가 될 수 있습니다.

이렇게 집중되는 현상은 설계의 문제일 수도 있고, 프로그래머의 문제일 수도 있으며, 레거시(Legacy)에서 발생하는 문제일 수도 있습니다. 이런 오류 집중도 현상은 특히 크고 복잡한 시스템에서 잘 나타나며, 기존의 코드를 그대로 가져와서 쓸 경우, 자주 수정되고 있는 기능 중 관련된 신규 기능이라던지, 3rd party와 연동되는 부분에서 더욱 도드라지게 잘 나타납니다. 필자의 경험으로 보면 시나리오가 잘 정의되어 있지 않은 신규 기능, 복잡한 시나리오를 가지고 있는 기능, 특정 개발자가 만든 소스 등에서 많은 문제점이 발생하는 경향이 있었습니다.

만약 우리가 이렇게 집중되는 부분을 미리 파악할 수 있다면 어떨까요? 아마 관련 기능에 대해서 좀 더 꼼꼼하게 살펴보고 시간과 비용을 투자하여 더 많은 문제점들을 찾아내 고객에게 전달되지 않도록 미연에 방지할 수 있게 될 겁니다. 이렇게 오류가 집중되는 특징을 잘 파악하면 소프트웨어 개발 진행 중 현재 시점, 현재 단계에서 우리가 맞닥뜨린 리스크(Risk)가 무엇인지 파악을 하는데 도움이 될 것이고 그것을 바탕으로 테스트 계획을 수립/수정하는데 도움이 될 수 있습니다. 또, 어떤 업무에 중점을 둬야 하는지에 대한 우선순위도 세울 수 있을 것입니다.

다만, 테스트 전문가 관점에서는 문제점들을 많이 찾아낸다고 일을 잘하는 것과 비례한다고 보기는 힘들 수도 있습니다. 하나의 소스 코드를 여러 곳에서 사용하고 있거나, 3rd party 연동하는 부분이 문제가 있다고 확인된 경우에는 그 부분과 관련된 테스트 케이스를 수행 시 모두 실패(Fail) 처리가 될 수도 있기 때문입니다. 그런 상황에서는 많은 문제점들을 발견을 해도 큰 의미가 없으며, 오히려 "설계 단계에서의 리뷰로 해당 문제를 해결하지 못했음에 대한 해결책"을 마련을 하거나 관련 테스트를 당장 하지 않고 수정된 이후로 미루거나 따로 표시를 해 놓아야 합니다.

그리고 그렇게 Testing 활동으로부터 얻어낸 데이터로 프로세스를 개선하는 활동들을 우리는 QA(Quality Assurance)라고 합니다.

[ 필자 주 ] QA와 Testing은 다릅니다. Testing만 하면서 QA라고 하지 마세요.

5. 살충제 패러독스에 유의하라

Beware of the pesticide paradox

[TV series] 체르노빌 - (본 드라마와 글이 관련은 없습니다. 이미지가 잘 맞아서 선택했습니다.)

「살충제 패러독스」란 말은, Boris Beizer의 저서 "Software Testing Techniques(1990)"에 처음 등장하였습니다. Boris는 이 책에서 "테스트를 하면 할수록 테스트에 면역이 되는 현상"을 설명하기 위해 Pesticide paradox(살충제 패러독스)라는 용어를 처음 사용한 것으로 알려져 있습니다. 이는 소프트웨어에서만이 아니라, 우리 실생활에서 나타나는 일입니다. 모기나 개미, 바퀴벌레 같은 해충을 죽이기 위해 만들어진 살충제가 처음 사용 시에는 효과가 잘 나타나지만, 지속적으로 사용하게 되면 해충들이 이 살충제에 대한 내성이 조금씩 생기고 나중에는 동일한 살충제로 해충을 죽일 수 없게 되는 현상을 확인할 수 있습니다. 여기서 유래한 말을 소프트웨어 환경에 차용하였습니다.

즉, 동일한 테스트 케이스를 이용해서 반복적으로 소프트웨어 제품을 테스트한다면, 처음에는 문제점들을 많이 발견할 수 있겠지만, 그 문제점들을 보완한 후에는 더 이상 아무런 문제점도 찾을 수 없게 됩니다. 그런데 그건 소프트웨어 개발이 잘 되어서라기 보다, 바로 동일한 테스트 케이스를 반복해서 사용하기 때문이라는 의미인데 이것이 「살충제 패러독스」입니다. 실제로는 잔존하거나 새로운 문제점들이 있을 수 있는데, 동일한 테스트 케이스로는 더 이상 문제점을 찾을 수 없게 되고, "문제점이 발견되지 않았으니 이제 괜찮구나"라고 착각하게 되는 큰 실수를 범할 수 있게 됩니다.

이를 방지하기 위해서는 요구사항과 설계를 리뷰할 수 있어야 하고, 동시에 테스트 케이스에 대한 리뷰와 개선도 진행해야 합니다.

일반적으로 테스트 전문가들이 「테스트 케이스 작성/수정 일정」을 수립하면 개발팀 내에서 '쓸데없는 시간' 취급을 받으며 저항을 받는 경우들이 자주 있는데, 사실 요구사항이 변경되면 테스트 케이스도 당연히 변경이 되어야 하고, 시나리오가 변경되면 그에 따라 테스트 케이스도 변경되어야 합니다. 또, 테스트를 수행하다 보니 더 나은 테스트 방법이 있다면 당연히 이에 대한 내용도 반영되어야 합니다.

세상 모든 일이 마음처럼 한 번에 끝나지 않듯이 테스트 케이스도 지속적으로 확인하고 수정하고 보완해 나가야 합니다. 지속적으로 부족했던 부분에 대해 보완하고, 테스트 기준과 테스트 시나리오에 대해 검토하고 확인해야 합니다. 그렇게 지속적으로 보완하고 수정해 나가야 살충제 패러독스에 빠지지 않을 수 있습니다.

[ 필자 주 ] 사업 진행 담당자는 「사업 기획서」로 소프트웨어를 「개발」하고,
프로그래머는 「코드」로 소프트웨어를 「개발」하며,
테스트 전문가는 「테스트 케이스」로 소프트웨어를 「개발」합니다.

누구의 업무도 덜 소중하다거나, 더 소중하지 않습니다. 그런 착시 현상에서 벗어나야 품질이 향상됩니다.

6. 테스트는 정황에 의존적이다.

Testing is context dependent

정황이라는 단어의 국어사전을 찾아보면 「일의 사정과 상황」을 의미한다고 나옵니다. 소프트웨어의 현상에는 정황(Context)이 존재하는데, 소프트웨어를 테스트하는 경우 대상이 되는 제품이나 프로젝트에 일괄적으로 동일한 테스트 접근법을 쓰는 것이 아니라, 그 제품에서 발생할 수 있는 상황에 맞는 테스트를 해야 한다는 의미입니다.

예를 들어, 자동차에 들어가는 제품을 테스트한다고 가정했을 때, 가장 중요시하게 봐야 하는 요소는 당연히 「사용자의 안전」입니다. 사고가 나게 되면 탑승자의 생명이 위험해질 수도 있기 때문입니다. 우리가 흔히 사용하는 스마트폰의 앱 중 하나가 문제가 생겨 멈춰버릴 경우에는 단순히 그 앱을 재구동을 하면 되지만, 자동차에 들어가는 제품이 오동작으로 멈춰버릴 경우는 사용자의 생명과 직결될 수 있기 때문에 절대로 일어나지 않도록 안전장치를 해야 합니다.

특히 앞으로의 자율 주행 시대에는 자동차는 사람이 운전하는 기계장치가 아니라 기계가 운전해주는 개인 공간으로 변해갈 것이고, 지금 보다 많은 소프트웨어들이 자동차에서 많은 역할을 수행할 것입니다. 이미 자율 주행이 아니더라도 많은 부분에서 소프트웨어를 통해 장치들을 제어하고 있습니다.

내비게이션으로 경로 검색을 하다가 갑자기 네비가 멈춰버리고 응답이 없는데, 다른 기기도 이에 영향을 받아 전혀 동작하지 않는다면? 운전을 하는데 우회전을 하기 위해 우측 방향지시등을 켜면서 브레이크를 살짝 밟아 속도를 줄이고 이내 핸들을 오른쪽으로 꺾었는데, 갑자기 뭔가 튀어나와서 자동제어 장치가 동작할 경우에는 어떤 기능이 어떻게 어떤 우선순위로 동작해야 할까요? 바로 이렇게 제품에서 발생할 수 있는 상황과 정황을 고려하여 테스트 기준을 수립하고 진행해야 한다는 것이 테스트의 정황과 관련된 이야기입니다.

이와 다르게 쇼핑몰 앱을 테스트한다고 가정했을 때, 가장 중요시하게 봐야 할 것 중에 하나는 결제 기능이겠습니다. 자동차에 들어가는 소프트웨어와 다르게 쇼핑몰 앱이 멈춰버리는 경우 어느 정도 문제가 되겠지만, 자동차가 주행 중 갑자기 멈추는 등과 같이 사용자의 안전과 직결되지는 않습니다. 하지만, 돈이 왔다 갔다 하는 결제와 연관이 될 경우는 큰 문제가 될 수 있습니다. 사용자가 물건을 선택할 수 없는 오류라면 문제는 되어도 손해가 나지는 않겠으나, 물건은 내보냈는데 결제가 되지 않아 수입을 창출할 수 없다면 그건 기업의 존폐로 이어질 겁니다. PG(Payment Gateway)사와 연동이 안되거나, 결제는 되었는데 금액이 잘못되거나 하는 등의 문제가 발생할 경우는 기업에 엄청난 손해를 끼칠 수 있는 중요한 부분이기 때문에 이 부분에 중점을 두고 테스트를 해야 할 것입니다.

모든 소프트웨어의 현상에는 정황이 존재하기 때문에 테스트하려는 제품이 어떤 도메인의 제품이고, 해당 도메인에서의 중요한 정황이 무엇인지를 파악하고, 그에 맞게 테스트 계획을 세우고 진행해야 합니다. 그것이 바로 「테스트는 정황에 의존적이다.」라는 의미입니다.

[ 필자 주 ] 한국에서 유명한 소프트웨어 테스팅 자격증은 ISTQB에서 주관하는 ISTQB 시리즈와 TTA에서 주관하는 CSTS가 있습니다. 이 두 개는 약간 결이 다른데, 단순한 필자의 주석으로 설명하기에는 너무 길어지니 기회가 있을 때 필자들의 블로그에서 다루겠습니다.

이렇게 결이 다른 또 하나의 거대한 "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/

언젠가 필자들이 본 블로그의 다른 프로젝트에서 위 인물들과 그들의 블로그에 기재된 내용이 실무에 어떤 식으로 활용되는 지에 대해 설명할 예정입니다.

7. 오류가 부재함은 궤변이다

Absence-of-errors is a fallacy

앞서 설명한 1번, 2번의 테스팅 원리에서 살펴보았듯이 오류가 존재하지 않게 테스트하거나 완벽한 테스팅을 하는 건 불가능합니다. 다양한 테스트를 통해 많은 문제점을 발견하고, 이를 다 수정한 후 더 이상 문제점 발견되지 않았다고 완벽한 제품을 개발했다는 의미는 될 수가 없습니다.

아주 간단한 기능만 가진 소프트웨어라고 해서 문제점이 전혀 없는 것은 아니며, 미처 발견하지 못한 문제점이 존재할 수도 있습니다. 혹은 사용자의 「기획 개선 의견」이 발생할 수도 있고, 문제점을 모두 수정해서 출시하더라도 사용자들에게 매력적이지 못해 어필하지 못할 수도 있고, 사용성이 너무 불편해서 외면받을 수 있고, 경쟁사 제품이 더 좋아서 인기가 없을 수도 있고 등등 여러 가지 다양한 이유로 성공하지 못할 수도 있습니다. 모든 점에 앞서 소프트웨어는 하드웨어 위에서 작동하기 때문에 하드웨어의 변수를 완전히 제거할 수 없습니다.

[ 필자 주 ] 실-예로 2021년 2월 20일, AWS 데이터 센터에서 냉각 유닛 정전이 발생하여 관련 시스템을 이용하는 수많은 소프트웨어 서비스들의 서비스가 중단되는 사건이 발생하였습니다. 소프트웨어는 하드웨어 의존성이 높습니다.

그러니 수많은 문제점들을 발견하고 그것들을 모두 보완했다고 해서 성공한 소프트웨어라고 생각하는 건 잘못된 착각입니다. 문제점이 적게 발견된다고 좋은 것이 아니라, 적게 나오는 현상에 대해 다른 문제가 있어서 적게 발견되고 있지는 않은지 경계해야 합니다. 지금 우리의 제품이 고객의 요구사항에 맞게 개발되고 있는지, 사용자의 관점에서 부족한 점은 없는지 등등 다양한 환경과 변수에 대해 고민하고 해결해야 성공적인 프로젝트가 될 수 있습니다.

「소프트웨어 테스팅의 7가지 원리」 Episode 2에 대한 필자들의 담론

※ 참고 : 본 포스팅에 대한 필자들의 주관적 의견입니다.

ISTQB에서 정리하여 발표한 「소프트웨어 테스팅의 7가지 원리」는 얼핏 보면 이론적으로 보이지만 사실은 현실 업무에서 발생하고 있는 여러 가지 기본적인 미흡한 인식들, 오해들에 대해 짚어내고 있다고 보는 쪽이 더 옳을 거 같습니다.

① 우리 회사의 성실한 테스트 전문가들이 수행한 테스트 한 번 통과했으면 문제가 없을 거라는 오해

② 제품/서비스 배포 후 오류가 발생하면, 이유를 찾기보다 테스트 담당자를 원망하는 테스트 활동에 대한 인식 부족

③ 개발 일정 중 테스트 케이스 작성 시간을 별도로 확보하지 못해서 생기는 연장 근로

④ 테스트 케이스는 금방 만드는 거 아니냐고 생각하는 인식 부족

⑤ 제품 내 여러 군데를 평등하게 평균적으로 보면 평균 이상의 품질을 확보할 것이라는 오해

이런 것들은 현실 업무에서 실제로 발생했을 때 실무자들이 경영진이나 관리자들을 설득시키기에 쉽지 않습니다. 그렇기에 테스팅 지식을 정리하고 편찬하는 ISTQB의 저명한 전문가들이 「소프트웨어 테스팅의 7가지 원리」를 정리한 것이 아닐까 싶습니다.

필자들 역시 이런 테스팅 수행 작업에 대한 일반론적이고 당연한 원리와 이야기들을 지속해 나아가, 소프트웨어에서 테스팅 활동의 중요성을 인식시키고, 고취시키려 이 블로그의 포스팅들을 작성 중입니다.

참여자 정보

•작성자 : Bykj, 천년나무

•검토한이 : 아이티마니, 품생품사, 현의노래

블로그 내의 관련 글

소프트웨어 테스팅의 7가지 원리에 대해 설명해 줄 수 있나요? (Episode 1/2)

목차 질문 소프트웨어 테스팅의 7가지 원리에 대해서 설명해 줄 수 있나요? ISTQB 버전 ISTQB Syllabus 2018 답변 본 글은 「소프트웨어 테스팅의 7가지 원리」에 대해 설명하지만, 글이 너무 길어져 2개

softwaretestingreference.tistory.com

테스팅 원리[4] - “결함 집중”이라는 말은 적은 수의 모듈에서 대다수의 결함이 발견된다고 나

목차 질문 테스팅 원리[4] - “결함 집중”이라는 말은 적은 수의 모듈에서 대다수의 결함이 발견된다고 나와 있는데요, 그럼 해당 부분만 집중적으로 고치면 해결되는 건가요? ISTQB 버전 ISTQB Syll

softwaretestingreference.tistory.com

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다. 개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.

[팀블로그] 소프트웨어 테스팅 참고서