ISTQB Syllabus 2005 통합정리 (1. Fundamentals of testing)

 

원문 : http://blog.naver.com/josephy74/70018639453
문제가 될 경우 바로 연락주세요. 바로 삭제하겠습니다.


1. Fundamentals of testing

 

1.1 왜 테스팅이 필요한가?

 

1.1.1  소프트웨어 시스템 환경 (K1)

소프트웨어 시스템들은 비지니스 응용 프로그램(ex 뱅킹 프로그램)에서 소비재(ex 자동차)까지 생활에 있어서 차지하는 부분이 증가하고 있다. 대부분의 사람들은 소프트웨어가 (자신들이) 예상한 것처럼 동작하지 않은 경험을 가지고 있다. 소프트웨어가 올바르게 동작하지 않는 것은 비용, 시간 또는 사업적인 평판을 포함한 많은 문제를 야기시킬수 있으며, 심지어 상해나 사망의 원인이 될 수도 있다.

1.1.2 소프트웨어 결함의 원인(K2)

 

인간은 문서내에서, 시스템이나 소프트웨어에서, 코드내에서 결함을 생성하는 에러(실수)를 만들수 있다. 만약 코드내의 결함이 실행되면, 시스템은 의도한 동작을 하지 못하고(또는 해서는 않되는 동작을 하고), 이는 실패의 원인이 된다. 소프트웨어, 시스템 혹은 문서상의 결함들은 실패의 원인이 될 수 있지만 모든 결함들이 실패(failures)의 원인이 되는 것은 아니다.

 

결함(Defects)은 인간이 오류에 빠지기 쉽고, 시간의 압박이나 복잡한 코드, 하부 구조의 복잡성, 기술의 변경, 그리고/또는 많은 시스템들의 상호작용 때문에 생긴다.

 

실패(Failures)는 환경적인 조건이 원인이 될 수 있다. 발열, 자기장, 전기장, 그리고 오염은 펌웨어(firmware)내의 결점(faults)의 원인이 될 수 있으며, 하드웨어 조건의 변경은 소프트웨어가 동작하는데 영향을 줄 수 있다.

 

1.1.3 소프트웨어 개발, 유지, 운용에 있어서 테스팅의 역할

 

만약 발견될 결함들이 시스템이 운영을 위해 릴리즈되기 전에 고쳐진다면, 시스템과 문서에 대한 엄격한 테스팅은 운영 환경내에서 발생하는 문제들의 위험을 줄이는데 도움이 될 수 있으며, 소프트웨어 시스템의 품질에도 도움을 준다.

 

소프트웨어 테스팅은 계약상(법적) 요구조건들, 또는 산업에 특화된 표준들을 만족시키기 위하여 요구될 수 있다.

 

1.1.4 테스팅과 품질

 

테스팅 발견된 결함으로 소프트웨어의 기능적/ 비기능적 요구사항과 특성들 - (신뢰성(reliability), 사용성(usability), 효율성(efficiency), 그리고 유지보수성(maintainability)) - 을 만족시키는 것에 대한 소프트웨어의 품질을 측정하는 것이 가능하다.

 

비기능적인 테스팅에 대한 더 많은 내용을 위해서는 2장을 보면 된다. 소프트웨어 특성에 대한 더 많은 정보를 원한다면 'Software Engineering - Software Product Quality'(ISO 9126)을 보라.

 

만약 발견된 결함이 없거나 그 수가 적다면, 테스팅은 소프트웨어 품질에 대한 확신을 줄 수 있다. 적절하게 설계된 테스트를 통과하는 것은 시스템이 가지는 위험(Risk)의 전반적인 수준을 낮춘다. 테스팅이 결함을 발견하고, 이러한 결함들이 수정될 때, 소프트웨어의 품질은 높아진다.

 

학습자들은 이전 프로젝트에서 배워야 한다. 다른 프로젝트들에서 발견된 결함의 근본 원인을 이해함으로써, 이러한 결함들이 다시 발생하는 것을 방지하고 프로세스가 향상 될 수 있으며, 결과적으로는 향후 시스템의 품질이 향상되게 된다. 테스팅은 품질 보증 활동(Quality assurance activities)의 하나로써 통합되어야 한다.

 

1.1.5 얼마만큼의 테스팅이 적당한가?

 

얼마만큼의 테스팅이 적당한가를 결정하는 것은 기술적인 산출물과 업무적인 산출물, 프로젝트 위험, 그리고 시간과 비용 같은 프로젝트 제약사항을 포함한 위험 수준을 고려해야만 한다 (위험에 대해서는 5장에서 더 논의된다.)

 

테스팅은 다음 개발 단계나 고객에 양도를 위하여, 테스트 되는 시스템이나 소프트웨어의 릴리즈에 관한 확실한 결정을 내릴 수 있도록, 이해당사자(stakeholders)에게 충분한 정보를 제공해야 한다.

===========================================================================

