1.2 테스팅이 왜 필요한가? Why is Testing Necessary?

운영 중 장애 발생 가능성을 줄임

결함을 발견/수정하는 것은 컴포넌트나 시스템의 품질에 기여

계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해

 

1.2.1 성공을 위한 테스팅의 기여 (Testing’s Contributions to Success)

테스터를 요구사항 리뷰 혹은 사용자 스토리 개선에 참여 => 작업 산출물에서 결함을 발견

시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업 => 이해도 상승, 기능 설계에 결함이 유입되는 리스크 감소,  필요한 테스트를 빠르게 식별

코드를 개발하는 동안 테스터가 개발자와 적극적으로 협업 => 이해도가 높아지면 코드와 테스트에서의 결함 발생 리스크감소

테스터가 릴리스 전에 소프트웨어를 확인하고 검증 => 놓쳤을 수 있는 장애를 발견하고 그 장애의 원인인 결함을 제거(즉, 디버깅)하는 데 도움

 

1.2.2 품질 보증과 테스팅 (Quality Assurance and Testing)

둘 다 좀 더 포괄적인 개념인 품질 관리(quality management)에 속한다. 

품질 관리에는 품질 측면에서 조직이 나아가야 하는 방향을 제시하고 제어하는 모든 활동이 포함

품질 관리는 또한 품질 보증과 품질 제어를 포함한 여러 가지 활동을 포함한다. 

일반적으로 품질 보증은 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점

프로세스를 따를 경우, 해당 프로세스를 바탕으로 생성되는 작업 산출물의 품질은 더 월등한 경우가 많으며, 높은 작업 산출물 품질은 결함 예방에 도움이 된다. 또한, 결함의 원인을 찾아서 제거하기 위한 근본 원인 분석(root cause analysis)의 활용과 회고 회의(retrospective meetings)의 결과를 적절하게 적용해서 프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항

 

품질 제어에도 적합한 품질 수준을 달성하기 위한 다양한 활동이 있으며, 테스트 활동도 여기에 포함된다. 테스트 활동은 전반적인 소프트웨어 개발 및 유지보수 프로세스의 일부

 

1.2.3 오류, 결함, 장애 (Errors, Defects, and Failures)

사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시키는 오류(실수)를 범할 수 있다. 특정 작업 산출물 내 결함의 원인이 되는 오류는 연관된 다른 작업 산출물의 결함의 원인

요구사항을 도출하면서 범해진 오류는 요구사항 결함이되며, 요구사항 결함은 프로그램 작성 시 오류를 일으켜 결국 코드 결함의 원인이 된다.

대표적인 오류 발생 원인은 다음과 같다:
● 시간적인 압박
● 사람의 실수
● 경험이 적거나 기술이 부족한 프로젝트 참여자
● 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제

● 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도
● 시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우
● 새롭고 익숙하지 않은 기술.

 

장애는 코드 결함뿐만 아니라 환경 조건으로 인해 발생할 수도 있다.

테스트 결과가 기대한 것과 다르다고 해서 무조건 장애가 있다고 볼 수는 없다.

거짓양성(false positive) : 결함으로 보고됐지만 실제 결함이 아닌 경우

ㄴ 테스트 실행 방식의 오류나 테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우

거짓음성(false negative) :테스트가 발견했어야 할 결함을 발견하지 못하는 경우

 

1.2.4 결함, 근본 원인, 결과 (Defects, Root Causes and Effects)

결함의 근본 원인은 해당 결함을 만들어낸 최초의 행동이나 조건

결함을 분석함으로써 근본 원인을 찾을 수 있으며, 차후 유사한 결함의 발생 가능성을 낮출 수 있다.

 

이자 지급 오류 => 소비자 불만

제품 소유자가 이자 계산법을 잘못 이해  => 애매모호한 사용자 스토리 => 위 스토리를 기반으로 코드가 잘못 작성됨

대부분의 결함 : 계산식에 존재하며 해당 결함들의 근본 원인 역시 비슷한 오해로 인한 것이라면, 차후 유사한 결함의 발생 가능성을 낮추기 위해 제품 소유자에게 이자 계산에 대한 교육을 제공할 수 있다.(파레토 법칙?)
앞의 예제에서의 결과는 소비자 불만이며 장애는 잘못된 이자 지급이다. 결함은 코드에 포함된 잘못된 계산식이며, 그것의 원인이 되는 최초 결함은 사용자 스토리의 모호성이다. 최초 결함의 근본 원인은 제품 소유자의 지식 부족이었으며, 그 결과로 제품 소유자가 사용자 스토리를 작성할 때 오류를 범했다고 볼 수 있다.