Exploratory Testing – Chapter 2

Chapter 2. The Case for Manual Testing

The Origin of Software Bugs

버그는 개발자가 설계에 고려하지 않은 것이 나타나 발견된 것이다. 고려된 것이라면 얘기가 달라진다.
it was an operational hazard that the developers didn’t consider in their design. (not a moth)

Preventing and Detecting Bugs

Preventing Bugs

The “Developer Makes the Worst Tester” Problem

개발자는 애플리케이션을 “짓는”(building)하는 관점으로 접근한다. 테스터가 가지고 있는 “어떻게 하면 깰수 있을까?”하는 관점을 대치할 수 있는 것은 없다. 개발자의 how can I build this의 관점을 잘 보완해준다.

Developers have blind spots because they approach development from a perspective of building the application.
there is no replacement for the tester attitude of how can I break thisto complement the developer attitude of how can I build this.

The “Software at Rest” Problem

at Rest상의 소프트웨어서는 실제적인 버그를 발견할 수 없다. 실제 운영환경에서 수행될 때 까지는 많은 버그는 발견되지 않는다. 개발자가 수행하는 테스트의 대상은 “software at Rest”이다.

Unfortunately, many bugs don’t surface until the software is running in a real operational environment.

The “No Data” Problem
최대한 많은 실 사용자 데이터와 실 환경과 유사한 환경에서 소프트웨어를 실행하고자 하는 다른 시각이 필요하다.이는 테스터가 갖고 있는 것이다.

we need a second set of eyes, running the software in an environment similar to real usage and using data that is as rich as real user data.

Detecting Bugs

테스터는 자동화 테스팅, 매뉴얼 테스팅의 두가지의 동적 분석 활동을 한다. 자동화 테스팅의 아킬레스 건은 oracle problem이라 불리는 것이다. oracle problem은 테스트 케이스가 수행될 때, 소프트웨어가 예상했던 대로 작동햇는지를 어떻게 알 수있는가에 대한 문제이다.

Testers generally use two forms of dynamic analysis: automated testing (writing test code to test an application) and manual testing (using shipping user interfaces to apply inputs manually).
there is one Achilles heel of automated testing that no one has ever solved: the oracle problem.
The oracle problem is a nice name for one of the biggest challenges in testing: How do we know that the software did what it was supposed to do when we ran a given test case?

Manual Testing

인간 테스터는 뇌와 손가락, 재치를 사용하여 소프트웨어가 성공하거나 실패하는 시나리오를 생성한다. 지금까지 매뉴얼 테스트는 잘 수행되지 못하였다. 너무 느리고 너무 임의적이고 반복할 수 없고, 재현할 수 없고 변환할수도 없는.. 그래서 매뉴얼 테스트는 좋지 못한 평판을 가지게 되었다.

A human tester uses her brain, her fingers, and her wit to create the scenarios that will cause software either to fail or to fulfill its mission.
historically the industry has not been good at manual testing. It’s too slow, too ad hoc, not repeatable, not reproducible, not transferable, and there isn’t enough good advice out there for testers to get good at it. This has created a poor reputation for manual testing as the ugly stepchild of development.

Scripted Manual Testing

we are only interested in the flexible type of scripted testing.

Exploratory Testing

전체적으로 스크립트가 제거되었을 때에 이를 exploratory testing이라 부른다. Tester는 문서화된 것 없이 exploratory 방법을 따른다. 테스트 결과, 케이스 등 문서는 테스트가 수행되면서 만들어진다. 매뉴얼 테스트라고 해서 도구를 전혀 사용하지 않는 것이 아니다. 기술이 좋은 가구를 만드는 사람도 좋은 도구를 많이 사용하는 것과 같다. 디버그 빌드, 디버거, proxy, 기타 분석 도구를 매뉴얼 테스팅에 실제적으로 더 사용하게 된다.

문서가 없이 어떻게 테스터가 커버리지르 달성했는지를 알 수있는가? 이는 가이드를 가지고 진행하는지에 달려있다. 좋은 가이드(지도) 없이 exploratory 테스팅을 하는 것은 도시의 유명한 곳을 찾기 위해 시내 전체를 휘젓고 다니는 것과 같다. 이는 탐험(탐색)을 좀더 methodical 할 수 있게 한다.

exploratory테스터가  decision-making을 하기 위해 도움을 주는 두가지 종류의 가이드가 있다.1) exploratory testing in the small 2) exploratory testing in the large 이다.