◆ 테스팅이란

 => 시스템에서 결함을 찾는 것이다.
 => 결함 발견 및 수정 (때때로 예방까지)
 => 테스트는 실제 수행하는 하나하나의 실체이다.
 => 주로 결함 발견 (Defect Dectection -QC) 메커니즘을 의미하지만,

      결함 예방 (Defect Prevention -QA)과 조화를 이뤄야 한다.
 => Test case를 만들어 실행하는 것 뿐 아니라
      테스팅 전략 수립과 계획/ 설계/ 결함 수정과 도구의 사용등 포괄적인 의미이다.

▪  IEEE의 정의  

"소프트웨어의 테스트는 수동이나 자동으로 시스템을 시험 작동시키고 평가하는 작업으로 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과와의 차이를 인식하기 위한 목적을 가진다."  

===========================================================================

 

1.2 What is testing

 

일반적으로 테스팅이란 소프트웨어를 실행하는 것처럼 테스트를 수행하는 것이다라고만 생각 할 수 있지만, 이것은 테스팅의 한 영역이지 전부는 아니다.

 

테스트 활동은 테스트 계획과 통제, 테스트 조건의 선택, 테스트 케이스(test case) 디자인, 그리고 결과의 확인과 완료 특성(criteria) 평가, 테스트 프로세스와 테스트하는 시스템에 대한 보고, 최종 승인과 (테스트 국면(phase)이 완수된 후의) 종료 작업 같은 테스트 실행 전과 테스트 실행 후에 모두 존재한다. 테스팅은(소스 코드를 포함한) 문서의 리뷰와  정적 분석(static analysis) 역시 포함한다.

 

동적 테스팅(Dynamic Testing)과 정적 테스팅(Static Testing) 모두 비슷한 목표를 이루기 위하여 사용될 수 있으며, 테스트 될 시스템과 개발/테스팅 프로세스 모두를 개선 시킬수 있는 정보 또한 제공할 것이다.

 

다음과 같은 여러가지 테스팅 목적이 있을 수 있다.

 

* 결함(defects)의 발견
* 품질 수준에 대한 확신을 얻고, 정보를 제공하는것
* 결함의 방지

 

개발 주기(life cycle) 초기에 테스트를 설계하는 프로세스를 생각하는 것(테스트 설계를 통하여 테스트 기본 사항들을 검증하는 것)은 코드 속에 포함되는 결함들을 예방하는데 도움을 줄 수 있다. 문서들(예를 들어 요구사항 문서)을 검토하는 것 역시 코드에 나타나는 결함을 방지하는데 도움을 준다.

 

테스팅에 대한 여러가지 관점들은 각기 다른 여러가지 목적을 가진다. 예를 들어, 개발 테스팅(Development Testing - 예를 들어 컴포넌트 테스팅, 통합 테스팅 그리고 시스템 테스팅)에서의 주된 목적은 소프트웨어에서 실패(failure)의 원인이 될 수 있는 결함(defects)을 가능한 한 많이 확인하고 고치는 것이다. 승인 테스트(Acceptance Test)에서 주된 목적은 시스템이 예상대로 작동하는 것을 확인하고, 시스템이 요구사항을 만족한다는 확신을 얻는 것이다.

 

어떤 경우에는, 결함을 고치려는 의도가 아니라 단지 소프트웨어 품질 평가가 테스팅의 목적이 되기도 한다. 이런 품질 평가 결과로 이해당사자는 계획된 시간의 시스템 릴리즈는 위험하다는 것을 알 수 있다.

 

유지보수 테스팅(Maintenance Testing)은 종종  개발 동안의 변경에 기인한 새로운 에러들이 없다는 것을 알려주는 테스트를 포함한다. 운영 테스팅(Operational Testing) 동안에 주된 목적은 신뢰성(reliability)과 가용성(availability)와 같은 시스템의 특성을 평가하는 것이 될 수 있다.

 

디버깅(Debugging)과 테스팅은 다른 것이다. 테스팅은 결함(defects)에 의한 실패(failures)를 보여줄 수 있다. 디버깅은 결점의 원인을 확인하고, 코드를 수정하고, 결점이 올바르게 고쳐졌는가(fixed)를 확인하는 개발 활동(development activitiy)이다. 테스터에 의한 계속되는 확정 테스팅(confirmation testing)은 실패(failure)가 실제로 고쳐졌다는 것을 보증한다. 각각의 활동(activity)에 대한 책임(responsibility)는 매우 다르다. 예를 들어 테스터(tester)는 테스트에 대한 책임이 있고, 개발자(developer)는 디버깅에 대한 책임이 있다.

 

테스팅 프로세스(testing process)와 활동(activities)은 1.4절에서 설명된다.

 

===========================================================================

◆ 테스팅의 목적

소프트웨어를 개발하는데 있어 실수와 오류를 범할 가능성은 매우 높다. 테스팅은 개발자, 사용자 모두 자신의 불완전함과 실수를 가정하는데서 출발한다. 테스트는 인간의 불완전성을 극복하고 높은 품질의 제품을 만들기 위한 노력이다. 모든 가능한 데이터를 사용하여 모든 경우의 수에 대하여 철저히 시험하는것은 일반적으로 가능하지 않다. 결국 선택된 데이터를 기초로 시험이 이루어지며 높은 확률로 버그를 찾아낼 수 있도록 좋은 테스트 케이스(test case)를 만들어야 한다.

 

