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

질문

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

ISTQB 버전

ISTQB Syllabus 2018

답변

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

「소프트웨어 테스팅의 7가지 원리」의 출처는 어디일까?

ISTQB를 공부하다 보면, 그리고 소프트웨어 테스팅 관련된 지식들을 학습하다 보면 여기저기의 블로그나 커뮤니티에 「소프트웨어 테스팅의 7가지 원리」에 대해 꽤나 자주 언급되곤 합니다. 대체 이건 어디에서 시작된 걸까요? 알아도 쓸데없는 신박한 이야기를 간단히 짚어 보겠습니다.

우리가 알고 있는 「소프트웨어 테스팅의 7가지 원리」는 아래의 그림 한 장으로 표현할 수 있습니다.

이 내용은 사실 「International Software Testing Qualifications Board, 국제 소프트웨어 테스팅 자격 협회」에서 발표한 내용입니다. 이 기관의 이름을 줄여 우리는 ISTQB라고 부릅니다. ISTQB의 활동은 꽤나 오래되었지만, 정식으로 협회를 등록하고 Board Member(이사회)가 꾸려진 것은 2002년입니다. 이 Board Memebr들은 전 세계 유수의 (당시에는) 최첨단 프로젝트들인 우주, 항공, 군사 등 전 세계의 최고 수준의 프로젝트에 참여했던 소프트웨어 테스팅 분야의 거장들이 참여하게 됩니다. 이 ISTQB 협회의 거장들이 모여 소프트웨어 지식 체계를 연구하고, 자격증을 개발하는 과정에서 정리한 내용이 「소프트웨어 테스팅의 7가지 원리」입니다.

ISTQB가 지식 체계를 정리하는 과정과 관련된 간략한 역사는 [특별기고] ISTQB는 어디에서 왔을까?를 참고해 주세요.

이 분들은 왜 갑자기 "원리"를 만들었을까요? 그 역사는 1979년 Art of Software Testing으로 거슬러 올라갑니다. '소프트웨어 테스팅의 원리'를 영어로 하면 'Software Testing Principles'인데, 이를 Google에서 검색하면 이 포스트에서 소개하는 내용 외에도 2가지 정도가 더 검색될 겁니다. 본문과는 관련이 없으므로, 「숨김/펼치기」 기능으로 넣어 두었습니다. 자세한 내용은 ISTQB 내용과는 관련이 없으니 참고만 해 주세요.

1. 1979년 발간된 Glenford J. Myers의 The Art of Software Testing의 내용 (2004년 재-발간)

• 한국에서는 「소프트웨어 테스팅의 정석」이라는 이름으로 출간되어 있음.

• 제2장에 「소프트웨어 테스팅 원칙」이 소개되어 있으며, 아래 내용은 도서의 내용을 참고함.

• 원칙 1 : 테스트 케이스의 필요한 부분은 예상 출력이나 결과에 대한 정의다.

• 원칙 2 : 프로그래머는 자신의 프로그램 테스트를 피해야 한다.

• 원칙 3 : 프로그래밍 조직은 자신들의 프로그램을 테스트하지 말아야 한다.

• 원칙 4 : 테스트 결과를 철저하게 조사해야 한다.

• 원칙 5 : 유효하고 예상 가능한 입력 조건에 대한 테스트 케이스 작성은 물론, 예상치 못한 무효한 입력 조건에 대해서도 테스트 케이스를 작성해야 한다.

• 원칙 6 : 프로그램이 해야 할 것을 하지 않는지에 대한 조사도 중요하지만, 프로그램이 하지 말아야 할 것까지 하는지도 찾아내야 한다.

• 원칙 7 : 한 번 사용하고 버리는 프로그램이 아니라면, 사용하고 버리는 테스트 케이스를 만들어서는 안 된다.

• 원칙 8 : 에러를 발견하지 못할 것이라는 암묵적인 합의 하에 테스트 수행 계획을 작성하면 안 된다.

• 원칙 9 : 프로그램의 한 섹션에 많은 에러가 있을 가능성은 그 섹션에서 발견된 에러 수에 비례한다.

• 원리 10 : 테스팅은 극도로 창의적이고 지적인 도전이다.