When the scripts are removed entirely (or as we shall see in later chapters, their rigidness relaxed), the process is calledexploratory testing.

Testers using exploratory methods are also not without a documentation trail. Test results, test cases, and test documentation are generated as tests are being performed instead of being documented ahead of time in a test plan. .. ust because it’s manual testing doesn’t mean we can’t employ automation tools as aids to the process. Indeed, even those who “handcraft” furniture do so with the assistance of power tools. Handcrafting test cases should be no different. Manual testers who use debug builds, debuggers, proxies, and other types of analysis tools are still doing manual testing; they are just being practical about it.

Without documentation, how do testers ensure they are getting good coverage? This is where guidance comes into play. Exploratory testing without good guidance is like wandering around a city looking for cool tourist attractions. It helps to have a guide and to understand something about your destination (in our case, software) that can help your exploration to be more methodical.

There are two types of guidance for exploratory testers to help in the decision-making process:exploratory testing in the small, which aids in local decision making while running tests; andexploratory testing in the large, which helps testers design overall test plans and strategies.

Exploratory Testing in the Small

이는 하나의 화면, 기능에 대한 exploratory 테스팅에 사용되는 많은 input 등을 결정할 때 도움을 주는 것이다.

Testers must choose which inputs to apply, what pages or screens to visit, which menu items to select, and the exact values to type into each input field they see. There are literally hundreds of such decisions to make with every test case we run.Exploratory testing can help a tester make these decisions. And when a tester uses exploratory testing strategy to answer these sorts of questions, I call this exploratory testing in the smallbecause the scope of the decision is small.

Exploratory Testing in the Large
하나의 화면, 기능이 아니라 소프트웨어 전체 범위에 해당하는 decision을 결정할때 도움을 준다.

I call this exploratory testing in the large because the scope of the decisions to be made
encompasses the software as a whole instead of a single screen or dialog. The decisions made should guide how an application is explored more than how a specific feature is tested.

Combining Exploration and Scripting
스크립트 기반의 테스팅과 exploratory 테스팅이 서로 대치하는 개념은 아니다. 이 둘을 결합하는 최고의 방법은 formal 스크립트로 시작하여 exploratory 기법으로 다양한 variation을 넣는 것이다.

The best way that I have found to combine the two techniques is to start with formal scripts and use exploratory techniques to inject variation into them.


논문 정리 – How to Automate Testing, The Big Picture

How to Automate Testing, The Big Picture




0. 문서 정보

이 문서는 “How to Automate testing, the big picture”  논문을 정리한 것이다. 

1. Introduction 

자동화의 5 단계가 있다. 
  • Automation baseline 설정
  • Automation goal 설정
  • Automation 구현
  • Cultural changes 다루기 (조직 문화 내에 practice로 정착 시키기)
  • 새로운 Goal 설정 및 개선 


2. Automation Baseline 설정

세 가지 영역에서 Automation baseline을 설정한다. 
  • Culture 
  • Processes
  • Tools 


2.1  Company Culture baseline 

Culture(문화)에 대한 부분은 Personal Experience Level (Experience)과 Adaptability Change(Flexibility / 변화 순응도)로 측정될 수 있다. 

Level Experience
None Naive Engineers
Low Undisciplined Engineers
Medium Professional Engineers
High Senior Engineer
CE System Architects


Level Flexibility
None Totally Inflexible – 강제적으로 하지 않으면 변화를 수용하지 않음
Low Rigid – 변화에 대한 강한 저항이 있음
Medium Careful/Stoic – 변화에 대해 다소 주저하거나, 신중함
High Open – 변화를 받아들고, 이에 대한 변화에 대한 의지가 있음
CE Aggressive – 변화가 필요한 부분을 주도적으로 찾음



2.2 Test Process Baseline 

