책 발췌 - 소프트웨어 테스팅 용어 및 정의 by Ron Patton

출처: 책 Software Testing by Ron Patton, 2001년

3장 The Realities of Software Testing, 46~49페이지

 

소프트웨어 개발 프로세스 및 소프트웨어 테스팅에 대한 기본 개념을 설명하는 용어이지만 혼동되거나 부적절하게 사용되는 경우가 많은 용어 쌍을 정리한다.

 

---

 

정밀(Precision) vs. 정확(Accuracy)

소프트웨어 테스터로서 정밀(precision)와 정확(accuracy)의 차이를 아는 것이 중요하다. 우리가 계산기를 테스트하고 있다고 가정하자. 계산기가 반환하는 답이 정밀한지(precise) 테스트해야 할까 또는 정확한지(accurate) 테스트해야 할까? 둘 다 해야 하는가? 프로젝트 일정으로 인해 이 둘 중 하나에만 집중하도록 리스크 기반 의사결정을 내려야 한다면 어느 것을 선택하겠는가?

 

우리가 테스트할 소프트웨어가 야구나 비행 시뮬레이터와 같은 시뮬레이션 게임이라면 어떤 선택을 하겠는가? 주로 정밀도를 테스트해야 할까, 아니면 정확성을 테스트해야 할까?

 

그림 3.4는 이 두 용어를 설명하는 데 도움이 되는 예이다. 이 다트 게임의 목표는 보드 중앙의 과녁을 맞추는 것이다. 왼쪽 상단 보드의 다트는 정밀하지도 정확하지도 않다. 다트가 밀접하게 그룹화되어 있지 않으며 타겟의 중심에 가깝지도 않다. 오른쪽 상단의 보드에는 정밀하지만 정확하지 않은 다트가 표시되어 있다. 다트가 촘촘하게 모여 있어서 던지는 사람이 정밀도를 보이지만 다트가 보드에 닿지도 않았기 때문에 정확성은 그리 높지 않다. 왼쪽 하단의 보드는 정확성은 있지만 정밀도가 좋지 않은 경우이다. 다트는 중앙에 매우 가깝기 때문에 던지는 사람이 조준하는 것에 가까워지고 있지만, 위치가 밀접하지 않아 정밀도가 떨어진다. 오른쪽 하단의 보드는 정밀도와 정확성이 완벽하게 일치한다. 다트는 가깝게 그룹화되어 있으며 타겟에 위치한다.

그림 3.4 다트판의 다트가 정밀(precision)과 정확(accuracy)의 차이를 보여줌

 

우리가 테스트하는 소프트웨어가 정밀해야 하는지 아니면 정확해야 하는지 여부는 제품이 무엇인지, 궁극적으로 개발 팀이 목표로 하는 것이 무엇인지에 따라 달라진다. 소프트웨어 계산기는 두 가지 모두를 달성해야 할 가능성이 높다. 그러나 “계산이 소수점 다섯째 자리까지만 정확하고 정밀하다” 같은 결정을 내릴 수도 있으며 그 이후에는 정밀도가 달라질 수 있다. 테스터가 이러한 명세(specification)를 알고 있는 한 이를 확인하기 위해 자신의 테스트를 맞춤화할 수 있다.

 

 

Verification vs. Validation

Verification과 Validation은 종종 같은 의미로 사용되지만 정의가 다르며, 이 차이점이 소프트웨어 테스팅에 중요하다. Verification은 소프트웨어가 그 명세(specification)를 충족하는지 확인하는 프로세스이고, Validation은 사용자 요구사항(user’s requirements)을 충족하는지 확인하는 프로세스이다. 이것이 매우 유사하게 들릴지 모르지만 허블 우주 망원경 문제에 대한 설명이 이 차이를 보여주는 데 도움이 된다.

 