소프트웨어 시험의 목적은 "소프트웨어의 품질을 향상시키기 위하여 결함(defect)을 발견하는 것"이다.

 

주요 이유

- 잔존 결함 발견
- 명세 충족 확인
- 사용자 및 비지니스의 요구 충족 확인
- 비지니스 리스크를 감소시키는 Well-informed 조언 제공

  (발견된 결함 기반의 수치적 데이터 제공)

 

기타 이유

- 개발 시스템/SW에 대한 자신감 부여
- 개발 프로세스 점검, 이슈제기
- 논리적 설계의 구현 검증 (Validate)
- 시스템/SW가 적절히 동작함을 확인

 

주의사항)

1. 완벽한 테스트는 불가능하다.

2. 테스트는 오류가 없음을 보여주려는 것이 아니다.

3. 주어진 시간과 인력 및 리소스로 오류를 발견할 확률이 높은 테스트 케이스를 찾아내고 실행 해야 한다.

4. 한계를 인정해야 한다.(모든 입력값을 테스트 할 수 없음, 모든 경로(Path)를 테스트 할 수 없음, 모든 타이밍을 테스트할 수 없음)

 

◆ Testing ROI (Return On Investment)

품질비용  (Cost of poor quality)

▪ Cquality = Cconformance + Cnon-conformance
▪ Conformance costs : 테스팅(결함 발견)과 QA (결함 예방)
          - 수동/자동/정적 테스팅 (QA 제외)
▪ Non-conformance costs : 결함 수정, 재시험(retesting), 불만족 고객대응, 회사 이미지 손상, 사업 기회 상실 등
          - 결함수정 (수치화 하기 어려운 것들 제외)

===========================================================================

 

1.3 General testing principles

 

원칙

 

지난 40년에 걸쳐 많은 수의 테스팅 원칙들이 제안되었다. 그리고 모든 테스팅에 대하여 가이드라인이 제공되었다.

 

원칙 1 - 테스팅은 결함의 존재를 보여준다.

 

테스팅은 결함(defect)이 존재하는 것을 보여줄 수 있다. 그러나 결함이 없다는 것을 증명하진 못한다. 테스팅은 소프트웨어에 확인되지 않은 결점이 남아 있을 확률을 줄인다. 그러나 결점이 발견되지 않는다고 하여도 이것이 완전하다는 증명이 될 수 없다.

(= 테스트 작업으로 버그가 존재하지 않는다는 사실을 입증할 수 없다.)

 

원칙 2 - 소모적인 테스팅은 불가능하다.

 

사소한 경우를 제외하고 모든 것을 테스팅하는 것(입력과 선행조건의 조합)은 불가능하다. 소모적인 테스팅 대신에, 우리는 위험(risk)와 우선순위(priorities)를 이용하여 테스팅하는데 드는 노력에 초점을 맞춘다.

 

프로그램을 완전히 테스트하는 것은 불가능하다. 간단한 소프트웨어라고 해도 프로그램을 완전히 테스트하는 것은 불가능하다. 불필요하다고 느껴서 혹은 시간을 절약하기 위해 특정 조건에서의 테스트를 건너뛰기로 결정하는 것은 프로그램을 완전히 테스트하지 않는다는 것을 뜻한다.

 

모든것을 테스트하려고 하면 비용은 엄청나게 증가하며 놓치게 되는 버그의 숫자는 일정 수준으로 감소하기 때문에 이와 같은 작업을 계속하는 것은 비용 면에서 효율적이지 못하다. 테스트를 축소시키거나 테스트할 대상에 올바른 판단을 내리지 못하면 비용은 감소하지만 많은 버그를 방치하게 된다. 따라서 너무 많지도 적지도 않은 적절한 양의 테스트 작업을 수행하는 것이 중요하다.

 

원칙 3 - 초기 테스팅(Early Testing)

 

소프트웨어나 시스템 개발주기에서 가능한 빨리 테스트 활동을 시작하여야 하며, 정의된 목표에 초점을 두어야 한다.

 

원칙 4 - 결점의 군집화(Defect Clustering)

 

작은 수의 모듈이 선행 배포(Pre-release)  테스팅 동안에 발견된 대부분의 결함을 포함하거나, 대부분의 운영 실패(oprational failure)를 보여준다.

종종 테스터들이 오랜 시간 동안 버그를 발견하지 못하다가 하나를 발견하면, 바로 또 다른 버그들을 연이어 발견하는 것을 볼 수 있다. 그 이유는
 - 프로그래머들도 사람이기 때문에 작업 품질이 일정하지 않을 수 있기 때문이다
 - 프로그래머도 사람이기 때문에 습관에 따른 특정 오류를 만들어 내며 같은 실수를 반복할 수 있다.
 - 소프트웨어의 설계나 구조에 근본적인 결함이 있는 경우가 많다. 이런 경우 여러 개의 관계 없는 버그가 발견되지만 나중에 모든 버그가 하나의 심각한 원인으로부터 생긴 것임을 발견 할 수 있다.

 