2. 2008년 IEEE Xplore 저널에 발표된 Bertrand Meyer의 Seven Principles of Software Testing

• 다음의 내용은 저널에 게재된 내용을 일부 발췌하여 필자들이 번역한 내용입니다. 의역이 들어가 있습니다.

• 원칙 1 : 정의 - 프로그램을 테스트함은 그것이 실패할 수 있음을 보이는 것이다.

• 원칙 2 : 테스트와 사양의 관계 - 테스트는 사양의 부족함을 대체하지 않는다.

• 원칙 3 : 회귀 테스팅 - 테스트 도중 실패한 부분에 대해서는 반드시 테스트 케이스를 생성하여 영구적으로 테스트할 수 있도록 해야 한다.

• 원칙 4 : 테스트 결과의 근거 적용 - 테스트의 성공/실패를 정의하는 자동화된 프로세스가 존재해야 한다.

• 원칙 5 : 수동/자동 테스트 케이스 - 효과적인 테스트 프로세스를 위해서는 생성한 테스트 케이스에 대한 수동/자동 테스트 모두가 포함되어야 한다.

• 원칙 6 : 테스트 전략의 경험적 평가 - 테스트 전략을 평가하되 원칙에 기반하여 평가해야 한다. 이는 재현 가능한 테스트 프로세스에서 명시적인 기준을 이용해 객관적으로 평가함을 의미한다.
• 원칙 7 : 평가 기준 - 테스트 전략의 가장 중요한 속성 중 하나는 시간의 흐름에 따라 발견되는 결함의 수를 평가해야 함이다.

1. 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다

Testing shows the presence of defects, not their absence

대한민국에 있는 테스터들은 오늘도 다양한 테스트를 통해 테스트 대상 제품에 문제가 있는지를 확인하고 있습니다. 결함을 찾음으로써 희열을 느끼기도 하고, 보람을 느끼기도 하면서 내가 기계라는 꿈을 꾸는지, 기계가 나라는 인간의 꿈을 꾸는 건지 모를 만큼 반복적인 테스트를 하기도 하면서 제품 내 결함이 없음을 확인하려 합니다.

이렇게 피-땀-눈물(Feat. BTS) 흘려서 테스트 케이스에 FAIL이 없어야 끝나는 테스팅인데... 아니, 이 테스팅이라는 게 결함이 없음을 밝히는 활동이 아니라고요? (이.. 이게 머선 129? @.@)

일반적으로 소프트웨어 기업에서 테스트 전문가들이 하는 일은 이렇습니다. 소프트웨어 제품이 고객의 요구사항에 부합하는지 확인하고, 예상과 다르게 동작하는 부분들이 없는지 확인하고, 사용자 시나리오 관점에서 특이사항이 없는지 확인하고, 가혹한 환경에서도 문제가 없는지 확인하는 등 다양한 테스팅 활동을 통해 문제점이 없는 지를 확인합니다. 테스트의 목적 중 가장 큰 목적 중 하나는 이러한 제품 내 문제점이 잔존하지 않는지를 확인하고자 하기 위함이고, 테스트 전문가들은 이런 활동을 통해 발견된 문제점들을 수정/보완해서 더 나은 제품이 될 수 있도록 합니다.

하지만 혼신의 힘을 다해 심혈을 기울여 테스트를 거쳐서 나갔기에 '이건 완벽해'라고 자부했던 제품들이 필드에 나간 후 또는 고객에 전달된 후 문제점이 발견되었다고 하는 리포트를 받아본 적이 자주 있을 겁니다. 아직까지 없었다면 앞으로 많으실 것입니다. 심지어 알고 있지만 수정하지 않았던 문제가 아니라 완전히 새로운 문제들이 발생한다는 점을 발견하시게 될 겁니다. 전혀 예상치 못한 경로를 통해 발생하거나 로또 확률 정도로 발생할 것 같았던 일들이 빈번히 발생하기도 하고, 전혀 예상치 못한 사용 환경으로 인해 발생하기도 하는 등 다양한 이슈들이 무수히 발생합니다. 우리는 버그가 아니라고 믿고 싶지만, 사용자 입장에서는 "이건 왜 이런 거야? 뭐 이래? 라며" '기획 자체가 잘못된 이슈'가 발생하여 보고될 수도 있습니다. (이런 이슈가 발생하지 않는다면 그건 아마 잘 안 팔리거나 잘 사용하지 않는 제품일 겁니다!)

