“품질 수준에 대한 자신감 획득”은 테스트 수행 후 버그가 없으면 좋은 품질이라고 확신할 수 있다는 의미인가요?

질문

ISTQB에서는 다양한 테스팅의 목적 중 하나로 “품질 수준에 대한 자신감 획득”이라는 말이 있는데, 테스트 수행 후 버그가 없으면 좋은 품질이라고 확신할 수 있다는 의미인가요?

ISTQB 버전

ISTQB Syllabus 2018

답변

테스팅을 해서 버그를 줄이면 품질이 올라간다?

우리는 흔히, 그리고 일반적으로 "테스팅을 수행해서 제품의 버그를 줄이면 품질이 올라간다."라고 착각하고 있습니다. 심지어 Software Testing을 오랜 시간 진행해온 경력자들도 이런 생각을 하고 있는 경우가 꽤 많습니다. 그렇다 보니 업계 전반적으로 "테스트 인력은 값싸고 낮은 경력을 많이 뽑아서 버그를 많이 찾으면 된다"라는 잘못된 인식이 퍼져 있어 필자들은 「테스트 전문가」로서 무척 마음이 아픕니다.

그래서 이번 포스팅에서는 그런 오해를 조금이나마 줄여드리는 데 필자들이 쓰는 글의 목적이 있습니다.

"테스팅을 해서 버그를 줄이면 품질이 올라가는가?"에 대한 대답은 뒤에서 설명하도록 하겠습니다. 먼저 짚고 넘어가야할 이야기들이 있거든요.

진짜 테스팅의 목적은 무엇일까요?

먼저 이 블로그의 다른 글인 소프트웨어 테스팅이란 무엇이며, 테스팅의 목표와 임무"는 무엇인가요? 에서 소개했던 내용을 다시 살펴봅시다. 국제 표준에 어떻게 쓰여 있고, 어느 수험서에는 어떻게 기술되어 있다는 식의 내용은 차치하고, 실제로 실무에서 뛰는 사람들이 사용하는 소프트웨어 테스팅의 목적은 아래와 같습니다.

일반적인 테스팅의 목적
- 남아 있는 결함을 발견하기 위함입니다.
- 명세를 충족하였는지 확인하기 위함입니다.
- 사용자 및 비즈니스 요구를 충족하였는지 확인하기 위함입니다.
- 결함을 예방하기 위함입니다.
부가적인 테스팅의 목적
- 품질 수준에 대한 자신감 획득과 정보를 제공합니다.
- 비즈니스 리스크를 감소시키는 정보를 바탕으로 의사결정 가능한 정보를 제공합니다.
- 개발 프로세스를 점검하고, 개발 프로세스 내의 이슈를 제기합니다.
- 논리적 설계의 구현을 검증합니다.
- 시스템과 소프트웨어가 적절히 동작하는지에 대해 확인합니다.
관점에 따라 다른 테스팅의 목적
- 개발 진행 중 : 소프트웨어의 결함을 찾아내고, 수정하기 위해 가능한 많은 장애 상황을 만들어 내기 위함입니다.
- 제품/서비스 인수 시점 : 기대 결과대로 시스템이 동작하는지를 확인하고, 요구사항에 맞게 개발되었는지 확신을 얻기 위한 과정입니다.
- 품질 평가 단계 : 특정 시간에 응용 프로그램 및 시스템을 출시하는 것의 리스크를 개발 프로젝트에 관련된 이해관계자에게 전달하기 위함입니다.
- 유지보수 단계: 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하기 위함입니다. 운영 : 시스템 특성(신뢰성, 사용성 등)을 평가합니다.

테스트 대상이 되는 시스템(Systems to be tested)이란?

이 질문은 아마도 ISTQB 2007의 1.2장, ISTQB 2018의 1.1장에 나오는 표현에 대한 질문인듯합니다. 해당 내용은 "테스트 대상이 되는 시스템(Systems to be tested)"에 대한 내용이므로, 이에 맞게 설명을 진행하겠습니다.

소프트웨어 테스트 대상이 되는 시스템들의 종류는 아래와 같습니다.