테스팅과 관련된 많은 프로세스가 존재하며, 이들 프로세스가 해당 조직 전체에 얼마나 내재되어있는지를 파악한다. 


  • Plan and Implement Process
    • 스케줄되어 진행되는 (자동화) 테스팅이 없다.
    • 계획없이 스케줄된 테스팅 수행 – Playing / 확인(experimenting)  / ad-hoc 테스팅 
    • 계획되고, 스케줄된 테스팅
    • 계획된 / 스케줄된 / 측정되는 테스팅
    • Repeatable 계획된 / 스케줄된 / 측정되는 테스팅
    • 개발 프로세스에 통합된 repeatable 테스트 프로세스 
  • Test Development Process
    • Ad hoc (자동화) 테스트 개발 
    • Capture Usage : 단지 테스트 스크립트 작성 수준
    • Planned Usage : capture/replay 사용 / 어느정도 단순 프로그래밍 수준 테스트 작성
    • Optimized Usage : capture/replay 더 잘(?) 사용 / 소프트웨어 제품 수준의 테스트 작성
    • Advanced Usage : 다양한 테스트 작성을 위해 모든 사용 가능한 도구를 활용함.  
  • Test Generation Process
    • 없음
    • Random Data Generation 
    • Selective Data Generation
      • 경계값 분석 정도 수준의 테스트 생성
    • Control / State Generation
      • 다양한 상태간의 전이에 대한 테스트 생성
    • Specification based Generation
      • 명세 기반의 테스트 생성
  • Test Running Process 
    • 수동 수행 
    • Individual Test Automation 기법 
      • 각기 테스트에 대한 개별적인 수행
    • Suite Automation 기법 
      • 스위트로 테스트 수행
    • System Automation 기법
    • CASE 도구와 통합하여 수행됨 
  • Capturing Metrics
    • 없음
    • Ad Hoc : 수동 메트릭 수집 (종이 / 연필~ ㅋ)
    • Easy / Static Electronic Measurement 기법 
    • Dynamic Measurements 기법
    • Advanced 기법
  • Defect Tracking
    • 없음
    • Ad hoc : 수동 기록 / 결함 보고 포맷이 정의되지 않음
    • Formatted Defect Report : ad hoc과 비슷하나, 정의된 포맷으로 defect 기록
    • Electronic Submission : 온라인 도구를 사용여 결함 보고 수행 / DB가 사용됨 
    • Query based search and database storage technique
    • 소프트웨어 개발 프로세스의 정보 시스템과 통합됨


위에 대한 자세한 레벨별 설명은  “How to Automate testing, the big picture”   의 2.2절을 참고한다. 

2.3 Tool baseline 

다양한 영역에 tool이 사용되며 그 영역별로 수준을 정의한다. 

  • Planning
    • 없음
    • 종이/연필, 온라인 파일도 가능
    • 캘린더 관리 도구
    • 프로젝트 관리 도구
    • CASE
Lower Test Environment Tools (테스트 작성 / 수행 부분을 포함)
  • Test Development 
    • 수동
    • 스크립트
    • Capture / replay
    • Intelligently synchronized capture / replay
    • Load replication
  • Test Generation
    • 없음 
    • Random Data Generators
    • Selective Data Generators
    • Control / State Generators
    • Specification Based Generators
  • Environment Simulators
    • 없음
    • 수동
    • Error Injection
    • H/W and S/W Simulators
      • H/W Simulator… ?
      • S/W Simulator 는 코드의 특정 부분을 실행할 수있는 도구를 포함한다. 
    • Research Simulators

Upper Test Environment Tools (수행 중인 테스트 관리 부분을 포함)

  • Test Running
    • 수동
    • Individual Test Automation Tools
    • Test Suite Automation Tools 
    • Test System / Lab Automation Tools
    • CASE 도구에 통합된 Automation Test Tool Set
Metric Tools
  • Static Measurement
    • 없음
    • Lint 와 같은 Tool
    • Data flow diagrammers, McCabe 등
    • Symbolic Execution
    • Research Metric Tools
  • Dynamic Measurement
    • 없음
    • 관찰 (Observation)
    • 유틸리티 도구 – 디스크/메모리 사용량 측정 
    • 코드 커버리지 및 성능 측정 도구
    • Research Metric Tools
  • Defect Tracking
    • 없음
    • 포스트 잇
    • 종이 보고양식
    • e-mail / Simple Database
    • Database system / 4GL system
    • 소프트웨어 개발 프로세스내 information tracking system에 통합된 Defect tracking system

2.4 Automation Baseline 

회사의 automation baseline은 다음의 합이다. 

  • Company’s Personnel / Culture Baseline
  • Test Process Baseline
  • Tool Baseline

다음의 표로 정리 될 수 있다. 



3. Set Automation Goals

Goal을 정할 때에는 각 파트별로 대략 같은 수준을 만드는 것이 좋다. 


4. Implement Automation

테스트 프로세스 전체가 아니라 테스트 프로세스 상의 Automation에 대한 부분을 정의하기 위한 부분이 이 문서의 촛점이다. 


4.2 Test Running Automation Levels

다음의 각 레벨에 따른 테스트 자동화의 특성에 대한 고려가 필요하다. 
  • Individual 
  • Suite
  • System