누군가 여러분께 와서 "이렇게 하면 개발하는 제품에 결함이 없어진다" 라거나 "이 방법론을 쓰면 품질이 높아진다" 라며 자신하는 사람이 있다면 그 사람은 사기꾼일 가능성이 높습니다. 반드시 피하셔야 됩니다!!!

요구사항에 대한 이야기를 해야 합니다. 실무에서 테스트 전문가들이 하는 업무를 조금 더 구체적으로 살펴보면 아래와 같습니다.

① 사업은 수익을 내려고 함을 목적으로 합니다. 쉽게 말해 '돈 벌려고' 하는 행위입니다.

② 그래서 수익을 내기 위한 "사업 요구사항"이라는 게 발생합니다.

③ 요구사항 중 소프트웨어와 관련된 부분은 "소프트웨어 요구사항"과 "소프트웨어 시스템 설계", 그리고 "소프트웨어 기획"을 작성하게 됩니다.

④ 테스트 전문가들은 요구사항, 설계, 기획을 기반으로 사업의 목적에 맞게 "어떤 테스트가 이 제품에서 PASS/FAIL인가에 대한 기준을 수립"합니다. (참고로 이런 성공/실패의 기준을 보고 Test Oracle이라고 합니다. ISTQB 공부하시다 보면 갑자기 튀어나오는 Oracle이라는 용어가 이걸 의미합니다.)

⑤ 그리고 프로그래밍과 테스팅을 수행합니다. 이런 행위를 "개발(Development)"이라 부릅니다. (테스트 전문가도 개발자입니다.)

이렇게 사업에 필요한 일련의 소프트웨어 개발 과정이 발생하는데요, 위의 3번 과정에서부터 소프트웨어 테스팅이 시작됩니다. 여기에서 문제는 시장의 흐름, 사용자들의 요구는 지속적으로 변화하기 때문에 "100점짜리 사업 요구사항"은 존재할 수 없습니다. 인류가 답을 못 찾은 게 아니라 그냥 불가능한 일입니다.

따라서 수학 공식인 "피타고라스의 정리"는 증명이 가능하지만, 소프트웨어 제품 내 "결함이 없음"은 증명이 불가능합니다. 애초에 사업 요구사항이 완벽할 수 없기 때문에 뒤따라 오는 모든 기준들은 앞의 결정에서 변경되는 폭의 2 배수, 3 배수, 10 배수만큼 다양하게 변경되기 때문입니다.

• 그래서 가능한 빠르게 투입하는 테스팅(Early Testing)이 중요하다는 원칙이 발생합니다.
• 그리고 이런 점은 뒤에 나오는 "완벽한 테스팅은 불가능하다"와도 연관되어 있습니다.

그럼 어차피 오류가 나올 텐데 테스트를 왜 하느냐고 반문하신다면 위의 설명을 절반만 이해하신 겁니다.

사업 요구사항은 100점짜리가 있을 수 없기 때문에 "소프트웨어가 어떤 식으로 작동해야 사업의 목적에 맞는가에 대한 기준"은 테스트 전문가들이 수립하고, 확인합니다. 그러니 테스트를 수행함은 "이 소프트웨어에서 이런 이슈들이 있었고, 적어도 이런 이슈들은 다시 발생하지 않을 것입니다."를 증명하는 활동이 소프트웨어 테스팅 활동이라고 이해하시면 됩니다.

[ 필자 주 ] 오늘도 여러분들은 테스트 전문가로서 제품 내 문제점이 1도 존재하지 않는 제품을 만들기 위해 테스트하고 있는 것이 아니지만, 테스트를 설계/준비/수행/마무리하시면서 좀 더 완성도가 높은 제품을 만드는데 기여하고 계십니다.

2. 완벽한 테스팅은 불가능하다.

Exhaustive testing is impossible

완벽한 테스팅이란 말 그대로 흠잡을 수가 없는, 모든 요구사항/기능에 대해 모든 경우의 수를 다 고려해서 테스트하는 것을 의미합니다. 과연 우리는 모든 경우의 수를 확인해서 테스트할 수 있을까요?