종류		예시
	웹 사이트	온라인 상점 : 아마존, 이베이, 11번가, G마켓, 쿠팡, 티몬 등 클래식 웹 사이트 : 회사 웹 사이트, 블로그, 온라인 뉴스 등 포털 : 구글, 네이버, 다음, 줌, 빙, 야후 등
	모바일 앱	구글 플레이 스토어 전용 앱(Android 기반) 애플 앱 스토어 전용 앱(iOS 기반)
	사물 인터넷	스마트 홈 : 지능형 온도 조절기, WLAN 지원 소켓, 감시 카메라 등 커넥티드 카 : 주차 공간 알리미, 교통 정보, 자동차 시동/온도 조절 등 스마트 기기 : 진공 청소기, 스마트 TV, 냉장고, 세탁기, 공기 청정기 등
	웨어러블	옷, 액세서리(시계, 안경, 반지, 팔찌 등), 운동화, 모자 등 소프트웨어가 탭재된 웨어러블 디바이스
	게임	캐주얼 게임 : 게임 경험이 없이도 적응 가능한 가벼운 게임 소셜 미디어 게임 : 다양항 장르와 테마로 제공되며, 소통 위주의 게임 가상 현실 게임 : 가상 현실을 통한 체험 위주의 게임
	챗봇 & 가상 도우미	고객 서비스로서의 가상 비서, 주문 시스템으로서의 디지털 비서, 일일 도우미로서의 언어 도우미 등
	비즈니스 및 엔터프라이즈 앱	독점 소프트웨어 : 오픈 소스 애플리케이션에 속하지 않는 소프트웨어 CRM : 고객 관계 관리 시스템 인트라넷 : 내부 네트워크

어떠신가요? 여러분들도 더 많은 좋은 예를 들어보실 수 있으신가요?

사실 위 테이블을 좀 더 구조화해서 구분하여 표현한다면 아래 그림과 같습니다.

위 그림은 GS(Good Software) 인증 심사의 범위입니다. GS인증은 한국 내에 판매되는 소프트웨어에 대해 인증기관이 "이 제품은 좋은 소프트웨어입니다."하고 품질인증을 해 증명함을 말합니다.

GS 인증에 대한 자세한 이야기는 필자 중 한 명의 개인 블로그의 포스팅을 참고하시기 바랍니다.

[SW 인증] GS(Good Software) 인증 소개

목차 GS(Good Software) 인증 이란? - GS인증은 Good Software의 약자입니다. - 이름에서도 확인할 수 있듯이 좋은 소프트웨어를 말합니다. - 이 인증은 국산 소프트웨어 중 품질을 증명하는 국가 인증제도

qa-testing.tistory.com

GS인증심사 범위에서도 확인할 수 있듯이 패키지, 모바일, 임베디드, 컴포넌트, 게임, GIS, e-Biz, e-Learning, 주문형(SI) SW, 운영체제, 디지털 콘텐츠, 보안용 SW, 웹 관리 도구, SW 개발도구, 유틸리티, 홈네트워크, 스토리지, 바이오 메트릭스, 교육용 SW 등 소프트웨어 전 분야가 「테스트의 대상」이 될 수 있습니다.

품질 수준을 측정하는 방법은?

자, 그럼 본격적으로 이 글의 주제인 「테스트 대상이 되는 시스템에 대한 품질 수준의 자신감 획득」에 대해 논해 보겠습니다.

「품질 수준의 자신감」이라는 의미는 분명히 나쁜 의미는 아닐 것입니다. 제품의 품질 수준이 좋고, 고객에게 좋은 인상을 심어줄 수 있으며, 잘 팔릴 수 있겠다는 의미가 함축된 의미라고 보는 게 더 옳을 것입니다.

그렇다면 우리가 품질 수준을 이야기할 때 "좋다"라고 이야기하는 방법에는 무엇이 있을까요?

우리는 흔히 단편적으로 「정성적인 측정 방법」과 「정량적인 측정 방법」이라는 방법을 이야기합니다.

① 정성적 측정 방법 : 제품의 품질 요소에 대한 측정 결과를 숫자로 정확히 표현하기 어려울 때 사용하는 방법입니다. 제품의 품질을 측정할 때 측정자인 '테스트 전문가'의 경험 및 주관에 따라 제품의 좋고 나쁨을 평가하는 방법을 말합니다.

물론 테스트 전문가가 자기 하고 싶은 대로 마구잡이로 측정한다는 의미가 아닙니다. "테스트 전문가라면" 당연히 정성적인 측정 방식을 개발해서 정량화하는 방식을 택합니다. 가장 대표적인 정성적인 측정을 정량화하는 방법으로 우리가 흔히 사용하는 방법은 "설문조사"입니다. 예를 들자면, 100명의 사용자에게 이 제품에 대해 어떻게 생각하는지에 대해 사용자들의 감성적인 답변을 모아 정량적으로 측정하기도 하지요.