4.2.1 Going from No Testing to Manual Testing 

보통 첫 번째 테스트 시스템은 manual이다. 테스터와 개발자는 분리되어 있지않고 한 명이 진행한다. 하지만 Myer는 “자신의 프로그램을 스스로 테스트하는 것은 불가능하다”라고 [Myers76] 말한다. 

보통 다음과 같은 방향으로 흘러간다. 
  1. 테스트 수행이 생략된다.  
  2. 별개의 테스트가 각기 별도의 시간에 수행된다. 
  3. Trained monkey가 사용된다. 
  4. 테스트 수행이 자동화되기 시작한다. 

테스트 자동화는 long-term solution이다. 따라서 long -term 뷰를 가지고 그 효과를 기대해야한다. 

4.2.2 Individual Automation 

  • 자동화의 첫 번째 단계이다. 
  • 소수의 사람들이 그들 스스로의 동기부여로 컨셉 증명을 하기 위해 시작하는 단계라 할 수 있다. 

4.2.2.1 Automating Input and Execution

  • 입력과 실행 부분에 대한 자동화이다. 
  • 보통 이부분에 대한 자동화는 달성하기 어렵지 않다. 

4.2.2.2 Automating Analysis

  • 결과에 대한 분석(pass or fail)을 자동적으로 판단하는 것을 말한다. 

4.2.2.3 Automating Reporting

  • 테스트 실행 결과(pass/ fail / .. )에 대한 reporting
  • 성능, 커버리지 등에 대한 reporting 
  • 나아가, 발견된 defect에 대한 defect system에 자동 reporting까지 

4.2.2.4 Automation Setup

  • 자동화 테스트 수행이 기대되는 결과를 나타낼 수 있게 해주는 환경에 대한 setup
  • setup의 대부분의 비용은 환경을 만드는 데에 있다. checking에 있지 않다. 
    • setup 비용은 execution 보다도 더 정확히 justify하기 어렵다. 
    • 몇 번의 수행만 한다면 manual setup이 비용적으로 더 효과적이겠지만, long-term 으로 본다면 setup에 대한 automation이 더 효과적일 것이다. 
  • SETUP을 통해 unknown state에서 known state로 옮길 수 있다. 
    • unknown state에서는 모든 케이스를 커버하기 어렵고, 해당 문제를 isolate 할 수도 없다. 

4.2.2.5 Automation Cleanup

  • cleanup 부분은 automation에서 자주 간과되는 부분이다. 
  • 실행/분석 후에는 관련 리소스를 모두 초기화 시켜두는 것이 좋다.
  • cleanup 역시 known state로 만드는 것에 주요 목적이 있다. cleanup을 통해 known state로 만들어준다면 setup을 진행하는 데에 많은 도움을 줄 것이다. 

4.2.2.6 Automation Help

  • Help는 테스트 셋에 대한 문서라 할 수 있다. 
    • 어떤 테스트가 포함되어 있는지
    • 사용되고 요구되는 리소스는 어떤 것인지  
    • 어떻게 테스트를 실행하고 결과를 해석해야하는지

4.2.2.7 Going from manual running to individual automation (수동에서 개별 자동화로)

  • SEARCH모델을 사용하여 자동화 모델을 구현한다. 
    • Setup
    • Execution
    • Analysis
    • Reporting
    • Cleanup
    • Help
  • 단지execution이 아니라 다른 항목에 대한 자동화까지를 고려해야한다. 
  • (Joseph’s comments) Fitnesse 를 통해  해결할 수 있는 부분 -> SEARCH 중에 SEARC 에 대해서는 도움 받을 수 있으며, H에 대해서도 내wiki내 문서화를 잘 해 둔다면 가능하다. 하지만 이는 자동화는 아니다..수동.. HELP을 어떻게 자동화??  결국 FitNesse가 많은 도움 / 지원이 될 수 있다. 

4.2.3 Suite Automation 

  • Individual automation으로 생성된 테스트 셋을 구조화하여 자동화한다. 

4.2.3.1 Setup, Execution and Cleanup 

  • 시작은 test set을 순차적으로 모아두는 것으로 시작한다. 하지만 병렬적으로 테스트 셋이 수행될 수 있는 상황도 고려해야한다. 
  • Suite Automation에 앞서 individual automation에서 setup, cleanup이 잘 정의 되어 있어야 무리가 없다. 
  • 선택적으로 test를 수행 할 수 있어야 한다. 