예를 하나 들어 설명하겠습니다. 우리가 채팅앱을 하나 테스트해 본다고 가정해 봅시다. 먼저 채팅 기능에 대해서 테스트를 해보려고 계획을 세워보겠습니다.

1. 메시지의 형태
- 텍스트, 사진, 동영상, 링크 등등 가능
1.1 텍스트의 종류
- 영어, 한국어, 숫자, 특수문자, 일본어, 중국어 등등
1.2 사진 파일의 속성
- 확장자(jpg, gif 등등)
- 사이즈, 해상도
- 파일명(영어, 한국어 등등)
1.3 동영상 파일의 속성
- 확장자(avi, mov 등등)
- 코덱(음성/비디오), 해상도
- 파일명(영어, 한국어 등등)
1.4 링크의 형태
- http, https, ftp 등등

이 글을 쓰기 위한 목적으로 「메시지」에 관련한 부분에 대해서만 대략적으로 적어본 내용이 이 정도입니다. 정식으로 해당 내용들에 대해 기획을 하려고 들면 훨씬 다양하고 세부적인 항목들이 도출될 겁니다.

테스트 전문가들이 "완벽함"을 추구하려 한다면, 각 항목 별로 모든 항목에 대해서 테스트를 해야 완벽한 테스팅이 가능할 것입니다. 그런데 파일명만 하더라도 한 가지 언어로만 존재하지 않습니다. 파일명에 영어/한국어를 같이 사용할 수도 있고, 영어/특수문자/일본어 등등 다양한 조합이 가능합니다. 또, 파일명의 길이 등도 문제가 될 수 있습니다.

이 모든 조합을 다 고려해서 테스트를 해야 할 텐데 이 조합의 경우의 수만 해도 세기 힘들 정도이므로, 모든 경우에 대한 테스트는 불가능에 가깝습니다.

"엄청나게 스펙을 좁게 제한을 하거나, 중요한 부분만 고르면 모든 조합이 테스트 가능하지 않느냐?"라고 물어보신다면, 테스트 전문가들의 입장에서는 "아직 테스트에 대해 잘 모르시는 거 같습니다. 여기서 끝나는 것이 아닙니다."라고 답을 드려야 합니다.

이를 짧게 설명하기 위해 이번에는 이 채팅앱의 지원 OS에 대해 알아볼까요?

이번 예시의 가상 앱은 아직 신규 출시 전이라 사람들이 많이 사용하고 있는 Andorid만 지원하기로 했다고 제한을 둬 봅시다. 스펙을 엄청나게 줄였죠. OS를 1개로 결정했으니까요.

그럼 이제 수많은 안드로이드 버전 중에 어느 버전부터 지원을 하고 있는지부터 확인해야 합니다. 2021년 기준으로 아직 많이 사용하고 있는 Android 8.0(오레오)부터 지원한다고 가정해 봅니다. 시중에 판매되고 있는 Android 8.0이 설치된 스마트폰은 어떤 것들이 있을까요? 나무 위키(안드로이드 오레오 적용 기기)에 따르면 대략 아래와 같습니다.

구글 픽셀 2, 구글 픽셀 2 XL ...
삼성전자 갤럭시 S9/S9+, 갤럭시 A6, A7 ...
LG G7 Thinq, G7+ Thinq, V35, ...
샤오미 Mi A1, 6, ...
소니, 레노버 등등

와~ 위 목록의 폰들만 하면 되네요. 휴, 그래도 우린 Android 8.0의 테스트를 끝마쳤네요. 그럼 이제 Android 9.0이 설치된 스마트폰들을 볼까요? 네? 뭐죠? Android 10.0도 있다굽쇼?

이 예시는 실제 실무에서 발생하는 문제입니다. Android 폰들의 특징은 제조 회사마다 조금씩 OS의 설정이나 화면 크기가 다르다 보니, 이 수많은 폰들을 일단 모두 구하는 것만도 쉬운 일이 아니며, 구할 수 있다고 해도 모든 폰에 설치해서 테스트를 하고 출시하려면 거의 무한대에 가까운 시간이 필요하게 될 겁니다.

