7. 테스팅의 정의 [2]
테스팅
– 결함 발견과 격리 (때로는 예방까지)
– 결함 발견(Defect Detection-QC) 메커니즘
– 제품에 자신감 제공
– 결함 예방(Defect Prevention-QA)과 조화를 이루어야함
– 품질과 리스크에 대한 통찰 제공
– 테스팅은 수명주기와 프로세스를 갖는 프로젝트
– “테스트”는 실제 수행하는 하나하나의 실체
10. 테스팅 용어
에러(오류)
결 함
장애
사람의 실수에 의한 에러
원인은 사람
defect, bug, fault
에러에 의해 발생한 것
에러가 실제로 코드에 구현된 것
Failure
결함을 가진 SW실행하면 발생
Visible하게 보임
모든 결함이 장애로 가지는 않는다.
12. 소프트웨어 결함의 원인
소프트웨어의 결함을 발생시키는 원인 2가지
사람의 실수는 소프트웨
어 또는 시스템 코드에
결함을 야기
전자파, 자석, 공해, 자연현상
등과 같은 주변 환경의 영향
으로 소프트웨어 또는 시스
템이 사용하는 하드웨어에
영향을주어 오류를발생
인간의 실수 주변 환경에 의한 결함
소프트웨어의
결함
13. 소프트웨어 테스팅의 목적 [1]
주요 이유
– 잔존 결함 발견
– 개발 시스템/SW에 대한 자신감 부여
– 결함을 미연에 방지
– 명세 충족 확인
– 사용자 및 비즈니스의 요구 충족 확인
– 비즈니스 리스크를 감소시키는 정보 제공(발견된 결함 기
반의 수치 데이터 제공)
기타 이유
– 개발 프로세스 점검
– 논리적 설계의 구현 검증
– 시스템/SW가 적절히 동작함을 확인
14. 소프트웨어 테스팅의 목적 [2]
테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질 수
있다.
개발과정: 소프트웨어의 결함을 찾아내고 수정하기 위해
서 가능한 많은 장애의 원인을 발생시킴
인수과정: 예상된 대로 시스템이 동작하는지 확인하고, 요
구사항에 맞는지 확신을 얻는 과정
품질평가: 특정시간에 시스템을 출시하는 것의 리스크를
개발 프로젝트 관련자에게 전달
유지보수: 변경사항을 추가적으로 개발하는 중에 새로운
결함이 유입되었는지 확인하는 테스팅 과정 포함
운영: 신뢰성 또는 가용성과 같은 시스템의 특성을 평가
15. 소프트웨어 테스팅의 목적 [3]
전통적 테스트 개념
소프트웨어의
정상 작동 여부 확인
현재의 테스트 개념
사용자의 기대수준과
요구사항에 맞게
구현되고 동작하는지
확인
최종 목표
결함 데이터를 근간으로 소프트웨어의
리스크 정보를 정량적 수치화하여
의사결정권자에게 전달
16. 테스팅과 디버깅의 차이
결함을 발견하기 위한 활동
테스트는 공정상의 결함을 발견할 수 있다.
시스템이 정지되는 결함과 정지가 되지 않는 결함
이 모두 포함된다.
테스팅
디버깅 결함의 원인을 찾고, 코드를 수정하는 개발활동
디버깅 후 테스터에 의해 확인 테스팅을 수행하여
결함이 제대로 고쳐졌는지 확인이 필요
17. 테스팅의 특성
완벽한 테스트는 불가능
– 한 프로그램 내의 내부조건이 무수히 많을 수 있음
– 입력이 가질 수 있는 모든 값의 조합이 무수히 많음
– 이벤트 발생순서에 대한 조합도 무수히 많음
테스트는 결함이 없음을 보이려는 것이 아님
본인이 만든 프로그램의 결함을 발견하기는 쉽지 않음
현실적인 테스팅의 목적
– 주어진 리소스(시간, 인력 등)로 리스크가 높은 시스템 부
분의 결함을 발견할 확률을 극대화 -> 리스크 최소화
23. 소프트웨어 테스팅에 대한 오해
시간, 인력이 부족해서 테스팅을 제대로 못한다.
테스트는 완벽하게 수행될 수 있다.
테스트는 그리 어려운 작업이 아니다.
아무나 테스트를 수행할 수 있다.
프로그램이나 시스템이 잘 수행될 수 있음을 보여주는 것이
다.
테스트는 개발 이후의 작업이다.
개발일정에 따라 테스트는 생략될 수 있다.
24. ISTQB에서 제시하는 테스팅 원칙
1. 테스팅은 결함이 존재함을 밝히는 활동이다.
2. 완벽한 테스팅은 불가능하다.
3. 테스팅은 개발 초기에 시작된다.
4. 결함 집중
5. Pesticide Paradox(살충제 패러독스)
6. 테스팅은 정황(context)에 의존적이다.
7. 오류-부재의 궤변
25. ISTQB에서 제시하는 테스팅 원칙 [1]
1. 테스팅은 결함의 존재를 보여 준다.
• 테스팅은 결함이 있다는 것을 보여줄 수 있지만, 결함
이 없다는 것을 증명할 수는 없다.
• 테스팅은 소프트웨어에 존재하는 결함 수를 낮출 수 있
지만, 가령 테스팅을 통해 아무런 결함을 발견하지 못
했다고 하여도 결함이 전혀 없다고는 증명할 수 없다.
26. ISTQB에서 제시하는 테스팅 원칙 [2]
2. 완벽한 테스팅은 불가능하다.
• 일반적으로 평범한 경우를 제외하고 모든 것(모든
input과 전제 조건의 조합)에 대한 테스팅은 불가능하
다.
• 완벽한 테스팅 대신, 리스크와 중요도가 높은 영역에
집중하는 것이 좋다.
27. ISTQB에서 제시하는 테스팅 원칙 [3]
3. 테스팅은 개발 초기에 시작한다.
• 테스팅 활동은 소프트웨어 또는 시스템 개발 수명주기
의 초기부터 시작되어, 수명주기와 상응하는 목적들에
집중하여야 한다.
4. 결함 집중
• 테스팅 활동은 소프트웨어 또는 시스템 개발 수명주기
의 초기부터 시작되어, 수명주기와 상응하는 목적들에
집중하여야 한다.
28. ISTQB에서 제시하는 테스팅 원칙 [4]
5. Pesticide Paradox(살충제 패러독스)
• 같은 테스트 케이스를 가지고 테스트를 계속해서 반복
하면 결국은 버그가 발견되지 않을 것이다.
• 이러한 “살충제 패러독스” 현상을 방지하기 위해서는
지속적으로 테스트 케이스를 검토하고 개정해야 한다.
• 소프트웨어의 다른 부분을 테스팅할 때에는 잠재적인
결함을 발견하기 위하여 새롭고 다른 테스트를 작성해
야 한다.
29. ISTQB에서 제시하는 테스팅 원칙 [4]
6. 테스팅은 정황에 의존적이다.
• 테스팅은 그 대상에 따라 다르게 수행되어야 한다.
• 예를 들어, 안전을 중요시하는 소프트웨어는 일반 웹사
이트의 테스트와 다르게 수행되어야 하는 것을 말한다.
7. 오류-부재의 궤변
• 결함을 찾고 고쳤다고 해도 시스템이 사용자가 원하는
필요성에 맞도록 개발되지 않았다면 테스팅은 아무런
도움이 되지 않는다.
30. 품질관리에서의 테스팅[1]
소프트웨어 테스팅은 문제를 포착하고 방지할 수 있는 활동
프로세스 또는 관리적인 부분에 대한 품질향상과 달리 테스팅
은 소프트웨어 제품의 품질에 직접적인 영향을 미칠 수 있다.
일반적으로 테스팅은 소프트웨어 개발이 70%~80% 이
상 완성이 된 상태에서 실시되는 경우가 많다.
소프트웨어의 품질을 높이기 위해서는 개발이 되는 과정
에서부터 테스팅이 필요하다(즉, 코딩 즉시 테스트).
이렇게 하면 사람의 실수로 인한 오타에서 기술적인 결
함까지 예방할 수 있다.
31. 품질관리에서의 테스팅[2]
테스팅을 통해 발견된 결함에서 소프트웨어의 품질을 측정할
수 있다.
소프트웨어의 기능성 뿐만 아니라, 신뢰성, 사용성, 효율
성, 유지보수성 등과 같은 특징적인 부분이 포함될 수 있
다.
만약 테스팅을 통해 낮은 수준의 결함만 발견된다면 소
프트웨어의 품질은 좋다는 의미가 된다.
또한, 엄격하게 작성된 테스트 케이스를 만족시킨다면
해당 소프트웨어의 전체적인 위험을 감소시킬 수 있다.
소프트웨어의 결함이 발견되어 고쳐진다면, 자연스럽게
해당 소프트웨어의 품질은 높아진다.
32. 품질관리에서의 테스팅[3]
관리적인 차원에서 문서화에 충실하고 잘 기록된다면,
새롭게 개발할 소프트웨어에서는 앞서 발견된 결함과
문제들을 참고하여 사전에 문제를 예방할 수 있다..
33. 어느 정도의 테스팅이 적절한가? [1]
테스팅은 많이 할수록 좋겠지만, 현실적인 제약이 있다.
일정 비용
조직의
성숙도
제약사항
34. 어느 정도의 테스팅이 적절한가? [2]
기술적 요인, 비즈니스적 요인, 제품의 특성, 제품의 리스크 수
준 등과 같은 다양한 요소들에 대한 고민이 필요
의사결정권자(경영진, 프로젝트 관리자)에게 소프트웨어에 대
한 충분한 정보(필요일정, 비용 등)를 제공해서 테스팅 규모를
산정할 수 있도록 해야 한다.
35. 테스팅 프로세스
ISTQB에서 제시하는 테스트 프로세스
1. 계획과 통제
2. 분석 및 설계
3. 구현과 실행
4. 완료 조건의 평가와 리포팅
5. 테스트 마감 활동
36. 1. 테스트 계획 및 제어(통제) [1]
테스트 계획
– 테스트 계획은 테스팅의 미션과 목표를 정의하고 이를 만
족시키기 위한 테스트 활동들을 수립하는 과정
– 테스트 계획은 모니터링 및 통제 활동의 피드백에 따라 조
치를 할 수 있도록 수립되어야 할 것
1. 테스트를 위한 자원 파악(인적자원, 테스트환경, PC사양 등)
2. 테스트 정책 및 테스트 전략 수립
3. 테스트 분석 및 설계 업무 일정 관리
4. 테스트의 적용, 실행, 평가에 대한 일정 관리
5. 종결 기준 결정
해야할 일
37. 1. 테스트 계획 및 제어(통제) [2]
테스트 통제
– 테스트 통제는 실제 진행 상황과 계획을 비교하고 보고하
는 활동
– 여기에는 프로젝트의 미션과 목표를 위해 조치가 이루어
질 수 있음
– 이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어
야 할 것
1. 결과 측정 및 분석
2. 모니터링 및 문서화의 진행, 테스트 범위, 종결기준
3. 결과반영(수정, 변경 등) 활동
4. 의사결정
해야할 일
38. 2. 테스트 분석 및 설계
테스트 계획에서 제시된 목표를 테스트 설계로 반영
1. 테스트의 기반이 되는 자료 리뷰(요구사항, 디자인 등)
2. 테스트 대상 아이템 또는 명세, 구조 분석을 통해 테스트 상
황을 식별하고 우선 순위 선정
3. 테스트 케이스 설계와 우선 순위 선정
4. 비공식적인 기법으로 테스트 케이스 추가 도출 및 보완
5. 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별
6. 테스크 환경 구축에 대한 디자인과 요구되는 기발 시설 및
도구 식별
해야할 일
39. 3. 테스트 구현 및 실행
테스트의 조건들을 테스트 케이스로 전환하고 이를 위한 환
경을 갖추는 일련의 활동
1. 테스트 케이스의 개발과 중요도 결정, 테스트 데이터 생성, 테스트 절차
수립
2. 효과적인 테스트를 위한 테스트 케이스의 그룹인 테스트 suit 생성
3. 테스트 환경이 제대로 설정되었는지 확인
4. 계획된 절차에 따라 테스트 케이스를 직접 또는 툴을 사용하여 수행
5. 테스트 실행결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전을 기
록
6. 실제 결과와 기대결과를 비교
7. 불일치하는 결과가 나오는 원인을 기록
8. 각각의 불일치에 대한 반복적인 활동
해야할 일
40. * 결함 유형 분류
기획 시 유입되는 결함
– 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전,
불일치, 기타 결함
설계 시 유입되는 결함
– 설계 표준 미준수, 테스트불가능, 불명확, 불완전, 불일치,
인터페이스 결함, 기타 결함
코딩시 유입된 결함
– 코딩 표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이
터 결함, 기타 결함
테스트 부족으로 유입된 결함
마무리 부족, 팀간 의사소통 부족, 코딩 실수
41. * 결함 심각도 별 분류
결함심각도 분류 사례
– 치명적, 매우 심각, 심각, 보통, 경미
– 치명적 결함, 주요 결함, 일반 결함, 사소한 결함, 개선사항
(37쪽 참조)
부적절한 사례
– Major, Minor, Tirfle
– A,B,C
42. 결함 우선순위
결함 심각도와 결함 우선순위는 구분해야한다.
모든 경우 결함심각도가 가장 높다고 해서 가장 먼저 그 결함
을 수정해야 하는 것은 아니다.
결함 우선순위 표현 사례
– 즉시 해결
– 주의 요망
– 대기
– 낮은 순위
43. 4. 완료조건의 평가와 리포팅
테스트 수행 결과를 목적과 비교하여 평가
1. 테스트 계획에 정의된 종결 기준에 따라 테스트 로그 확인
2. 추가 테스트가 필요한지에 대한 평가를 하거나 종결 기준을
변경
3. 이해관계자들을 위한 테스트 요약 보고 작성
해야할 일
44. 리포팅 내용
발견된 결함과 미해결 결함의 추이 및 우선순위
테스트 진척도
리스크 및 메트릭으로 실증된 조언
테스트 환경의 가용성
테스트 커버리지, 결함발견 효과성/효율성, 품질평가 결과, 결
함 상태별 결함 수, 소프트웨어 사이즈 대비 결함 수 등
45. 효과적/효율적
효과적(Effective)
– 계획되었거나 원했던 테스트 결과산출
– 효과적 테스터는 테스팅 노력으로부터 어떤 결과를 도출
할 것인지 결정함
효율적(Efficient)
– 원했던 테스트 결과 산출을 생산적(효율적)으로 수행
– 효율적 테스터는 가용한 리소스(시간, 자금, 인력)를 적절
하고 현명하게 배치
효과적
효율적
46. 5. 테스트 마감 활동
모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합
하기 위해 데이터를 수집하고 완료
1. 계획된 산출물이 산출되었는지에 대한 확인, 개별 요소에 대
한 보고 종결, 또는 아직 수행중인 활동의 변경 기록에 대한
이슈 제기
2. 시스템 인수와 관련된 문서 확인
3. 유지보수 조직에 테스트 도구 인계
4. 사후 관리 및 테스트 성숙도 향상 수준 분석
해야할 일
47. 테스팅의 독립성
개발자가
테스트를 설계하는
경우
(낮은 수준의 독립성)
개발팀내
다른 조직의 인력이
테스트를 설계하는
경우
사내
다른 조직의 인력이
테스트를 설계하는
경우
(별도의 테스트팀)
다른 조직 또는
기업의 인력이
테스트를 설계하는
경우
(외부기관 인증)
48. 테스팅의 제약
테스팅을 투자가
아닌 불필요한
비용으로 간주함
관리자나 테스터가
테스팅에 대하여
단편적인 지식만
가지고 있음
부족한 인력과
자원으로 인해
테스팅에 대한
투자여력 없음
의사결정권자나
프로젝트 관리자가
테스팅에 대한
인식이 부족함