원칙 5 - 살충제 패러독스(Pesticide paradox)

 

동일한 테스트가 계속적으로 반복된다면, 실제적으로 동일한 테스트 케이스의 집합은 더 이상 새로운 버그를 발견하지 못할 것이다. 이러한 "살충제 패러독스(Pesticide paradox)"를 극복하기 위해서는 테스트 케이들이 주기적으로 검토되고 새로이 고안되어야 하며, 잠재적으로 좀 더 많은 결함을 발견하기 위하여 소프트웨어나 시스템의 다양한 부분들을 실행하도록 다양한 테스트 케이스들(test cases)을 작성해야 한다.

 

소프트웨어나 시스템에 대한 잠재적인 더 많은 결점을 발견하기 위하여 여러 부분을 테스트하기 위해 작성된 다양한 새로운 테스트들이 필요하다.

 

원칙 6 - 테스팅은 내용(context)에 종속적이다.

 

테스팅은 다양한 내용에 따라서 다르게 행하여진다. 예를 들어, 안전에 민감한 소프트웨어는 전자 상거래 사이트와는 다르게 테스트 된다.

 

원칙 7 - 에러 부재 오류

 

만일 구축된 시스템이 쓸모 없으며, 사용자의 요구와 기대를 채우지 못한다면, 결함을 찾고 고치는 것은 의미가 없는 일이다.

 

===========================================================================

이외에도 소프트웨어 테스팅은 위험을 수반하는 훈련이다

 

소프트웨어 테스터가 배워야 할 한가지 중요한 개념은 많은 영역의 테스트 대상을 테스트 가능한 범위로 축소하는 방법이다. 이렇게 하려면 무엇이 중요하고 무엇이 중요하지 않은지에 대하여 현명하게 판단하는 방법을 알아야 한다.

 

발견한 모든 버그를 수정할 수 없다.

 

소프트웨어 테스트 작업의 실상 중 하나는 버그를 찾아내기 위해 기울였던 많은 노력에도 불구하고 발견된 버그를 모두 수정할 수 없다는 사실이다.

 

버그를 수정하지 않기로 결정하는 이유는 아래와 같다.

- 쫓기는 작업 일정

- 진짜 버그가 아닌 경우

- 고치기 위험한 버그

- 고칠 가치가 없는 버그

 

* 버그라고 말하기 힘든 버그도 있다.

* 제품 명세서는 결코 최종적인 것이 아니다.

* 소프트웨어 테스팅은 훈련이 필요한 전문 기술이다.

 

◆ "Effective" Testing and "Efficent" Testing

 

▪ Why?
  - 모든 결함을 발견하는 것은 불가능할 뿐 아니라 모든 것을 테스트하기에는 시간, 자금, 인력이 언제나 부족하다. 따라서 Must E&E

 

▪ Effective
   - 계획되었거나 원했던(decided or desired) 테스트 결과 산출
   - 효과적 테스터는 테스팅 노력으로 부터 어떤 결과를 도출할 것인지를 결정함
   - "Risk based testing"

 

▪ Efficient
   - 원했던(desired) 테스트 결과 산출을 생산적 (효율적)으로 수행
   - 효율적 테스터는 이용가능한 리소스(시간, 비용, 인력)을 적절하고 현명하게 배치한다.

===========================================================================

 

1.4 Fundamental test process

 

테스팅의 가장 명백한 부분은 테스트를 실행하는 것이다. 그러나 효과적이고 효율적인 테스팅이 되기 위해서는 테스트를 계획하고, 테스트 케이스를 설계하고, 실행을 준비하고 상태를 평가하는데 보내는 시간 역시 포함되어야 한다.

 

기본적인 테스트 프로세스는 다음의 주된 액티비티들(activities)로 구성된다.

 

• 계획과 통제 (Planning and Control)
• 분석과 설계 (Analysis and Design)
• 구현과 실행 ( Implementation and Execution)
• 종료 기준의 평가와 보고 (Evaluating exit criteria and Reporting)
• 테스트 종료 액티비티들 (Test closure activities)

 

논리적으로는 순차적이지만, 프로세스내에서 액티비티들은 중첩되거나 동시에 진행될 수 있다.

 

1.4.1 테스트 계획(Planning)과 통제(Control)

 

테스트 계획(Test planning)은 테스트의 목적과 임무(mission)를 만족시키기 위하여  테스팅의 임무을 검증하고, 테스팅의 목적과 테스트 액티비티들의 명세를 정의하는 액티비티이다.

테스트 통제(Test Control)은 실제 진행상황과 계획을 비교하고, 계획의 오차를 포함한 진행 상태를 보고하는 계속 진행되는 액티비티이다. 테스트 통제는 프로젝트의 임무와 목표를 만족시키기 위하여 필요한 액션들(actions)을 포함한다. 테스팅을 통제하기 위해서는, 프로젝트 전체에 걸쳐 모니터링 되어야 한다. 테스트 계획은 모니터링과 통제 액티비티로 부터 피드백(feedback)을 받는다.

 