여기서 잠깐! "설문조사는 마케터 혹은 제품기획자들이 하는게 아닐까요?" 라는 물음이 드실 수 있습니다.

맞습니다.

하지만 마케터나 제품기획자들은 테스트를 하면 안될까요? 본 블로그는 "어떤 업무를 누가 한다" 라는 설명을 드리는 것이 아닙니다. 필자들은 테스트 활동이라는 큰 명제에 대한 설명을 풀어쓰고 있습니다. 테스트 전문가가 설문을 만들어도 되고, 마케팅 전문가가 테스트 관점에서 설문을 만들어도 됩니다. 지금 이 글에서 중요한 부분은 정성적 측정 역시 정량적 측정 도구로 사용될 수 있음을 이야기하는 바입니다.

② 정량적 측정 방법 : 제품 품질 요소를 명확히 뽑아낼 수 있고, 이에 대한 객관적인 기준과 데이터를 가지고 측정하여 정확한 숫자로 기록할 수 있는 경우 사용합니다. 우리가 평생 보아온 시험 결과도 정량적 측정 방법 중 하나입니다. 숫자로 명확하게 표현하기 때문에 일반적으로 정성적 측정 방법보다 훨씬 명확한 결과가 나옵니다. 그래서 많은 테스트 전문가들이 자신의 제품에 대해 정량적인 측정을 하려 노력합니다.

물론, 정량적이라고 해서 항상 명확하게 결과가 나올 거 같지만, 사실 그렇지 않습니다. 인간이 사용하는 많은 소프트웨어에는 재미 요소를 위해 어느 정도의 무작위(Random) 요소를 넣는 경우가 많은데, 이런 확률/통계는 명확한 숫자는 나오지만 그야말로 무작위이다 보니 측정 결과가 명확치 않은 경우가 있습니다. 이런 경우의 해결책은 일반적으로 확률/통계의 오차 범위가 무색해질 정도의 아주 많은 양의 데이터를 확보하는 방법입니다.

마지막으로, 이런 정성/정량적 분석 기법은 위험기반 테스팅(Risk-based testing)에서도 사용하며, 프로젝트 관리자들이 프로젝트의 평가 시에도 사용합니다.

품질이 좋다는 의미는 무엇일까?

함께 생각해 봅시다.

【질문 1】 앞에서 언급한 GS(Good Software) 인증을 획득하면 좋은 품질이라고 할 수 있을까요? TMMi, CMMi, A-SPICE 인증 등 국제 표준을 획득하면 좋은 품질이라고 할 수 있을까요?

【답변 1】 아니오, 인증이라는 것은 심사에 필요로 하는 것을 모두 충족한 상태의 소프트웨어나 시스템, 기업이라고 할 수 있고, 소프트웨어를 판매하거나 기업을 홍보할 때 접두사 정도로 쓰이는 것이지 좋은 품질을 대신할 수는 없습니다.

【질문 2】 테스트 전문가가 테스트 활동 수행 후 버그가 없으면 될까요? TDD(Test-driven development)를 이용해서 개발 초기 단계부터 예상 가능한 모든 예외와 오류를 처리하면 품질이 좋을까요? 소프트웨어 시스템에 버그가 없다는 것은 어떻게 정량적으로 증명할 수 있을까요? 혹은 테스트 전문가, 전문 프로그래머가 "내가 해봐서 아는데..." 라며 정성적으로 주장해 볼 수 있을까요?

【답변 2】 답을 이미 아시겠지만, 위의 질문들에 대한 일관된 대답은 "아니오, 안됩니다."입니다. 이는 테스트 전문가들이 삐딱한 시선을 가지고 있어서라거나, 여러분들이 소프트웨어 테스팅을 잘 모른다며 무시해서 하는 소리가 아닙니다. 소프트웨어 품질 측정에 주관적인 느낌이나 감정을 개입시켜선 정확한 품질을 측정할 수 없기 때문입니다.

복잡하고 화려면 UI를 가져야 좋은 품질일까요? 구글의 품질은 어떤가요?

