ISTQB 1.1 테스팅의 필요성

1. SW 시스템 관점에서 테스팅의 필요성

• 비즈니스 어플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분에 사용
• 비중은 계속 증가
• 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 그리고 부상 이나 사망에 이르기까지 다양하고 심각
• 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요

2. 소프트웨어 결함의 원인

• 오류(error): 인간의 행위, 실수, 코드 작성, 소프트웨어나 시스템 또는 문서 작성시 결함을 만드는 오류
• 결함(defect): 요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨
• 간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변 경, 수많은 시스템 상호간의 연동
• 결함은 장애의 원인, 그러나 모든 결함이 장애를 발생시키는 것은 아님
• 장애(failure): 코드에 존재하는 결함의 실행 또는 환경적 조건에 의해 부정확하게 처리되는 것을 의미함
• 결함 + 환경적인(방사, 전자기장, 물리적 오염 등 ) 조건

3. SW개발, 유지보수, 운영 시 테스팅의 역할

• 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석을 통해 정적으로 시작(각각의 개발단계에 대응하는 테스트 레벨별)
• 컴포넌트, 통합 테스팅은 개발 조직 중심으로 수행
• 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직 중심
• 테스트 레벨에 따른 테스트
• 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화
• 유지보수 활동으로 변경 및 단종되거나 환경이 변경
• 변경된 환경에 대해 운영 테스팅(리그레션 테스팅)
• 변경으로 인한 결함과 장애를 예방
• 계약상 요구조건 및 산업에 특화된 표준 만족

4. 테스팅과 품질

• ISO/IEC 9126 소프트웨어 제품 품질
• 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성
• 품질 향상(테스팅이 결함을 찾아내고, 발견된 결함 수정)
• 품질 보증(Quality Assurance)
• 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보
• 발견된 결함의 근본 원인 이해를 통해 프로세스 개선
• 결함의 재발 방지
• 개발 표준이나 교육 훈련 그리고 결함 분석

5. 테스팅, 얼마나 해야 충분한가?

• 리스크 수준을 고려
• 프로젝트 제약 사항
• 기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간, 비용
• 테스팅은 테스트된 SW나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해관계자들이 릴리즈 결정을 내릴 수 있도록 충 분한 정보 제공