테스트 계획(Test Planning)은 다음의 주요 작업들(tasks)을 포함한다.

 

• 테스팅의 범위(scope)와 위험(risk)를 결정하고, 테스팅의 목표를 정한다.
• 테스트 방법을 정한다.(기법, 테스트 항목, 적용 범위, 테스팅에 포함되는 팀들간의 정의와 조정, 테스트웨어)
• 요구되는 테스트 자원을 정의한다. (e.g 인력, 테스트 환경, PC등)
• 테스트 정책과/또는 테스트 전략을 결정한다.
• 테스트 분석과 설계 작업을 계획한다.
• 테스트 구현과 실행 그리고 평가를 계획한다.
• 종료 기준을 결정한다.

 

테스트 통제(Test Control)는 다음의 주요한 작업들을 포함한다.

 

• 결과의 측정과 분석
• 프로세스, 테스트 커버리지(test coverage), 그리고 종료 기준(exit criteria)의 모니터링과 문서화
• 올바른 동작의 초기화
• 의사결정

 

1.4.2 테스트 분석(Analysis)과 설계(Design)

 

테스트 분석과 설계는 일반적인 테스팅 목표를 구체적인 테스트 조건과 테스트 설계로 변환하는 액티비티이다.

 

테스트 분석과 설계는 다음의 주요한 작업을 포함한다.

 

• 테스트 관련 기본사항을 검토한다.(요구사항, 아키텍쳐, 디자인, 인터페이스)
• 테스트 조건 또는 테스트 요구사항과 테스트 항목, 명세, 동작과 구조에 분석을 기초로 필요한 테스트 데이터를 정의한다.
• 테스트들(tests)을 설계한다.
• 시스템과 요구사항의 테스트 가능성을 평가한다.
• 테스트 환경을 설정하고, 테스트에 요구되는 기반 구조와 도구를 정의한다.

 

1.4.3 테스트 구현(Implementation)과 실행(execution)

 

테스트 구현과 실행은 테스트 조건들이 테스트 케이스(test case)와 테스트웨어(testware) 그리고 테스트 설정 환경으로 변환되는 액티비티이다.

 

테스트 구현과 실행은 다음의 주요한 작업을 포함한다.

 

• 테스트 케이스의 개발과 우선 순위화, 테스트 데이터의 생성, 테스트 절차(test procedures)의 작성, 그리고 테스트 장치의 준비와 자동화된 테스트 스크립트 작성
• 효과적인 테스트 실행을 위한 테스트 케이스들로 부터의 테스트 슈트(test suite) 작성
• 테스트 환경이 올바르게 설정되었는지의 검증
• 계획된 순서에 따라 수동이나 테스트 실행 도구에 의한 테스트 케이스의 실행
• 테스트 실행의 결과 로깅(logging)과 테스트웨어, 그리고 테스트 도구, 테스트 중인 소프트웨어의 버전과 특성(identities)들을 기록
• 실제 테스트 결과와 예상 테스트 결과의 비교
• 실제 테스트와 예상 테스트 결과 사이의 불일치(discrepancies)를 보고하고, 그 원인을 찾기 위하여  분석한다. (e.g 코드, 특정 테스트 데이터, 테스트 문서안의 결점이나 실행된 테스트 방법 내의 잘못)
• 각각의 불일치에 대하여 취해진 행위의 결과와 같은  테스트 액티비티를 반복한다. 예를 들어, 이전에 실패한(failed) 테스트의 재실행(re-excution)은 잘못을 수정한 것을 확인하기 위한 것이다. (확인 테스트-confirmation test) 정정된 테스트의 실행과/또는 다른 테스트들의 수행은 소프트웨어의 변경되지 않은 부분에는 아직 결점이 나타나지 않았다는 것과 결점을 고친 것이 다른 결점들을 커버 하였다는 것을 확신하기 위해서 진행된다.(회귀테스팅-regression testing)

 

1.4.4 종료 기준(Exit criteria) 평가와 보고(Reporting)

 

종료 기준을 평가하는 것은 테스트의 실행이 정해진 목표에 대한 것인지를 평가하는 액티비티이다. 이것은 각각의 테스트 레벨에 대하여 반드시 수행되어져야 한다.

 

종료 기준을 평가하는 것은 다음의 주요한 작업을 포함한다.

 

• 테스팅 계획에 정의된 종료 기준에 비교하여 테스트 로그들(logs)을 확인한다.
• 더 많은 테스트가 필요한지, 정의된 종료 기준이 변경되어져야 하는지를 평가한다.
• 이해당사자를 위한 테스트 요약 보고서를 작성한다.

 

1.5.5 테스트 종료(Test Closure) 액티비티

 

테스트 종료 액티비티는 경험, 테스트웨어, 실제 사실과 숫자들을 통합하기 위하여 종료된 테스트 액티비티로부터 데이터를 수집한다. 예를 들어, 소프트웨어 시스템이 릴리즈되면, 테스트 프로젝트가 완료되며(또는 취소되며), 목표(milestone)가 성취되었거나 유지보수를 위한 배포가 완료된 것이다.

 