각 OS 별로 다른 부분들이 얼마나 많고, 우리 제품에 얼마나 영향을 끼치는지를 확인하려면 모든 제조사별 하드웨어의 차이점을 이해해야 하고, 그에 맞게 소프트웨어도 변경이 되어야 하고 하드웨어 특성에 따라 영향받는 소프트웨어의 범위도 파악해야 합니다. 특정 회사에서 나오는 기기에서만 문제점이 발견되는 경우도 있기 때문입니다. 그래서 실제 실무에서는 보통 각 제조사별로 많이 사용되는 대표 기기 몇 개를 선정해서 그 기기들에서만 테스트를 진행합니다.

이밖에도 고려해야 할 상황은 많습니다. 이제 겨우 채팅만 보았는데, 그 외의 기능에 대해서 테스트도 해야 하고, 사용 시나리오 등등을 모든 경우의 수를 따져서 테스트를 할 수 있을까요? 그것은 마치 별을 세는 일과 같습니다. 엄청난 시간, 자원을 동원한다면 별을 셀 수는 있을 것 같은데 계속 변화하는 우주에서 정확하기는 할까요? 가능은 할까요? 그리고 과연 그게 의미는 있는 일일까요?

현실에서는 소프트웨어 내 존재할 수 있는 모든 오류 가능성에 대해 고려하기도 불가능에 가깝고, 모든 기능/비기능 조합에 대해 테스트를 하는 건 현실적으로 불가능합니다. 그래서 실무 진행 시에는 지원 대상을 한정시키거나 제약된 환경 안에서 효과적인 테스트를 테스트를 하기 위해 경우의 수를 효과적으로 줄이는 방법에 대해 고민하여 사용합니다. 현실적인 제약사항(시간/자원/인력 등)이 있기 때문에 현 단계에서 무엇이 중요한지, 현 상황에 어떤 리스크를 대비해야 하는지 확인하고, 우선순위를 세워 테스트를 진행하기도 합니다.

[ 필자 주 ] 테스트 전문가들과 프로그래머들은 상생 관계이지만, 대부분의 인간 관계가 그렇듯 서열이 생기기 쉽상입니다. 이를 적절히 잘 관리해서 서열이 잘 발생하지 않는 회사에 다니신다면 CTO님을 칭찬하시면 됩니다. 훌륭하신 분이니까요. 그러나 현실은 그렇지 않지요. CTO도 그냥 보통 사람입니다. 그냥 운이 좋아서 CTO가 되었을 뿐이죠.

그런데 그런 상황에서는 대부분 "개발팀 내 QA의 존재 이유"에 대한 도전을 받게 되는데, 단순히 프로그래머들의 테스팅 시간을 줄여준다는 식으로 오해되지 않도록, 제품의 특징과 테스팅 시 고려해야 할 부분들에 대해 어필하시면 좋습니다. 여러분들은 「테스팅 전문가」이십니다.

매니저 : 소프트웨어는 끝났나요?
프로그래머 : 소프트웨어에 끝남이란 없어요.

매니저 : 그럼 버그들 수정은 모두 끝난 거죠? 이제 문제없는 거죠?
프로그래머 : 앞으로 버그가 안 나올지에 대해 제가 알 방법은 없어요.

매니저 : 거짓말하는 방법을 안 배우시면 제가 님을 관리하기 어려울 거 같네요.
프로그래머 : 앗, 예, 소프트웨어 개발은 앞으로 2~3일 내에 완벽히 끝납니다.

3. 조기 테스팅으로 시간과 비용을 절약할 수 있다

Early testing saves time and money

"일찍 테스트를 하라"는 문장에서 "일찍"이라는 뜻은 소프트웨어 개발 라이프 사이클, SDLC(Software Development Life Cycle)에서 앞 단계를 의미하는 것으로 초기 개발 단계인 요구사항 분석 단계부터 테스트를 해야 한다는 의미이고, 이 단계에서의 테스트는 보통 준비(Planning) 단계에서의 요구사항이나 설계의 리뷰를 의미합니다.

Software Development LifeCycle - Strolve.com

쉽게 말하면 개발팀에서 프로그램을 다 만들고 난 후에 테스트하는 것이 아니라, 요구사항 분석부터 참여해서 리뷰도 하면서 개발을 시작하는 단계에서부터 참여하면 오류가 발생할 확률도 낮고, 수정 비용도 낮아진다라는 의미입니다.