사실 상용으로 판매되는 소프트웨어들은 대다수 복잡한 기능을 가지고 있기 때문에 「소프트웨어 제품 내부의 테스트 가능한 모든 경우의 수를 완벽하게 테스트하는 것은 불가능합니다」만, 모든 경우의 수에 대해서 테스트했다고 가정해 보겠습니다. 과연 우리는 발견한 모든 버그를 수정함으로써 해당 소프트웨어의 품질이 좋다고 말할 수 있을까요? 테스트 전문가들의 답은 한결같습니다. "아니오 그럴 수 없습니다." 그 이유는 소프트웨어 테스트의 7가지 진리 중 하나인 "오류 부재의 궤변"의 이론에서 확인하실 수 있습니다.

※ 참고 : 소프트웨어 테스팅의 7가지 원리

1. 테스팅은 제품 내 결함이 존재함을 증명하는 것이다.
2. 완벽한 테스팅은 불가능하다.
3. 테스팅은 가능한 개발 초기 단계에 시작해야 한다.
4. 결함은 집중된다.
5. 테스팅에는 반드시 살충제 패러독스가 필연적으로 발생한다.
6. 테스트는 정황에 의존적이다.
7. 오류가 부재하다고 함은 착각이다. (= 오류 부재의 궤변)

이렇듯 소프트웨어의 품질을 측정하는 '정론'이 존재하지 않기 때문에 자사의 소프트웨어 품질을 측정하고 싶은 회사들은 「테스트 전문가」를 고용합니다. 「테스트 전문가」들은 그들이 가진 경함과 역량, 지식을 이용하여 품질 수준을 측정합니다.

사업 요구사항이 얼마나 구현되었는 지, 사용자가 얼마나 만족할 지 등을 확인할 목적으로 '① 정성적 측정 방법'을 주로 사용하고, 세부 시스템 기획의 구현 수준을 확인하고 측정하는 데에 '② 정량적 측정 방법'을 많이 활용합니다. 이런 방법 외에도 국제적으로 표준을 준수해야만 사업을 전개할 수 있는 경우에는 '③ 표준 준수성'을 기준으로 제품의 표준 특질을 얼마나 잘 만족했느냐에 대한 것도 기준이 될 수 있습니다. 또한 불특정 다수의 사용자들이 사용하는 거대 플랫폼 시스템을 운영하는 경우 '④ 시스템 안정성 및 성능'이 주요 기준이 될 수 있습니다. 게임의 경우 각 게임 사 나름대로 '⑤ 게임의 재미를 측정' 하는 내부 기준을 가지고 있는 경우도 있습니다.

※알림 : ③, ④, ⑤번은 일반적으로 사용하는 방법이 아니며, 본 블로그 필자들 중에서도 이를 "정상적인 방식으로 인정할 수 있느냐, 없느냐"에 대한 논쟁이 있으므로, 대충 '업계에서 쓰이는 방식 중엔 이런 방식도 있다' 정도로만 언급하고 자세히 기술하지 않겠습니다.

조직의 성숙도나 테스트 수준에 대한 평가

품질 수준을 높이기 위한 방법으로 단순히 테스트를 수행하여 품질을 평가하는 방법 외에도 조직의 프로세스 성숙도, 혹은 테스트 성숙도를 평가하는 방법이 있습니다. 프로세스의 성숙도가 더 높을수록 더 높은 품질의 제품을 생산할 것이라는 기대가 있기 때문입니다.

예를 들어, 선진국에서 만든 상품이 개발 도상국에서 만든 제품보다 일반적으로 더 좋은 품질을 가진 제품들을 생산함을 떠올리시면 될 듯합니다.

대표적인 예는 아래와 같으며, 관련 자료는 아래 참고자료(References)에 링크해 두었습니다.

< https://www.fmpconsulting.com/ - CMMI ML3 SVC – MORE THAN JUST ALPHABET SOUP >

그래서, 테스팅을 해서 버그를 줄이면 품질이 향상되는가?

본 포스팅의 첫 번 째 질문인 '버그를 줄이면 품질이 향상되는가'에 대한 대답은 사실 "맞다"와 "틀리다"가 동시에 있습니다. 버그를 줄여야 품질이 향상되지만, 또, 버그를 줄여도 품질이 향상되지 않기도 합니다. 품질은 단순히 '버그에 종속적인 성격'을 가지고 있지는 않기 때문입니다.

물론 ISTQB 수험생들을 위해 본 포스팅에서 제공해야 하는 일반적인 답은 "예, 버그가 줄어야 품질이 향상됩니다." 입니다. 이렇게 먼저 이야기 한 후 뒤 이야기를 풀어 가겠습니다.