테스트 종료 액티비티는 다음의 주요한 작업을 가진다.

 

• 부가적인 사건의 종료 보고서와 오픈된(opened) 상태로 남아 있는 부분에 대하여 일어나는 변경 기록들, 그리고 시스템의 승인에 대한 문서와 같은 계획된 소프트웨어 구성요소들(deliverables)이 전달되었는가 확인한다.
• 테스트웨어, 테슽 환경 그리고 테스트 기반 구조를 정리하고 최종적으로 승인한다.
• 유지보수 조직에 테스트웨어를 이양한다.
• 다음 프로젝트와 릴리즈 그리고 테스트 성숙도의 향상을 위하여 경험으로 배운  사항(lessons learned)을 분석한다.

 

===========================================================================

* 소프트웨어 업계에서는 일단 제작되어 다른 사람에게 전달되는 소프트웨어 제품 구성요소를 deliverable이라 한다.

 

* 초기 구상 단계부터 대중에게 출시되기까지 소프트웨어 제품을 만드는 데 사용되는 과정을 소프트웨어 수명주기 모델이라고 한며 가장 많이 사용되는 모델은 다음의 4가지 모델이다.

     - 빅뱅 (Big-bang) 모델

     - 코딩- 수정(Code-and-Fix) 모델

     - 폭포(Waterfall) 모델

     - 나선형(Spiral) 모델   

 

 ◆ Test Plan
  ▪  Purpose
      - Test의 개요를 정의한다.
      - 테스트 전략 및 테스트 수행의 개요를 정의한다.
  ▪ Goal of the Test
      - Test의 최종 목표를 정의한다.
  ▪ Scope of the Test
      - 테스트 대상 기능과 비 대상 기능을 정의한다. 해당 기능들은 업무요구 사항 및 기술 요구사항에 정의되어 있어야 한다.

 

 ◆ Test Estimation
  ▪ 예측 방법
      - 과거 프로젝트나 유사 프로젝트의 매트릭을 근거로 테스트 업무량(effort) 예측
      - 전문가나 테스크의 주체에 의한 예측
  ▪ 테스팅 업무량에 영향을 주는 요소들
      - 제품의 특성 : 테스트 베이스의 품질, 제품 사이즈, 문제 도메인의 복잡성, 신뢰성 및 보안성 요구수준, 문서화 요구수준
      - 개발 프로세스 특성 : 조직의 안정성, 사용한 틀, 테스트 프로세스, 관여자들의 스킬 수준, 시간 압박 정도
      - 테스팅 결과물 : 결함 수와 요구되는 재작업량
 
◆ Test approaches
  ▪ 분석적 접근법 (Analytical approachs) : Risk-based testing
  ▪ 모델 기반 접근법(Model-based approaches) : Stochastic testing(reliability growth model, operational profiles)
  ▪ Methodical approaches : Failure based(error guessing, fault-attacks), check-list based, quality characteristic based
  ▪ Process - or standard-compliant approaches
  ▪ Dynamic and heuristic approaches
  ▪ Consultative approaches (by expert advice)
  ▪ Regression-averse approaches (reuse of existing test materials and automation)

 

◆ Test Strategies and factors
  ▪ 테스트 전략은 무엇을 어떻게 테스트하고 어느 정도의 깊이/커버리지로 할 것인지를 결정하는 것으로 리스크 기반 테스트 전략이 대표적이다.
  ▪ 테스트 전략의 결정 요소로는 Product technology, product criticality, product complexity, component selection 등이 있다.

 

 ◆ Risk - 시간과 자원의 한계를 고려
    ▪ Defect -> Failure -> Risk   (*Error - relate to human)
    ▪ Defect : Failure 원인 (a specific cause of failure) (Related to product)
    ▪ Failure : 의도된 기능을 수행하지 못한것 (relate to events)
    ▪ Risk : failure 때문에 주어진 기간에 발생하는 비용
               Risk = failure 가능성 * Damage
               Chance of Failure = frequency of use * chance of fault

 

 ◆ Exhaustive 테스팅 전략
   ▪ 모든 가능한 경우를 테스팅
   ▪ 생명 관련 소프트웨어 -> Exhaustive 테스팅 & 안전분석 필요
   ▪ 안전 분석을 위한 Safety manager와 엔지니어가 있어야 함

 

 ◆ Test Environment
   ▪ 테스트가 수행될 물리적 환경, H/W 환경을 정의한다.
   ▪ 테스트가 수행될 S/W 환경을 정의한다.
 

소프트웨어 수명 주기 모델 (참고)

 

빅뱅 모델 (Big-Bang Model)

우주의 생성을 설명하는 이론 중 하나가 빅뱅이론이다. 수 십억년전 우주는 무한한 에너지로 인한 한 번의 거대한 폭팔로 인해 생성되었다는 것이 이 이론이다. 소프트웨어 개발에서의 빅뱅 모델도 같은 이론을 따른다. 많은 양의 물질(사람과 자본)이 한데 모여 종종 매우 격렬하게 많은 양의 에너지가 소모되고 그 결과 완벽한 소프트웨어 제품이 탄생하거나 혹은 그 반대가 된다.

