Nickoo's Blog

1.4 테스트 프로세스의 기초(Fundamental test process)

 

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

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

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

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

 

테스트 계획과 제어
테스트 분석과 설계  - 테스트 베이시스 검토  - 테스트 상황/요구사항/데이터식별  - 테스트 기법 할당  - 테스트 용이성(testability)  - 테스트 환경 구축	- 테스트 목적/목표 설정 및 대상 연구  - 테스트 전략 개발      리스크 분석      테스트 추정  - 조직 셋업  - 테스트 계획 활동  - 테스트 완료 조건  - 테스트 관리 및 제어  - 리포팅      리포팅 계획/설계      진행 리포팅
테스트 구현과 실행  - 테스트 케이스 명세화, 우선순위 선정, 데이터 생성, 절차 작성  - 선행 테스트  - (재) 테스트 실행 (결과 기록)  - 기대 결과와 비교
테스트 실행 완료 및 리포팅
테스트 마감 활동  - 산출물 확인, 테스트웨어 보관  - 프로세스 평가(심사)

 

 

1.4.1 테스트 계획과 제어/통제(Test planning and Control)

 

테스트 계획 수립은 테스팅의 목표와 임무(Mission)를 달성하기 위해 목표와 임무를 면밀히 확인하는 활동이고, 테스팅의 목표 달성을 위해 필요한 활동 내역을 정의하는 것이다.

테스트 계획이란 테스트 임무를 확인하고, 테스트 목적과 어떻게 테스트 할것인지를 정의하는 행위이다.

Test planning is the activity of verifying the mission of testing, defining the objectives of testing and the specification of test activities in order to meet the objectives and mission.

 

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

Test control is the ongoing activity of comparing actual progress against the plan, and reporting the statues, including deviations from the plan. It involves tasking actions necessary to meet the mission and objectives of the project. In order to control testing, it should be monitored throughout the project. Test planning takes into account the feedback from monitoring and control activities.

 

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

 - 테스팅의 범위와 위험을 결정하고, 테스팅의 목표를 정한다. 

 - Determining the scope and risks, and identifying the objectives of testing.

 

 - 테스트 방법을 정한다.(기법, 테스트 항목, 적용 범위, 테스팅에 포함되는 팀들간의 정의와 조정, 테스트웨어)
 - Determining the test approach (techniques, test items, coverage, identifying and interfacing the teams involved in testing, testware).

 

 - 요구되는 테스트 자원을 정의한다. (e.g 인력, 테스트 환경, PC등)
 - Determining the required test resources (e.g. people, test environment, PCs).

 

 - 테스트 정책과/또는 테스트 전략을 결정한다.
 - Implementing the test policy and/or the test strategy.

 

 - 테스트 분석과 설계 작업을 계획한다. 
 - Scheduling test analysis and design tasks.

 

 - 테스트 구현과 실행 그리고 평가를 계획한다.
 - Scheduling test implementation, execution and evaluation.

 

 - 종료 기준을 결정한다.

 - Determining the exit criteria.

 

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

 - 결과의 측정과 분석

 - measuring and analyzing result.

 - 프로세스, 테스트 적용범위(test coverage), 그리고 종료 기준(exit criteria)의 모니터링과 문서화

 - monitoring and decumenting progress, test coverage and exit criteria.

 

 - 올바른 동작의 초기화

 - initiation of corrective actions.

 - 의사결정

 - making decisions.

 

 

1.4.2 테스트 분석과 설계(Test analysis and design)

 

테스트 분석과 설계는 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황(Test conditions)과 설계(Design)로 변환하는 활동이다.

Test analysis and design is the activity where general testing objectives are transformed into tangible test conditions and test design.

 

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

 - 테스트 관련 기본사항을 검토한다.(요구사항, 아키텍쳐, 디자인, 인터페이스)
 - Reviewing the test basis (such as requirements, architecture, design, interfaces)

 

 - 테스트 조건 또는 테스트 요구사항과 테스트 항목, 명세, 동작과 구조에 분석을 기초로 필요한 테스트 데이터를 정의한다.
 - Identifying test conditions or test requirements and required test data based on analysis of test items, the specification, behavior and structure.

 

 - 테스트들(tests)을 설계한다.
 - Designing the tests.

 

 - 시스템과 요구사항의 테스트 가능성을 평가한다.

 - Evaluation testability of the requirements and system.

 - 테스트 환경을 설정하고, 테스트에 요구되는 기반 구조와 도구를 정의한다.

 - Designing the test environment set-up and identifying any required infrastructure and tools.

 

 

1.4.3 테스트 구현과 실행(Test implementation and execution)

 

테스트 구현과 실행은 테스트 상황을 테스트 케이스나 테스트웨어로 변환하는 활동이다. 이때에는 테스트 실행에 필요한 테스트 환경이 구축되어 있어야 한다.