굳이 왜 이렇게 앞 단계부터 해야 하는 걸까요? 그 이유는 바로 투입 시간과 투자 비용 때문입니다.

세계적인 물류 회사 「페덱스(Fedex)」에서 중요시한다고 알려진 품질 비용에 관련된 「1-10-100 법칙」이 있습니다. 문제가 발생하기 전 예방했을 때 지불해야 하는 비용이 1이라고 하면, 고객이 발견하기 전 수정하는데 필요한 비용은 10배가 발생하고, 고객이 문제 발생을 발견하여 수정해야 하는 경우 필요한 비용은 100배가 든다라는 뜻입니다. 즉, 미리 예방을 하면 나중에 들어가는 엄청나게 큰 비용(시간과 돈)을 지불하지 않아도 된다는 뜻입니다.

"우리 회사는 포괄 임금제라 사람만 갈아 넣으면 되는데요?"라는 생각이 드셨으면 그에 대해 답하는 건 너무 길어질 거 같아 모두 설명하기는 어렵지만, 위의 법칙에 대비하여 이렇게 말씀드려보겠습니다. 만약 문제를 발생시키지 않고 예방해서 효율을 10배, 100배 높일 수 있다면 어떤 선택을 하시겠습니까? 이는 「품질 관리」에 대한 이야기이라 본 블로그에서는 일단 이 정도의 질문을 던진 채 마감하겠습니다.

소프트웨어 개발과정에서 이를 적용해 본다면 대략 아래와 같습니다. 아래는 예시이니 너무 심각히 받아들이지 마시고, 대략적인 개념을 이해하시며 읽어 주세요.

• 가장 값싸게 해결 가능

일반적으로 초기 요구사항 및 설계 리뷰에 참석하는 사람들은 사업기획, 소프트웨어 설계(아키텍트) 분야의 전문가들이며, 팀 리더들도 참석하곤 합니다. 이 단계에서 문제점을 확인하고 수정할 수 있다면, 적은 수의 사람들만 설득하면 되고, 아직까지는 그다지 세부적이지 않은 문서들을 수정하게 됩니다. 이로써 간단하고, 빠르고, 간편하게 문제 수정이 가능합니다.

• 어느 정도 저렴하게 해결 가능

의사 결정된 사항들을 세부 기획으로 만들어 소프트웨어 개발팀에 나누어 줍니다. 기획자들도 정보를 보고, 프로그래머들도 정보를 접하고, 사용성 전문가인 디자이너들과 테스트 전문가들도 해당 정보를 분석하기 시작합니다. 이 과정에서 오류를 수정하면, 이 모든 인원들에게 정보 수정을 통지해야 하고, 이 모든 인원들의 시간을 다시 투자해야 합니다. 예를 들어, 총 10명의 팀원이 있는데 해당 내용을 파악하는 데에 각자 평균 2시간 씩을 사용했다면, 초기 정보 인식에 20시간 + 수정 내용 파악 20시간으로 총 40시간의 프로젝트 시간을 허비하게 됩니다.

• 이제부터 본격적으로 비싸지기 시작

개발을 진행하는 중 문제점들을 발견하거나, 사업 의사결정이 변경되어 수정하는 경우도 있을 수 있습니다. 이미 프로그래밍이 진행 중이고, 때로는 테스팅이 진행 중일 수 있습니다. TDD를 적용한 경우 잘 수행되고 있는 수많은 테스트 케이스들이 변경될 수도 있습니다. 그래서 결국 일정이 지연되고, 사업 가능성이 줄어드는 결과로 나타납니다. 개발 부서의 모든 인원들에게 변경을 알리지 못해 감정싸움이 발생하거나, 퇴사자 등 불만 인원과 이탈 인원이 발생할 가능성이 높아지는 건 덤이겠네요.

• 위험할 정도로 높은 비용으로 치달음