빅뱅이론의 장점은 간단함이다. 계획, 일정 또는 형식적인 개발 과정이 포함된다면 이 이론의 매력은 반감된다. 모든 노력은 소프트웨어를 개발하고 코드를 작성하는데 사용되어야 한다. 이 방법은 제품의 요구사항이 분명하지 않고 최종 출시 날짜가 변동 가능할 경우에 이상적이다. 고객의 요구사항이 유동적이이어야 한다는 점 역시 중요하다. 마지막 순간까지 어떤 제품이 나올지 모르기 때문이다. 대부분의 빅뱅 모델에서는 형식적인 테스팅이 아예 없거나 거의 이루어지지 않는다. 테스팅 과정이 있는 경우에는 제품이 출시되기전 아주 잠깐 동안만 이루어진다.

 

코딩-수정 모델 (Coding-Fix Model)

 

코드-수정 모델은 프로젝팀이 특별히 다른 모델을 사용하려는 노력을 기울이지 않는 한 대개 기본적으로 안주하게 되는 모델이다. 적어도 이 모델에서는 제품의 요구 사항이 무엇인지에 대한 생각을 필요로 한다는 점에서, 절차상으로는 빅뱅 모델보다 한 단계 위에 위치한다. 이 접근 방법을 사용하는 팀은 대개 그들이 원하는 바에 대한 대략적인 아이디어만 가지고 간단한 설계 작업을 하고 코딩, 테스팅, 버그 수정의 단계를 끊임없이 반복한다.

이 모델의 경우 계획과 문서화하는 단계가 거의 없기 때문에 프로젝트 팀은 즉시 결과를 보여줄 수 있다. 이러한 이유로 코딩-수정 모델은 프로토타입, 데모 등 빠른 시간 내에 제작하고 제작이 끝나면 금방 버리도록 계획된 작은 규모의 프로젝트에 매우 적합하다. 하지만 코딩-수정 모델은 규모가 크고 잘 알려진 많은 소프트웨어 제품에 사용되고 있다. 빅뱅 모델과 같이 코딩-수정 모델에서도 테스팅 작업이 특별히 요구되지 않지만 코딩 작업과 수정 작업 사이에 매우 중요한 역할을 담당한다.

 

폭포수 모델 (Waterfall Model)

 

이 모델에서 중요한 세가지 사실은
  
1. 어떤 제품을 만들 것인가를 명확히 해 두는 것이 매우 중요하다. 개발 및 코딩은 제품에 있어 하나의 단계에 지나지 않음을 명심해야 한다.
2. 단계는 분리되어 있고 겹치는 일이 없다.
3. 이전 단계로 되돌아 갈 수 없다. 한 단계에 발을 들여 놓은 다음에는 해당 단계에 대한 작업을 완전히 마무리 지은 후 다음 단계로 이동해야 한다.

 

나선형 모델 (Spiral Model)

 

나선형 모델의 기본 아이디어는 처음 시작 단계에서는 모든 세부 사항을 정의 할 수 없다는 것에서 출발한다. 중요한 기능을 정의하여 시도해보고 고객의 의견을 수렴한 후 다음 단계로 이동한다. 나선형 모델은 다음의 단계를 반복한다.

 

1. 목표, 대안, 장해 요인 결정
2. 위험 요인 확인 및 분석
3. 대안 평가
4. 현재 단계 개발 및 테스트
5. 다음 단계 계획
6. 다음 단계에 대한 접근 방법 결정

 

참고로 이 모델은 이상향이 아니다.

 

========================================================================================

 

◆ Iterative and Incremental Developement & Approach

 

▪ 점진적으로 효과적인 결과물(해결책)을 산출하기 위해 일련의 활동(Requirement -> Analysis -> Design -> Implmentation -> System Test)을 반복적으로 적용하는 개발 스타일
▪  Interative (반복적인) : 핵심적인 개발 활동을 "리스크(우선순위)"에 따라 반복적/발전적으로 적용하여 결과물/해결책 도출
▪  Incremental (점차적으로 증가하는) : 반복 사이클을 통해 개발이 진행됨에 따라 "문제"에 대한 이해를 높여, 해결능력을 향상시킨다.

 

◆ Waterfall VS  Iterative

 

▪ Waterfall은 결과물로 수행전까지 문서만 존재하지만 Iterative는 각 Iteration 별 실제 개발

  결과물이 존재한다.
▪ Waterfall은 Risk를 프로젝트 중간이후의 코딩 단계까지 가지고 가지만  Iterative는 Risk를 개발 앞단에서 처리
▪ Waterfall은 개발 프로젝트 예측이 어렵지만 Iterative는 개발 프로젝트 예측이 용이하다.

 

1.5 The psychology of testing