Test implementation and execution is the activity where test conditions are transformed into test cases and testware, and the environment is set up.

 

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

 - 테스트 케이스의 개발과 우선 순위화, 테스트 데이터의 생성, 테스트 절차(test procedures)의 작성, 그리고 테스트 장치의

    준비와 자동화된 테스트 스크립트 작성
- Developing and prioritizing test cases, creating test data, writing test procedures and, optionally, preparing test harnesses and writing automated test scripts.

 

 - 효과적인 테스트 실행을 위한 테스트 케이스들로 부터의 테스트 슈트(test suite) 작성
 - Creating test suites from the test cases for efficient test execution.

 

 - 테스트 환경이 올바르게 설정되었는지의 검증
 - Verifying that the setst environment has been set up correctly.

 

 - 계획된 순서에 따라 수동이나 테스트 실행 도구에 의한 테스트 케이스의 실행
 - Executing test cases either manually or by using test execution tools, according to the planned sequence.

 

 - 테스트 실행의 결과 로깅과 테스트웨어, 그리고 테스트 도구, 테스트 중인 소프트웨어의 버전과 특성(identities)들을 기록
 - Logging the outcome of test execution and recording the identities and versions of the software under test, test tools and testware.

 

 - 실제 테스트 결과와 예상 테스트 결과의 비교
 - Comparing actual results with expected results.

 

 - 실제 테스트와 예상 테스트 결과 사이의 불일치(discrepancies)를 보고하고, 그 원인을 찾기 위하여  분석한다.

   (e.g 코드, 특정 테스트 데이터, 테스트 문서안의 결점이나 실행된 테스트 방법 내의 잘못)
 - Reporting discrepancies as incidents and analyzing them in order to establish their cause.

   (e.g a defect in the code, in specified test data, in the test document, or a mistake in the way the test was executed)

 

 - 각각의 불일치에 대하여 취해진 행위의 결과와 같은  테스트 활동을 반복한다. 예를 들어, 이전에 실패한 테스트의 재실행(re-execution)은 잘못을 수정한 것을 확인하기 위한 것이다. (확인 테스트-confirmation test) 정정된 테스트의 실행과/또는 다른 테스트들의 수행은 소프트웨어의 변경되지 않은 부분에는 아직 결점이 나타나지 않았다는 것과 결점을 고친 것이 다른 결점들을 커버 하였다는 것을 확신하기 위해서 진행된다.(회귀테스팅-regression testing)

 

 

1.4.4 테스트 완료 조건과 리포팅(Evaluating exit criteria and reporting)

 

"완료 조건 평가"는 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 실행되었는지를 평가하는 활동이다. 테스트 목표를 달성하였다면 테스트가 완료된다. 그렇지 않다면 추가적인 테스트를 통해 테스트 목표를 달성할 것인지, 아니면 목표를 변경하여(필요시 추가적인 테스트를 실행한 후) 테스트를 완료할 것인지를 결정하여야 한다. 해당 활동은 각 테스트 레벨(Test Level - 컴포넌트, 통합, 시스템, 인수 테스팅)마다 수행되는 것이 원칙이다.

 

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

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

 

 

1.4.5 테스트 마감 활동(Test Closure activities)

 

테스트 마감은 완료된 테스트 활동에서 데이터를 수집하여, 테스트에서 발견된 사실과 수치는 물론 테스팅 경험과 테스트웨어를 종합하고 축적하는 활동이다. 테스팅이 얼마나 체계적으로 수행되었는지 평가하고 향후 테스팅을 개선하기 위해 업계 모범 사례(Best practices)를 모델로 테스트 프로세스를 심사(평가)하는 것 또한 테스트 마감 활동의 중요한 부분이다.

 

테스트 마감 활동은 소프트웨어 시스템이 출시되어 테스트 프로젝트가 완료 되었을 때(또는 취소되었을 때), 계획된 모든 마일스톤이 달성되었을 때, 또는 유지보수 활동 중 추가 개발되거나 업데이트된 부분이 출시 완료되었을 때 발생한다.

Test closure activities collect data from completed test activities to consolidate experience, testware, facts and numbers. From example, when a software system is released, a test project is completed (or cancelled), a milestone has been achieved, or a maintenance release has been completed.

 

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

 - 부가적인 사건의 종료 보고서와 오픈된(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. 다음 단계에 대한 접근 방법 결정

 

이 모델은 이상향이 아니다.

 

 

---

 

Interative and Incremental Developement & Approach

점진적으로 효과적인 결과물(해결책)을 산출하기 위해 일련의 활동(Requirement -> Analysis -> Design -> Implmentation -> System Test)을 반복적으로 적용하는 개발 스타일

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

 

Waterfall VS  Interative

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

 

 

출처 :  2005년 ISTQB 시나버스 ||  http://akiss.egloos.com/2634612