1990년 4월, 허블 우주 망원경이 지구 주위 궤도로 발사되었다. 반사 망원경인 허블은 조준하는 물체를 확대하기 위한 주요 수단으로 대형 거울을 사용한다. 이 거울을 만드는 일은 극도의 정밀도와 정확성을 요구하는 엄청난 작업이었다. 망원경은 우주에서 사용하도록 설계되었고, 그것이 아직 지구에 있는 동안에는 위치를 정하거나 거울을 통해 볼 수도 없었기 때문에 거울을 테스트하는 것이 어려웠다. 이러한 이유로 테스트하는 유일한 방법이 모든 속성을 주의 깊게 측정하고 측정치를 명세서에 기술된 것과 비교하는 것이었다. 이렇게 테스팅이 수행되었으며 허블이 발사에 적합하다고 선언되었다.

 

불행하게도 작동을 시작한 직후 반환되는 이미지의 초점이 맞지 않는 것으로 나타났다. 조사 결과 거울이 부적절하게 제조된 것으로 밝혀졌다. 거울이 사양대로 연마되었지만 해당 사양이 틀린 것이었다. 거울은 매우 정밀했지만 정확하지는 않았다. 테스트를 통해 거울이 명세를 충족했음이 확인되었지만(verification YES) 원래 요구사항을 충족하는지 확인하지는 못했다(validation NO). 1993년 우주 왕복선 임무에서 부적절하게 제조된 거울이 생성하는 이미지의 초점을 다시 맞추기 위한 "교정 렌즈"를 설치하여 허블 망원경을 수리했다.

 

이것이 소프트웨어 예는 아니지만 verification 및 validation이 소프트웨어 테스팅에도 동일하게 적용된다. 절대 명세서가 정확하다고 가정하지 마라. 명세를 verification하고 최종 제품을 validation하면 허블 망원경이 맞닥뜨린 것과 같은 문제를 피하는 데 도움이 된다.

 

 

품질(Quality) vs. 신뢰성(Reliability)

Merriam-Webster 사전에서는 품질(quality)을 “a degree of excellence” 또는 “superiority in kind”라고 정의한다. 소프트웨어 제품의 품질이 높으면 고객의 니즈(needs)를 충족할 것이다. 고객은 그 제품이 다른 선택보다 훌륭하고 우수하다고 느낄 것이다.

 

소프트웨어 테스터는 품질(quality)과 신뢰성(reliability)이 같은 것이라고 믿는 함정에 빠지는 경우가 많다. 그들은 프로그램이 안정적이고 신뢰할 수 있을 때까지 테스트할 수 있다면 고품질 제품이 보장된다고 생각한다. 불행히도 반드시 그런 것은 아니다. 신뢰성은 품질의 한 측면일 뿐이다.

 

소프트웨어 사용자가 생각하는 품질에는 기능(features)이 폭넓은지, 자신의 구형 PC에서 제품이 실행될 수 있는지, 소프트웨어 업체가 전화로 고객 지원을 하는지, 심지어는 제품 상자의 색상까지 포함될 수 있다. 신뢰성(또는 제품이 얼마나 자주 크래시되거나 데이터가 망가지는가)이 중요할 수 있지만 항상 그런 것은 아니다.

 

프로그램의 고품질과 신뢰성을 보장하기 위해 소프트웨어 테스터는 제품 개발 프로세스 전반에 걸쳐 verifacation과 validation을 수행해야 한다.

 

 

테스팅(Testing) vs. 품질 보증(Quality Assurance: QA)

이 두 용어는 소프트웨어 verification 및 validation과 관련된 그룹이나 프로세스를 설명하는 데 가장 자주 사용되는 용어이다.

 

• 소프트웨어 테스터의 목표는 버그를 가능한 한 빨리 발견하여 수정하는 것이다.
• 소프트웨어 품질 보증 담당자의 주요 책임은 개발 프로세스를 개선하고 버그 발생을 방지하기 위한 표준과 방법을 만들고 시행하는 것이다.

 

물론 겹치는 부분도 있다. 일부 테스터가 몇몇 QA 작업을 수행하기도 하고 QA 담당자가 약간의 테스팅을 수행하기도 한다. 이 두 가지 직업과 그 임무는 서로 얽혀 있다. 중요한 것은 자신의 주요 직무가 무엇인지 알고 해당 정보를 개발팀의 나머지 팀원들에게 전달하는 것이다. 누가 테스트하고 누가 테스트하지 않는지에 대한 팀원들의 혼란은 여러 프로젝트에서 많은 프로세스 문제를 야기했다.