테스팅하고 검토하는 동안의 사고방식과 분석하고 개발하는 동안의 사고방식은 다르다. 올바른 사고를 가진 개발자들이 자신의 코드를 스스로 테스트 할 수 있지만, 각자 맡은 일에 집중할 수 있도록 도와주고 훈련된 전문 테스팅 인력들에 의한 독립적인 관점을 얻을 수 있는 혜택을 더하기 위해서 테스터에게 테스팅 책임을 분리하여 준다. 독자적인 테스팅은 테스팅의 모든 레벨에서 수행될 수 있다.

 

(저자의 편향을 피하는) 독립적인 어떤 단계는 종종 결점이나 실수를 발견하는데 더 효과적이다.  그러나 독립성은 정통함의 대체수단은 아니며 개발자들은 효과적으로 자신의 코드에서 많은 결점을 발견할 수 있다. 다음과 같이 독립성의 몇가지 레벨이 정의될 수 있다 :

 

• 테스트중인 소프트웨어를 작성한 사람(들)에 의하여 설계된 테스트 (낮은 수준의 독립성)
• 다른 사람(들)에 의하여 설계된 테스트 (e.g 개발팀에 의해 설계된 테스트)
• 다른 조직이나 그룹의 사람(들)에 의하여 설계된 테스트(e.g 독립적인 테스팅 팀)
• 다른 조직이나 회사의 사람(들)에 의하여 설계된 테스트(e.g 아웃소싱 혹은 외부의 인증)

 

조직 구성원들은 관리자와 다른 이해당사자들에 의해 설정된 목표에 자신들의 계획(예를들어, 결함 찾기, SW 정상 동작 확인)을 맞추려는 경향이 있다. 따라서 테스팅의 목적을 명확히 하는 것은 중요하다.

테스팅 동안에 실패들을 정의하는 것은 제품이나 저자에 대한 비평으로 인식될 수 있다. 그러므로 테스팅은 비록 제품의 위험 관리에 있어서 매우 건설적이더라도 종종은 파괴적인 액티비티로 보여질 수 있다. 시스템에서 실패를 찾는 것은 호기심, 전문적인 비관론, 비평적인 눈, 세부사항에 관한 관심, 개발자 동료와의 건전한 의사소통, 그리고 기본적인 에러를 추측하는 경험등을 요구한다.

만약, 에러나 결점 혹은 오류들이 건설적인 방법으로 전달된다면, 테스터와 분석가, 설계자와 개발자 사이의 나쁜 감정들을 회피할 수 있다. 이것은 테스팅은 물론 검토(reviewing)에서 적용된다.

 

테스터와 테스트 리더는 결점, 진보, 그리고 위험에 대한 사실적인 정보를 건설적인 방법으로 전달하기 위한 좋은 대인관계의 스킬이 필요하다. 소프트웨어나 문서의 저자들은 결점에 대한 정보를 통하여 그들의 기술을 향상시킬 수 있다. 테스팅 동안의 결점 발견과 수정은 나중에 들어갈 시간과 비용을 절약해 줄 것이다. 그리고 위험을 줄인다.

 

만약 테스터들이 결점에 대한 원하지 않는 소식의 전달자로만 보여진다면, 의사소통에 문제가 일어날 수도 있다. 그렇지만, 다른 사람과 테스터 사이의 의 사소통과 관계를 향상시키는 몇가지 방법이 있다.

 

• 전투보다는 협력으로 시작하라 - 모두의 공통적인 목적은 더 좋은 품질의 시스템인 것을 생각하라
• 제품을 생산한 사람에 대하여 비판하는 것없이 제품에 대한 발견사항을 중립적이고 사실에 중점을 둔 방법으로 전달하다. 예를 들어, 객관적이고 실질적인 사건 보고서와 발견 사항에 대한 검토 보고서를 작성하라.
• 다른 사람이 어떻게 느끼는지와 왜 그들이 그렇게 반응하는가를 이해하려고 노력하라.
• 다른 사람이 당신이 말한 것을 이해했는지를 확인하라 그리고 반대 상황도 마찬가지이다.

 

===========================================================================

테스터의 역할은 동료의 작업을 비판하고 문제점을 찾아낸 다음에 공개하는 일이다. 다음은 테스터가 동료와 잘 지낼수 있는 몇가지 TIP이다.

 

1. 버그를 일찍 발견하라.
  - 테스터의 당연한 의무이긴 하지만, 이 규칙을 지키도록 노력해야 한다. 예정된 제품 출시 몇 달 전에 버그를 찾아내는 것이 출시 일주일 전에 버그를 발견하는 것보다 개발 팀이 받는 타격이 줄어들며, 테스터에게 우호적일 것이다.

 

2. 지나친 의욕은 금물이다.
   - 대단한 버그를 찾아내면 열광하는 것은 당연하다. 하지만 테스터가 프로그래머에게 가서 히죽 히죽 웃으면서 그가 작성한 코드 중에 테스터로서 가장 끔직한 버그를 찾았다고 말하는 것은 원만한 인간 관계를 유지하기 위한 길은 아니다.

 

3. 나쁜 소식만 전해서는 안된다.
  - 테스트 중 버그가 없는 부분이 있다면 모두에게 말하라. 나쁜 소식만을 전하는 사람이 된다면 모두들 대화 자체를 기피할 수 있다.