[ISTQB] Why is Testing Necesarry

K2 : 이해 (understand)

 

Testing’s Contributions to Success

결함으로 장애가 발생하거나 이해관계자의 요구를 충족시키지 못하는 상황을 줄일 수 있다.

• 요구사항 리뷰 > 테스트 불가 기능 제거를 통해 리스크 줄임
• 사용자 스토리 개선에 참여 > 작업 산출물에서 결함 발견 
• 시스템 설계 중 테스터와 협업 > 기능 설계의 결함 유입이 낮아지고 필요한 테스트를 일찍 식별
• 코드 개발 중 > 결함 발생 리스크 낮춤
• 릴리스 전 테스트 > 발견한 결함 디버깅 가능 > 이해관계자의 필요와 요구사항을 충족시킬 가능성을 높임

Quality Assurance and Testing

품질 보증(QA, Quality Assurance)과 테스팅의 차이점

• QA는 품질 보증과 품질 제어를 포함한 더 포괄적인 개념
• 즉, 테스팅은 품질을 올리기위한 방법으로 기여

 

*품질 보증: 적절한 품질 수준 달성 여부 확인하기 위해 프로세스 준수

(또한 근본 원인 분석(root cause analysis)의 활용과 회고 회의(retrospective meetings)의 결과를 적절하게 적용해서 프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항)

*품질 제어 또한 품질 수준 달성을 위해 다양한 테스트 활동을 포함

 

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

 

[정의] 결함의 원인 = 오류(실수)

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

 

오류 발생 원인

• 시간적인 압박
• 사람의 실수
• 경험/기술이 부족한 프로젝트 참여자
• 요구사항/설계 등에 대한 프로젝트 참여자 간 의사소통 문제
• 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도
• 시스템 내/외부 인터페이스에 대한 이해 부족(내/외부 인터페이스의 수가 많은 경우)
• 새롭고 익숙하지 않은 기술

 

[정의] 결함으로 인한 장애

 

• 결함 중 일부는 발생 가능성이 없거나 매우 낮아서 특수한 입력이나 사전조건이 충족돼야 장애를 일으킬 수 있다.
• 코드 결함 뿐만 아니라 환경 조건으로 발생 가능(방사능, 전자기장, 환경 오염)

주의해야할 점은 테스트 결과가 기대와 다르다해도 무조건 장애로 판단할 수 없다.

> 거짓 양성의 가능성(테스트 실행 방식의 오류나 테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우 등)

 

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

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

 

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

 

[정의] 결함의 근본 원인은 해당 결함을 만든 최초의 행동이나 조건

 

따라서 결함 분석 > 근본 원인 발견 > 차후 유사 결함 방지 > 이를 기반으로한 프로세스 개선 > 결함 수 발생 줄임