소프트웨어 테스팅의 기초

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

(1) 소프트웨어의 결함이 사람, 환경 또는 기업에 어떤 악영향을 끼치는가?

소프트웨어가 올바르게 동작하지 않는 경우 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 그리고 부상이나 사망에 이르기까지 다양하고 심각하다.

(2) 결함의 원인과 결과
결함의 원인 : 인간이 오류를 범하기 쉽기 때문에 발생하며, 시간적인 압박, 복잡한 코드, 기반환경(Infrastructure)의 복잡성, 기술이나 시스템의 변경, 그리고 수많은 시스템 상호간의 연동 등의 이유로 발생한다.
또한 방사, 자기, 전자기장, 물리적 오염 또한 소프트웨어의 결함을 유발시킬 수 있으며, 이러한 환경적인 조건이 하드웨어 조건을 변경시켜 소프트웨어의 실행에 영향을 미칠 수 있다.
결함의 결과 : 장애(Failure) 발생
(3) 테스팅이 필요한 이유

운영 환경 내에서 발생하는 결함들의 리스크(위험)를 줄이는데 기여할 수 있으며 소프트웨어 시스템의 품질 향상에도 도움을 준다.
(4) 품질 보증에서 테스팅이 필요한 이유를 설명하여라.
품질을 높이기 위해서는 이전 프로젝트를 통해 많은 테스트 경험과 정보를 확보하여야 한다. 다른 프로젝트에서 발견된 결함의 근본 원인에 대한 이해를 바탕으로 프로세스를 개선할 수 있으며, 그러한 결함의 재발을 방지함으로써, 결과적으로 차후 시스템의 품질을 개선할 수 있다.
(5) 오류(Error), 결함(Defect), 결점(Fault), 장애(Failure)와 같은 용어의 차이점을 구분 및 이해하고 실수(Mistake), 버그(Bug)와 관련 지어 설명하여라.
오류(Error) : 부정확한 결과를 초래하는 인간의 활동결함(Defect) : 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점결점(Fault) : 결함을 유발하는 잘못되거나 완전하지 못한 점장애(Failure) : 컴포넌트나 시스템에 예상된 인도나 서비스 또는 예상 결과와 실제적인 편차를 보이는 것


1.2 테스팅이란 무엇인가?


(1) 테스팅의 일반적인 목적- 남아있는 결함 발견
- 명세 충족 확인
- 사용자 및 비즈니스의 요구 충족 확인
- 결함 예방

(2) 테스팅의 보다 상세한 목적- 품질 수준에 대한 자신감(Confidence) 획득과 정보 제공
- 비즈니스 리스크를 감소시키는 정보에 근거한(Well-informed) 조언 제공(발견된 결함 기반의 수치적 데이터 활용)
- 개발 프로세스 점검, 이슈 제기
- 논리적 설계의 구현 검증(Validate)
- 시스템과 소프트웨어가 적절히 동작함을 확인


1.3 테스팅의 일반적인 원리


(1) 테스팅의 일반적인 원리
[원리 1 - 테스팅의 결함이 존재함을 밝히는 활동이다.]
→ 결함이 없는 것을 증명 불가
[원리 2 - 완벽한 테스팅(Exhaustive testing)은 불가능하다.]
→ 한 프로그램 내의 내부조건이 무수히 많을 수 있음(무한 경로)
→ 입력이 가질 수 있는 모든 값의 조합이 무수히 많음(무한 입력값)
→ GUI 이벤트 발생 순서에 대한 조합도 무수히 많음(무한 타이밍)
[원리 3 - 테스팅을 개발 초기에 시작한다.]
→ 가능 수명주기 초기에 시작
[원리 4 - 결함 집중(Defect clustering)]
→ 자체적으로 복잡한 구조를 가지고 있는 모듈
→ 소프트웨어나 시스템의 다른 부분 또는 다른 모듈과 다량의 복잡한 상호 작용을 하는 모듈(복잡한 인터페이스)
→ 개발 난이도가 높거나 최신 기술을 사용한 모듈
→ 기존에 개발된 것을 재사용하지 않고 새롭게 개발한 모듈
→ 크기가 큰 모듈
→ 경험이 미흡한 개발팀에서 개발한 모듈
[원리 5 - 살충제 패러독스(Pesticide paradox)]
→ 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면, 나중에는 더 이상 새로운 결함을 찾아내지 못한다.
[원리 6 - 테스팅은 정황(Context)에 의존적이다.]
→ 정황에 따라 다른 테스팅 방법 적용

[원리 7 - 오류-부재의 궤변(Absence-of-errors fallacy)]
→ 개발된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮다면 결함을 찾고 수정하는 과정은 아무 소용없다.



1.4 테스트 프로세스의 기초


(1) 테스트 계획에서부터 테스트 마감 활동까지의 기본적인 테스트 활동과 주요 업무

[계획과 제어(Planning and control)]
→ 테스트 목적/목표 설정 및 대상 연구→ 테스트 전략 개발 - 리스크 분석                            - 전략 수립→ 테스트 완료 조건→ 테스트 추정→ 조직 구성→ 테스트 계획 활동→ 테스트 관리 및 제어→ 리포팅(모니터링) - 리포팅 계획/설계
                            - 진행 리포팅

[분석과 설계(Analysis and design)]
→ 테스트 베이시스 검토→ 테스트 상황/요구사항/데이터 식별→ 테스트 기법 할당→ 테스트 용이성(testability) 평가→ 테스트 환경 구축

[구현과 실행(Implementation and execution)]
→ 테스트 케이스 명세화, 우선순위 선정, 데이터 생성, 프로시저 작성→ 선행 테스팅→ (재)테스팅 실행(결과 기록)→ 기대 결과와 비교

[완료 조건의 평가와 리포팅(Evaluating exit criteria and reporting)]
→ 완료 조건의 달성 여부 확인→ 최종 테스트 보고서 작성

[테스트 마감 활동(Test closure activities)]
→ 산출물 확인, 테스트웨어 보관→ 테스트 프로세스 평가(심사)



1.5 테스팅의 심리학


(1) 테스팅의 성공에 영향을 미치는 심리적인 요인

→ 다툼보다는 협력으로 시작한다.→ 소프트웨어를 개발한 "사람"에 대한 비평을 배제하고, 중립적이고 사실에 근거한 제품의 결함만을 전달하려고 노력한다.→ 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다.→ 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다.

(2) 테스터와 개발자간의 심리를 비교하여라.

테스터 : 개발자와의 의사소통과 친분을 개선할 수 있도록 최선을 다해야 함

개발자 : 테스터가 결함을 지적하는 불쾌한 소식만을 전하는 것으로 비추어 질 수 있음.
            테스팅을 종종 파괴적인 활동으로 간주.