예, 맞습니다. 버그 수를 줄여야 품질이 향상됩니다. 왜 그럴까요? 바로 제품을 만드는 사람의 「제작 의도」, 「기획 의도」 때문입니다. 제품을 사용 하는데 너무 많은 버그가 있다면 사용자들은 제품의 원래 기획 의도를 정확히 느끼고 이해하기 어렵습니다. 사용자들은 제품의 의도와 목적에 맞게 작동해야 품질이 높다고 느끼기 때문입니다.

또, 반대로 개발하는 입장에서는 「기획 의도」와는 다르게 작동하여 꽤나 중대해 보이는 버그가 있어도 사용자들이 이를 기능으로 인식한다면, 혹은 이를 이용해서 제품을 사용한다면 이는 그다지 심각한 버그가 아닐 수 있습니다. (검색 엔진에 '와우 벽타기'를 검색해 보세요.)

< https://www.scnsoft.com/ - Software Testing Basics: Types of Bugs and Why They Matter >

언젠가 본 블로그에서 품질에 대해서 깊은 이야기를 하게 되겠지만, 오늘은 간단히 정리하겠습니다.

품질에 대해 이야기할 때는 "버그와 품질의 상관 관계"보다는 "프로젝트/제품과 관련한 이해관계자 간의 이해" 쪽이 훨씬 진실에 가깝습니다. 제품으로 사업하는 역할에서는 제품이 잘 팔리는 게 품질이 높은 상태이고, 기획하는 입장에서는 기획 의도 대로 작동하는 게 품질이 높은 상태이고, 프로그래밍하는 입장에서는 개발한 대로 작동하는 게 품질이 높은 상태이고, 테스팅하는 입장에서는 버그가 많이 없어야 품질이 높은 상태일 것이며, 사용자의 입장에서는 돈 낸 만큼의 가치를 하는게 품질이 높은 상태일 것입니다. 즉, 모든 이해관계자가 바라보는 관점에 따라 품질의 고저를 판단하는 기준이 다릅니다.

그러나 본 블로그는 ISTQB를 해석해주는 내용을 소개해 드리고 있으므로... "버그가 줄어 들어야 품질이 높아 진다, 그리고 그래야 품질 수준에 대한 자신감을 얻을 수 있다." 라는 「테스트 전문가」라는 이해관계자의 입장에서의 답을 결론으로 드리겠습니다.

ISTQB 자격증과 상관 없이 이 글을 보고 계신 분들은 추가적으로 SLA(Service Level Agreement)에 대해서도 검색해서 공부해 보셔도 좋습니다.

사족 : 「테스트 전문가」인 우리가 잊지 말아야 할 원칙

"월급을 받는 전문직 테스터"인 「테스트 전문가」로서 우리가 반드시 잊지 말아야 할 것이 있습니다.

우리는 회사원이라는 점입니다.

회사의 한국어 사전은 '회사'의 의미를 아래와 같이 정의합니다.

그리고 영문 사전에서는 회사, Cooperation을 다음과 같이 정의합니다.

우리는 완벽을 추구하는 예술가가 아닙니다. 우리는 회사에 다니는 사람들이고, 회사의 목적은 이윤 추구에 있습니다. 그러므로, 어떤 제품의 가장 좋은 품질의 상태는 바로 "잘 팔리는 상태"입니다. 최고의 기능, 최고의 그래픽, 최고의 스토리텔링을 가지고 있지 않더라도, 소비자들이 많이 선택하는 상품의 상태가 '해당 제품이 가져야 할 적절한 품질 상태'를 가지고 있다고 할 수 있습니다.

물론 잘 팔리기만 하는 제품이 좋은 품질이라는 의미는 아닙니다. 제품의 상태가 너무 완벽할 필요는 없으며, 프로젝트 관리 관점에서 보았을 때 궁극적으로는 '투입되는 자원 대비 이윤 향상을 추구해야 함'을 『테스트 관점』에서 분석하고, 활동을 준비/진행하는 것이 「테스트 전문가」가 회사에 필요한 이유라는 의미입니다.

예를 들면, 떡볶이에 금가루 뿌려서 팔 거 아니고, 스테이크에 초장 발라서 팔게 아니라는 겁니다. (물론, 이렇게 해서 대박 나는 경우가 있다면 이 글에서 이 부분은 삭제하기로 하죠!!)

「테스트 전문가」의 소임은 사업이 옳은 방향으로 잘 작동하게 하여 이윤을 추구하는 데 있음을 잊지 마세요!!