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

 

[소프트웨어 테스팅이 왜 필요한가?]

(용어)

오류(Error) : 코드 및 문서를 작성하는 도중 결함을 만드는 실수(mistake)를 할 경우 발생

결함/버그/결점(Defects, Bug, Fault)

- 요구된 기능의 부정 처리

- 보통 장애를 발생시키는 것을 말함

- 원인 : 인간의 오류, 시간적 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템의 상호 연동

장애(Failure)

- 코드에 존재하는 결함의 실행 또는 환경적 조건에 의한 부정 처리

- 모든 결함이 장애를 일으키는 것은 아니다.

- 원인 : 환경적인 조건(방사, 자기, 물리적 오염 등)이 HW 조건을 변경시켜 SW에 영향을 줄 수 있다.

 

품질보증(Quality Assurance)관점에서 테스팅의 필요성

- 테스팅으로 발견된 결함이 없다면 SW품질에 대한 확신을 가질 수 있다.

- 이전 프로젝트를 통해 얻은 경험과 정보가 이후 프로세스의 개선을 돕는다.

- 그러한 결함의 재발을 방지하여 차후 시스템의 품질을 개선할 수 있다.

 

테스팅이란 무엇인가?

- 사용자의 기대와 요구에 맞게 동작하는지를 확인하고, 이를 통해 결함을 발견하여 리스크(risk)정보를 전달하는 것

 

테스팅의 목적

개발과정(컴포넌트) : SW의 결함을 찾아내고 수정하기 위해 가능한 많은 장애 상황을 만들어 냄

인수 테스팅 : 예상대로 시스템이 동작하는지, 요구사항을 충족하는지 확인

품질 평가 테스팅 : 특정 시점에 릴리즈하는 것의 리스크를 확인하여 전달하기 위함

유지보수 테스팅 : 개발 변경작업이 있는 경우 새로운 결함이 있는지, 리그레션 포함

운영 테스팅 : 신뢰성, 가용성 등의 특성을 평가

 

테스팅의 일반적인 원리

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

- 결함이 없다고 증명할 수는 없다.

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

- 간단한 SW가 아닌 경우, 모든 가능성을 테스팅하는 것은 불가능하다. (무한 경로, 입력, 타이밍)

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

- 전체 테스팅 기간과 개발기간이 단축될 수 있고, 후반부에 발견될 결함을 예방할 수 있다.

4. 결함 집중(Defects clustering)

- 대다수의 결함은 소수의 특정 모듈에 집중되어 발생하는 경향

5. 살충제 페러독스(Pesticide paradox)

- 공식적인 기법을 적용한 TC역시 반복되면 새로운 결함을 찾기 어려워짐. TC업데이트 및 탐색적 테스팅, JIT 테스팅 등의 노력 필요

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

7. 오류-부재의 궤변

- 개발된 시스템이 요구를 만족시키지 못하고 사용성이 낮다면 결함이 없더라도 품질이 높다고 볼 수 없다.

 

테스트 프로세스

1. 테스트 계획과 제어(통제)

- 테스트 범위와 리스크 결정, 목적 식별

- 테스트 정책(인력, 타켓, 프로세스, 이해관계 등)의 실현, 테스트 전략 구현

- 테스트 접근 방법에 대한 결정(테스트 기법 및 테스트 베이시스 포함 여부, 아이템, 커버리지 등)

- 필요한 리소스의 결정

- 분석/설계/구현/실행/평가의 일정 관리

- 완료 조건의 결정

테스트제어의 주요 작업

- 테스트 결과에 대한 측정과 분석

- 진척상황, 커버리지, 완료 조건의 모니터링 및 문서화

- 계획과의 차이를 비교

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

 

2. 테스트 분석과 설계

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

- 테스트 상황을 식별하고 우선순위 선정

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

- 비공식적 테스트 기법으로 보완

- 테스트 데이터 식별

- 기반 시설 및 테스팅 도구의 식별

 

3. 테스트 구현과 실행

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

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

- 테스트 하네스 준비 (테스트 하네스 : 시스템 또는 컴포넌트 테스팅을 위해 코드 개발자가 생성하는 데이터 또는 코드)

- 테스트 수트 생성 (테스트 케이스 묶음)

- 테스트 환경 구축여부 확인

- 테스트 프로시저 수행

- 수행 결과 및 SW, tool, 테스트웨어 등을 기록

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

- 두 차이에서 오는 불일치를 인시던트(incidents) 또는 결함(defects)로 보고

- 원인 분석

- 수정 결과를 확인하기 위한 확인 테스트, 리그레션 테스트

 

심각도를 표현하는 용어는 사고 방지를 위해 모호하지 않게, 직관적으로 표현할 필요가 있다.

그러나 심각도와 처리해야할 우선순위는 별도로 구분해야 한다.

- 즉시 해결 (Resolve immediately)

- 주의 요망 (Give high attention)

- 대기 (Normal gueue)

- 낮은 순위 (Low priority)

 

4. 테스트 완료 조건과 리포팅

- 테스트 실행 결과가 계획에 명시된 완료 조건을 만족하는지 확인

- 추가 테스트 또는 완료 조건을 변경 해야 하는지에 대한 평가

- 보고서 작성

[리포팅에 포함되는 내용]

- 발견된 결함과 미해결 결함의 추이 및 우선순위

- 테스트 진척도

- 리스크 및 메트릭으로 실증된 조언

- 테스트 환경의 가용성

- 테스트 커버리지, 효과성/효율성, 품질 평가 결과, 결함 수, 테스트 일 수, 미해결 결함 등

 

5. 테스트 마감 활동

SW가 출시되거나 취소되었을 때, 모든 마일스톤이 달성되었을 때, 업데이트가 출시 완료되었을 때 마감 활동이 발생한다.

- 테스트 결과 마감 (산출물 확인, 인시던트 리포트, 변경 요구사항에 대한 처리, 시스템 인수의 문서화)

- 테스트웨어, 테스트 환경, 테스트 기반설비들을 차후 재사용을 대비하여 보관

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

- 테스트 프로세스 평가 및 개선

- 이후 활동에 지침이 될 수 있도록 교훈을 정리한다.

 

테스팅의 심리학

테스트 엔지니어의 독립성 확보는 결함과 장애를 찾아내는데에 효과적이다. (낮음 -> 높음)

1. 테스트 대상 SW개발자가 설계한 테스트

2. 다른 개발자가 설계한 테스트

3. 다른 그룹 또는 테스트 관계자가 설계한 테스트

4. 다른 조직 또는 다른 회사의 인원이 설계한 테스트(아웃소싱)

 

테스팅으로 발견한 결함이나 장애는 긍정적인 방법으로 의사소통할 필요가 있다.

테스터와 개발자간의 감정악화를 피할 수 있는 방법을 모색하여 진행한다.

"사람을 인스펙션하지 말고 SW를 인스펙션하라"