4.2.3.2 Reporting 

  • 어느정도는 표준화된 reporting 포맷이 필요하다.
  • individual automation testing 에 대한 reporting 뿐 아니라, Suite에 대한 reporting도 있어야 한다. 

4.2.3.3 Shared Functionality 

  • 표준화 대상에 있어, 중요한 것 중 하나가 “shared function”이다. 
    • 특히, Setup에 많이 사용될 수 있다. 
  • Suite automation에서는 다음을 제공해야한다. 
    • configuration 조정을 통해 해당 suite의 환경 설정이 가능해야 한다. 
    • Cleanup에 필요한 function을 제공해야 한다. 
    • Execution / Analysis을 위한 function도 있어야 한다. 


4.2.3.4 Help

  • Suite의 Help는 단지 individual test set의 Help를 모아둔 것이 되어서는 안된다. 
    • 사용된 함수
    • 필요로 되는 리소스
    • 선택적으로 테스트를 선택하여 수행하는 데 필요한 정보가 있어야 한다.

4.2.4 System / Library Automation 

  • 여러 개의 Test suite은 Test Library로 모을 수 있다. 

4.2.4.1 The SEARCH for System Automation 

  • Setup
    • 환경에 대한 configuration 설정 뿐 아니라, 가용한 머신에 대해 필요한 환경 설정을 생성할 수 있어야 한다. 
  • Execution
    • 가장 효율적인 리소스 효율을 갖도록 어떤 순서로 test suite 또는 test set이 수행되어야 하는지 스케줄 관리도 필요하다. 
  • Analysis 
    • 어떤 머신에서 , 어떤 네트워크 환경에서,  어떤 버전의 소프트웨어에서 버그가 생성되었는지에 대한 것도 분석할 수 있어야 한다. 
  • Reporting 
    • 병렬적으로 수행되는 테스트의 결과를 수집한다. 
  • Cleanup
    • 다양한 System level setup function을 다루는 것이 필요하다. 
  • Help
    • test library 레벨로 추상된 도움말이 필요하다. 


4.2.5 Integrating Test Running Automation into Software Development Automation 

  • 소프트웨어 개발 과정 상에 테스트 자동화가 통합/ 녹아져야한다. 
    • (Joseph’s comments) 현재의 경우, CI를 통한 테스트 자동화 통합이 될 듯 / 특정 단계의 build에서는 각기 맞는 자동화된 테스트 셋이 수행될 수 있도록. 



4.2.6 Automation Level Summary (자동화 단계 요약)

  • Automatic Test System의 그림을 그리면 다음과 같다. 


  • Test Running Maturity Model 
    • Individual (개별)
      • Completely Manual Running (완전 수동 수행)
      • Automated Excution, (everything else manual) (테스트 수행만 자동화 (그외는 모두 수동))
      • Partially Automated (부분 자동화) 
        • Setup
          • Environment Checked 
          • Environment Configured 
        • Execution 
          • (대게 테스트 입력에 대한 자동화가 되어 있음)
        • Analysis & Evaluation 
          • 캡쳐 및 output에 대한 비교
        • Reporting
          • Status – pass / fail / .. 
          • Metric – 성능 / 커버리지 ..
          • Defects 
        • Cleanup
        • Help
      • Full automated individual test set running (개별 테스트 셋 수행에 대한 완전 자동화)
    • Suite (스위트)
      • Completely manual test suite running 
      • Partially automated test suite running
      • Full SEARCH automated test suite
    • System (시스템)
      • Completely manual system testing running
      • Partially manual system testing running 
      • Full SEARCH automated test running system
      • Integrated testing and software development systems

4.2.6.1 Individual automation 

  • Execution 전에 Setup 부분에 대한 자동화가 필요하다. 
  • Analysis 자동화를 위해 출력에 대한 기록, 비교, 평가가 필요하다. 
  • Reporting은 Analysis의 결과와 관련 metric을 공유하기 위해 반드시 있어야 한다. 
  • 마지막으로는 Cleanup에 대한 자동화도 필요하다. 
    • Cleanup시에는 추후 defect isolation에 대한 분석 정보 등은 남겨두어야 한다.

4.2.6.2 Suite automation

  • SEARCH 모델이 확장된다. 
  • 테스트 케이스 셋을 분류하기 위한 Test Indexing도 필요하다. 

