[ISTQB-CTFL #02] 1.2 테스팅이 왜 필요한가?

컴포넌트, 시스템 및 관련 문서에 대한 철저한 테스팅은 운영 중 장애 발생 가능성을 줄이는 데 도움

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

소프트웨어 테스팅이 계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해 필요할 수도 있음

---

1.2.1 성공을 위한 테스팅의 기여

테스팅의 필요성

- 컴퓨터의 역사에서 소프트웨어와 시스템이 운영을 위해 배포된 후로, 늘 존재

- 결함으로 장애가 발생하거나 이해관계자의 요구를 충족시키지 못하는 상황

- 해결방안: 적절한 테스트 기법을 적절한 테스트 전문성을 가지고 적절한 테스트 레벨과 개발 수명주기 단계에 적용

 

테스팅의 예

요구사항 결함 식별

1. 테스터를 요구사항 리뷰 혹은 사용자 스토리 개선에 참여

2. 해당 작업 산출물에서 요구사항 결함을 발견, 식별

3. 제거하면 잘못된 혹은 테스트할 수 없는 기능이 개발되는 리스크 ↓

 

이해도 상승

1. 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우

2. 설계와 그것을 어떻게 테스트해야 하는지 서로 좀 더 깊이 이해

3. 기능 설계에 결함이 유입되는 리스크 ↓, 필요한 테스트를 좀더 일찍 식별

 

1. 코드를 개발하는 동안 테스터가 개발자와 적극적으로 협업할 경우

2. 코드와 그것을 어떻게 테스트해야 하는지 서로 좀 더 깊이 이해

3. 코드와 테스트에서의 결함 발생↓

 

소프트웨어가 이해관계자의 필요와 요구사항을 충족시키는 법

1. 테스터가 릴리스 전에 소프트웨어 확인, 검증

2. 장애 발견, 장애의 원인인 결함을 제거(디버깅)

 

정의된 테스트 목적을 충족하는 것은 소프트웨어 개발과 유지보수 전반의 성공 확률 ↑

---

1.2.2 품질 보증과 테스팅

품질 관리

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

- 품질 보증, 품질 제어를 포함한 여러 가지 활동 포함

품질 보증

- 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것

- 프로세스를 따를 경우, 해당 프로세스를 바탕으로 생성되는 작업 산출물의 품질은 더 월등한 경우가 많으며, 높은 산출물 품질은 결함 예방에 도움이 됨

- 결함의 원인을 찾아 제거하기 위한 근본 원인 분석의 활용과 회의의 결과를 적절하게 적용해서 프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항들

 

품질 제어

- 적합한 품질 수준을 달성하기 위한 다양한 활동이 있음(테스트 활동 등)

- 전반적인 프로세스의 올바른 수행 여부에 관심을 가지기 때문에 올바른 테스팅의 적용에 관심

 

테스팅

- 테스트 활동은 전반적인 소프트웨어 개발 및 유지보수 프로세스의 일부

- 테스팅은 품질을 높이는데 다양한 방법으로 기여

 

---

1.2.3 오류, 결함, 장애

오류

- 사람의 오류: 사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)를 발생시키는 오류(실수)를 범할 수 있음

- 특정 작업 산출물 내 결함의 원인이 되는 오류: 연관된 다른 작업 산출물의 결함의 원인이 되는 또 다른 오류의 계기가 될 수 있음

- ex) 요구사항을 도출하면서 범해진 오류는 요구사항 결함, 프로그램 작성 시 오류를 일으켜 결국 코드 결함의 원인

 

결함

- 코드의 결함이 실행되면 장애를 일으킬 수 있지만 반드시 그런 것은 아님

- ex) 결함 중 일부는 발생 가능성이 없거나 매우 낮아서 특수한 입력이나 사전조건이 충족돼야 장애를 일으킬 수 있음

 

장애

- 코드 결함 뿐만 아니라 환경 조건으로 인해 발생

- ex) 펌웨어 결함의 원인, 하드웨어 상태를 변화: 방사능, 전자기장, 환경 오염 등 소프트웨어 실행에 영향

 

오류 발생 원인

- 시간적인 압박

- 사람의 실수

- 경험이 적거나 기술이 부족한 프로젝트 참여자

- 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제

- 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도

- 시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우

- 새롭고 익숙하지 않은 기술

 

거짓양성

- 테스트 결과가 기대한 것과 다르다고 해서 무조건 장애 X

- 테스트 실행 방식의 오류나 테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우, 그 외 다양한 이유

- 비슷한 오류, 결함이 거짓 음성의 원인이 되는 반대의 경우도 발생할 수 있음

 

거짓 음성: 테스트가 발견했어야 할 결함을 발견 X

거짓 양성: 결함으로 보고되었지만 실제 결함이 아닌 경우

 

---

1.2.4 결함, 근본 원인, 결과

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

결함 분석 => 근본 원인 찾아냄 => 차후 유사한 결함의 발생 가능성 ↓

가장 근본적인 원인 분석 후, 집중하기에 프로세스 개선은 이후 발생하는 결함 수를 상당 부분 ↓

 

ex) 단 한 줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만 초래

1. 제품 소유자가 이자 계산법을 잘못 이해해서 작성한 애매모호한 사용자 스토리 발생

2. 그 사용자 스토리를 기반한 코드가 잘못 작성

 

대부분의 결함이 이자 계산식에 존재, 해당 결함들의 근본 원인 역시 비슷한 오해로 인한 것, 차후 유사한 결함의 발생 가능성을 낮추기 위해 제품 소유자에게 이자 계산에 대한 교육 제공

 

결과: 소비자 불만

장애: 잘못된 이자 지급

결함: 코드에 포함된 잘못된 계산식

원인이 되는 최초 결함: 사용자 스토리의 모호성

최초 결함의 근본 원인: 제품 소유자의 지식 부족

결과: 제품 소유자가 사용자 스토리를 작성할 때 오류를 범했다고 볼 수 있음

 

근본 원인 분석 프로세스는 ISTQB-CTFL-TM 및 ISTQB-CTFL-ITP 에서 다루고 있음