[2011 실라버스 - Chapter.1] 소프트웨어 테스팅의 기초에 대해서 알아보자

※ "개발자도 알아야 할 소프트웨어 테스팅 실무"를 기반으로 요약 ※ 

 

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

1.1.2 소프트웨어 결함의 원인

결함은 인간이 오류를 범하기 쉽기 때문에 발생하며, 시간적인 압박, 복잡한 코드, 기반 환경의 복잡성, 기술이나 시스템의 변경, 그리고 수많은 시스템 상호 간의 연동 등의 이유로 발생한다.

 

장애는 이와 같은 결함에 의해서뿐만 아니라 환경적인 조건에 의해서도 발생한다. 즉, 방사 , 자기 , 전자기장, 물리적 오염 또한 소프트웨어의 결함을 유발할 수 있으며, 이러한 환경적인 조건이 하드웨어 조건을 변경시켜 소프트웨어의 실행에 영향을 미칠 수 있다.

 

1.2 테스팅이란 무엇인가?

현재의 테스팅은 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고, 최종적으로는 결함 데이터를 근간으로 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달하는 것이다.

 

테스팅의 일반적인 목적

- 남아있는 결함 발견

- 명세 충족 확인

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

- 결함 예방

 

부가적인 테스팅 목적

- 품질 수준에 대한 자신감 획득과 정보 제공

- 비지니스 리스크를 감소시키는 정보에 근거한 조언 제공

- 개발 프로세스 점검 , 이슈 제기

- 논리적 설계의 구현 검증

- 시스템과 소프트웨어가 적절히 동작함을 확인

 

테스팅은 관점에 따라 서로 다른 목적을 가지게 된다.

- 개발과정에서 테스팅의 주요 목적은 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애 상황을 만들어 내는 것이다.

- 인수 테스팅에서의 주요한 목적은 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정이다.

- 소프트웨어 품질을 평가하기 위한 테스팅은 특정 시간에 시스템을 출시하는 것의 리스크를 개발 프로젝트 관련자에게 전달하는 것이다.

- 유지보수 테스팅은 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하는 리그레션 테스팅의 과정을 포함한다.

- 운영 테스팅 기간의 주요한 목적은 신뢰성 또는 가용성과 같은 시스템의 특성을 평가하는 것일 수 있다.

 

1.3 테스팅의 일반적인 원리

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

[원리 2] 완벽한 테스팅은 불가능하다.

[원리 3] 테스팅을 개발 초기에 시작한다.

[원리 4] 결함 집중

- 출시 전 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보이며, 이러한 결함의 집중은 대부분 운영상의 장애를 초래한다.

[원리 5] 살충제 패러독스

- 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면 , 나중에는 더 이상 새로운 결함을 찾아내지 못한다. 시스템에 잠재된 보다 많은 결함을 발견하기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선할 필요가 있다.

[원리 6] 테스팅은 정황에 의존적이다.

[원리 7] 오류-부재의 궤변

- 결함이 없는 소프트웨어일지라도 사용자 또는 비즈니스의 요구를 충족시켜주지 못한다면 품질이 높다고 볼 수 없다.

 

1.4 테스트 프로세스의 기초

- 계획과 제어

- 분석과 설계

- 구현과 실행

- 완료 조건의 평가와 리포팅

- 테스트 마감 활동

1.4.1 테스트 계획과 제어

테스트 계획 수립 관련 주요 작업

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

- 테스트 범위 : 다른 시스템과의 인터페이스 정도, 관련 품질 특성, 호환성과 테스팅 범위, 커버하고자 하는 테스트 레벨 

- 리스크 기반 테스트 전략 : 각각의 테스트 레벨에 대해 테스트 대상 제품이 충족해야 할 품질 수준 및 특성과 기술적 어려움, 비즈니스 리스크를 고려한 테스트 전략 수립

- 테스팅의 목적 : 품질 요구 수준, 테스트 레벨 별 목적 , 커버하고자 하는 품질 특성

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

- 테스트 정책 : 조직 구조 형태 및 인력 구성 , 자격, 중점 테스트 타깃과 테스트 레벨, 테스트 프로세스 개선 방향 , 고객 및 이해관계자와의 관계 등

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

- 테스트 기법 및 대상 테스트 베이시스 포함 여부테스트 아이템 , 커버리지 , 테스팅에 참여할 팀의 식별과 팀 간 의사소통, 테스트 웨어 등

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

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

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

7. 테스트 완료 조건의 결정

 

테스트 제어의 주요한 작업

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

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

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

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

1.4.2 테스트 분석과 설계

1. 테스트 베이시스 리뷰

- 요구사항 명세서 , 아키텍처 , 개발 설계 문서 , 인터페이스

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

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

- 공식적인 테스트 기법을 활용한 테스트 케이스 도출

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

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

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

1.4.3 테스트 구현과 실행

1. 테스트 케이스 명세화 , 우선순위 선정, 데이터 생성, 프로시저 작성

2. 선행 테스팅

3. 테스트 실행

4. 기대결과와 비교

1.4.4 테스트 완료 조건과 리포팅

완료 조건의 평가와 관련된 주요한 작업

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

2. 추가적인 테스트가 필요한지, 아니면 명세된 테스트 완료 조건을 변경해야 하는지에 대한 평가 수행

3. 이해관계자에게 배포할 테스트 요약 보고서 작성

1.4.5 테스트 마감 활동

1. 테스트 결과 마감

- 예정된 산출물 확인

- 인시던트 리포트 종료

- 해결되지 않은 추가 및 변경 요구 사항에 대한 처리

- 시스템을 인수하는 것 문서화

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

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

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

5. 이후 릴리즈나 프로젝트 , 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석

 

1.5 테스팅의 심리학

테스팅의 독립성

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

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

3 - 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가가 설계한 테스트

4 - 다른 조직 또는 다른 회사의 인원이 설계한 테스트

 

 

Related References

- 도서 : 개발자도 알아야 할 소프트웨어 테스팅 실무

 

ISTQB

요약 : iso 표준, 국제 표준 iso, 국내 표준, 표준, istqb, kstqb, 웹 qa, 모바일 qa, 앱 qa, test web