4.2.6.3 System Automation 

  • 관련된 여러 Test suite이 Test Library로 통합된다.
  • SEARCH
    • Setup에서는 machine 선택, 특정 테스트 대상 소프트웨어 배포 및 test library를 통한 test suite에 대한 배포를 포함한다.
    • Execution에서는 테스트의 수행 순서 및 스케줄 / 동기화를 맞추는 부분이 사용된다. 최적의 리소스 사용을 위해 어떤 머신에서 테스트를 수행해야하는 지 등도 결정해아함.
    • Analysis에서는 동일한 test suite이 각기 수행되었을 때의 결과를 포함한다. 
    • Report에서는 test suite 수행 결과를 통합한다. 
    • Cleanup은 machine 에 대한 free를 포함한다. 
    • Help는 Test library에 대한 기술 뿐 아니라 machine (software)에 대한 스케줄링에 대한 것도 포함한다. 

4.3 Go One Step at a Time 

  • 다음 단계를 진입하기 진에 전 단계를 완성하고 다음 단계를 진행해야한다. 
    • 예를 들어,Suite automation으로 진행하기 전에 Individual 단계의 SEARCH 모델이 잘 완성되어 있어야 한다. 
    • 소흘히 보게 될 수 있는 Help에 대한 부분도 완성되어 있어야 한다. 
  • 현재 수준을 정하고 목표를 정하라
    • 자동화를 계속하여 늘려나가기 위해, 먼저 지금 수준이 어느정도인지를 파악하고, 장기적으로 무엇을 목표로 하는지를 정한다. 
  • 표준화 할 수 있는 부분을 계속하여 늘려가라
    •  Individual 수준에서 많은 표준화된 항목이 있다면 그만큼 Suite 자동화에 도움을 줄 것이다.

4.3.1 Typical Progressions (진화의 방향)

  • 자동화에 있어 Execution으로 부터 시작한 자동화를 확장하는 2가지 방법이 있다. 

      

  • 첫 번째는 E에서 시작하여, Setup을 추가, Cleanup을 추가한다. 그리고 그 다음으로 Analysis와 Reporting을 추가한다. 
  • 두 번째는 E에서 시작하여, Analysis / Report를 추가한다. 그리고 그 다음으로 Setup과 Cleanup을 추가한다. 
  • (Joseph’s Comments) 현재 우리의 실정으로 볼 때는 두번째 방향이 맞는듯 하다. FitNesses를 활용하면 E / A / R에 대해서는 쉽게 도움을 받는다. S / C / H에 대한 노력이 필요

5. Deal with Cultural Changes in your Company (문화의 변화 다루기)

5.1 Automatic’s Effect of work 

  • 테스트 자동화는 시간을 절약한다. 
  • Tester의 role의 이동을 이룰 수 있다. 
    • 개별 테스트 작성 뿐 아니라 high level system programmer로써의 role로 이동 
    • 자동화 테스트는 사람이 수동으로 할 수 있는 부분을 수행해주므로, Tester는 더 복잡하고 더 창조적인 테스트에 집중한다.
  • 테스트 랩이 있다면 자동화 테스트는 랩 관리자가 해당 랩을 관리하는 용도로도 사용할 수 있다. 

5.2 Personal Interaction 

  • Testing 활동이 educated guessing으로부터 engineering으로 이동할 수 있다.
  • Testing group에 대한 respect가 증가한다. 
  • 소프트웨어 개발 사이클의 초기부터 테스트를 수행할 수 있다. 
  • Tester는 좀더 복잡한 테스팅, 특히 통합/시스템 테스트, 성능 테스트 등에 집중할 수 있다. 

  • 이런 변화는 때로 긴장감, 혼돈, 때로는 분보를 불러일으키기도 한다. 이런 문화적인 변화는 상위 관리자의 의해 다뤄져야한다. 리소스 측면에서 이는 장기적인 안목을 가지고접근해야한다. 적절히 이런 변화에서 생기는 문제가 다뤄지지 않으면, 자동화 구현 중에 큰 고통으로 다가올 것이며 결국 상위 수준의 자동화를 이룰 수 없게 된다. 

6. Set New Goals and Improve Again

  • 자동화 목표를 달성하였다면, 이제 다시 프로세스를 시작할 때이다. 새로운 이슈와 아이디어가 새로운 자동화 프로세스를 수행하며 나타날 것이다. 새로운 프로세스로 들어가기 전에 이를 축하하고, 이에 참여한 모든 사람들을 알리라. 파티를 열고 보너스를 주고, 휴가를 주라
  • 모든 사람이 목표한 자동화 수준을 달성했다고 느낄 때가 다음 수준의 자동화로 넘어갈 때이다. Automation baseline을 설정하고, 새로운 자동화 프로세스로 진입하라.