제품의 개발이 완료된 후 수정이 발생하게 되면 개발과정에서 투입한 많은 시간과 인력 비용을 다시 투자하여 개발해야 합니다. 만약 요구사항이 의도한 방향대로 구현되지 않았다면 그동안 들였던 비용은 모두 사라지는 꼴이 되고, 관련 사항에 대한 모든 투입 비용(프로그래밍 및 테스트에 투입한 시간, 인력 등)도 모두 공중으로 사라지게 될 것입니다. 올바르게 개발된 사항에 대해서 문제점이 발생한다면 테스트 및 이를 보고하는데 시간과 비용이 추가로 들게 되고, 그 문제점들을 확인하고 수정하는 시간 및 관련자들이 수정 방향에 대해 검토하는 동안의 인력과 시간에 대한 비용을 지불해야 합니다.

• 최고 수준의 지출을 감내해야 하는 상황

출시 후 단계에서 수정하게 되면 개발단계에서 수정하듯이 수정할 수는 없습니다. 이미 고객에게 출시되었기 때문입니다. 보완된 버전의 출시를 위해서는 앞에서 든 수정, 테스트 비용뿐만 아니라 일정을 산정하고, 수정 범위를 정하고, 영향도 등을 확인하여 많은 관련자들과 조율을 해야 합니다. 고객의 불만족 or 인기 하락, 기업의 신뢰도 저하 등 눈에 보이지 않는 무형의 가치들에 대한 비용도 지불해야 할 수밖에 없는 상황이 다가옵니다. (좀 더 자세한 설명에 대해서는 본 블로그의 다른 글인 "개발 초기에 테스팅을 시작하라" 글을 참고하세요)

물론 초기부터 테스트를 시작한다고 모든 문제가 값싸고 손쉽게 해결된다라는 의미는 아닙니다. 적어도 개발 공정의 앞단 프로세스에서 확인할 수 있는 문제들을 수정함으로 인해 추가적인 비용이 들지 않도록 사전에 방지할 수 있다는 의미입니다. 이렇게 비용(시간, 인력, 돈)을 적게 들이고, 절약된 비용으로 좀 더 중요한 사업 요구사항들에 집중할 여력을 가지게 되면 프로젝트의 성공 가능성을 높이고, 높은 품질을 유지하는 데에 도움이 된다는 의미입니다.

[ 필자 주 ] 하지만, 정작 실제 현실에서는 눈앞에 보이는 성가신 여러 문제들 때문에, 혹은 다른 여러 이유들이 많다 보니 개발 초기에 테스팅을 시작하지 못하고, 개발이 거의 끝난 시점부터 투입되어야 합니다.

이 글을 읽는 분들은 테스팅 활동을 일찍 시작해야 유리하다는 점을 아시고, 경영진들을 설득시켜 실무에서도 조금이라도 앞서 테스트를 하셨으면 하는 필자들의 개인적인 바람을 남겨 봅니다.

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

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

그러므로, 테스트 전문가들은 테스트에 들이는 투입 공수를 가능한 줄이고, 그러면서도 출시 후 문제가 덜 발생하도록 하는 임무를 수행해야 합니다.

TDD를 도입하기로 했고, 이를 테스트 전문가들이 아닌 프로그래머들이 수행하기로 했다고 가정해 보겠습니다. TDD 도입이 전반적인 「테스트 투입 공수」를 줄일 수 있는 시스템이라면, TDD를 수행할 사람들에 단위 테스트를 맡겨놓고, 테스트 전문가들은 통합 테스트 및 시스템 테스트 단계에서의 할 일들을 설계하는 등 사업 전반적인 관점에서 ROI를 향상하고 품질관리 활동을 수행함을 주요 업(業)으로 삼을 수 있겠습니다.

이와 관련한 자세한 이야기는 필요한 시점에 본 블로그의 필진들이 다시 한번 설명할 예정입니다.

참여자 정보

•작성자 : Bykj, 천년나무

•검토한이 : 아이티마니, 품생품사

블로그 내의 관련 글

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

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

softwaretestingreference.tistory.com

테스팅의 원리[3] - “개발 초기에 테스팅을 시작하라.” 라고하는데, 테스트는 개발이 완료된 후

목차 질문 원리[3]에는 “개발 초기에 테스팅을 시작하라.”라고 하는데, 테스트는 개발이 완료된 후에 하는 거 아닌가요? 테스팅을 어떻게 개발 초기에 시작하나요? ISTQB 버전 ISTQB Syllabus 2018 답

softwaretestingreference.tistory.com

STEEG 개인 의견

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

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