ISTQB Part 1 - 소프트웨어 테스팅의 기초

1. 소프트웨어 테스팅의 기초

1.1.1 소프트웨어 시스템 관점에서 테스팅의 필요성

- 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요

 

1.1.2 소프트웨어 결함(Defects, Bug)의 원인

1) 인간의 오류 (시간적 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 시스템 상호간의 연동 등)

2) 환경적인 조건 : 방사, 자기, 전자기장, 물리적 오염

결함 => 장애의 원인

 

1.1.3. 소프트웨어의 개발, 유지보수, 운영 시 테스티의 역할

- 개발 초기 단계 : 정적분석

- 각각 개바 단계 : 테스트 레벨에 따른 테스팅

- 컴포넌트(단위) 테스팅, 통합테스팅 => 개발조직이 중심이 되어 수행

 

1.1.4. 테스팅과 품질

- 테스팅으로 발견된 결함이 극소수이거나 없다면 테스트 설계 및 실행이 정상적으로 진행되었다는 전제하에 소프트웨어의 품질에 대한 확신을 가질 수 있음

 

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

- 리스크 수준을 고려해야 함

- 기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간 비용과 가은 제약사항 고려 필요

 

1.2 테스팅이란 무엇인가?

 - 테스팅이란 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 매커니즘

[테스팅의 일반적인 목적]

- 남아있는 결함 발견

- 명세 충족 확인

- 사용자 및 비즈니스의 요구 충족 확인

- 결함 예방

 

[관점에 따른 테스팅의 목적]

- 개발과정 : 가능한 많은 장애 상황을 만드는 것

- 인수 테스팅 : 예상한대로  시스템이 동작하는지 확인, 요구사항에 맞는지 확신을 얻음

- 유지보수 테스팅 : 리그레션 테스팅을 포함

- 운영 테스팅 : 신뢰성 또는 가용성과 같은 시스템의 특성을 평가

 

[테스팅과 디버깅의 차이]

- 테스팅 : 결함을 발견하기 위한 활동

- 디버깅 : 결함의 원인을 밝히고 코드를 수정하는 개발 활동

 

1.3. 테스팅의 일반적인 원리

1) 테스팅은 결함이 존재함을 밝히는 활동이다.

2) 완벽한 테스팅은 불가능하다

3) 테스팅을 개발 초기에 시작한다

4) 결함 집중

5) 살중제 패러독스

6) 테스팅은 정황에 의존적이다

7) 오류-부재의 궤변

 

1.4 테스트 프로세스의 기초

테스트 프로세스 주요 활동

1.4.1 테스트 계획과 제어(통제)

[테스트 계획]

- 테스트 범위와 테스트를 위한 리스크에 대한 결정, 테스팅의 목적에 대한 식별

- 테스트 정책의 실현과 테스트 전략의 구현

테스트 접근 방법에 대한 결정

테스트에 필요한 리소스의 결정

테스트 분석과 설계 작업의 일정관리

테스트 구현, 실행 및 평가의 일정관리

테스트 완료 조건의 결정

 

[테스트 제어]

- 테스트 결과에 대한 ㅡㄱ정과 부넉

- 테스트 진척 상황, 테스트 커버리지와 완료 조건의 모니터링과 문서화

- 테스트 계획과의 차이를 교정하는 활동

- 테스팅의 진행과 변경에 대한 의사 결정 활동

 

1.4.2. 테스트 분석과 설계

: 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동

- 테스트 베이시스(요구사항 명세서, 아키텍처, 개발 설계 문서, 인터페이스) 리뷰

- 테스트 대상 아이템 또는 제품, 명세, 동작과 구조의 분석을 통해 테스트의 상황을 식별하고 우선 순위 선정

- 테스트 케이스 설계와 우선순위 선정

- 비공식적인 테스트 기법으로 테스트 케이스 추가 도출 및 보완

- 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별

- 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설 및 도구의 식별

 

1.4.3. 테스트 구현과 실행

- 테스트 케이스의 개발, 구현과 우선순위 선정

- 자동화 테스트 스크립트 작성

- 테스트 하네스 준비

- 효율적인 테스트 실행을 위한 테스트 수트 생성

- 테스트 환경의 올바른 구축 여부 확인

- 계획된 순서에 의거하여 수동 또는 테스트 시행 도구로 준비된 테스트 프로시저 수행

- 테스트 수행 결과 기록

- 예상결과와 실제 결과 비교

- 예상 결과와 실제 결과간의 차이에서 오는 불일치를 인시던스 또는 결함으로 보고

- 불일치의 원인을 알아내기 위해 실제 결과나 현상을 분석

1) 테스트 케이스 결함

2) 테스트 정황 결함

3) 어플리케이션 결함

4) 어플리케이션 정황 결함

- 각각의 불일치를 조치한 결과를 확인하기 위해 테스트 활동을 반복

 

[분류 가능한 결함 유형]

- 기획 시 유입된 결함

- 설계시 유입된 결함

- 코딩 시 유입된 결함

- 테스트 부족으로 유입된 결함

- 마무리 부족

-팀간 의사소통 부족

- 코딩 실수

 

1.4.5. 테스트 마감 활동

- 테스트 결과 마감

- 테스트웨어, 테스트 환경, 테스트 시반설비를 차후에 사용할것을 대비하여 마감하고 보관

- 테스트웨어를 유지보수 조직에 이관

-테스트 프로세스 심사 및 개선사항 제안

 

1.5. 테스팅의 심리학

[테스팅의 독립성]

1) 테스트 대상 소프트웨어의 개발자가 설계한 테스트

2) (개발팀 내의) 다른 인원이 설계한 테스트

3) 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가(사용성 또는 성능 테스트 전문가 등)가 설계한 테스트

4) 다른 조직 또는 다른 회사의 인원이 설계한 테스트 (외부적인 조직에 의한 인증, 아웃소싱)

 

1.6. 소프트웨어 테스팅을 제약하는 요소

- 테스팅을 투자가 아닌 불필요한 비용으로 보는 것

- 의사결정권자 또는 매니저들의 테스팅에 대한 인식 부족

 

1.8. 테스트 전문가의 요건

- 기술능력

- 습관

- 개인능력

-사고방식, 태도