Optimizing the Contribution of Testing to Project Success

조금은 급진적인 주장들이지만, 충분히 귀담아 고민해 볼 필요가 많은 글인 것 같다.

가끔 보면 본인 블로그에 제 포스팅 내용을 그대로 퍼가시는 분들이 계신데, 요즘은 검색 엔진이 잘 되어 있어서 공개되어 있는 글들 잘 찾아 준다. 복사해 가셨으면 혼자서만 보시지 그걸 또 왜 공개하시는지? ^^ 그러지 마시고 원문 링크만 걸어 주시길 부탁 드린다. ^^ 웬만해서는 쥔장은 이 블로그의 글들을 지우지 않는다. 링크는 아주 오랫동안 살아 있을 것을 약속드린다. :)

Optimizing the Contribution of Testing to Project Success
프로젝트의 성공에 테스팅의 기여도를 최적화하기

Niels Malotraux, niels @ malotaux.nl
http://www.malotaux.nl/nrm/English/

translated by TB
reviewed by blackprince (검은왕자)

1. Introduction
1. 소개

We know all the stories about failed and partly failed projects, only about one third of the projects delivering according to their original goal [1].
우리 모두는 부분적으로 또는 완전히 실패한 프로젝트의 이야기들을 알고 있다. 단지 프로젝트들의 약 1/3 가량만 최초의 목표에 맞게 출하된다 [1].

Apparently, despite all the efforts for doing a good job, too many defects are generated by developers, and too many remain undiscovered by testers, causing still too many problems to be experienced by users.
확실히, 훌륭히 업무를 달성하려는 노력에도 불구하고, 너무나 많은 결함이 개발자에 의해 만들어지고, 너무나 많은 잔존결함이 테스터에 의해 발견되지 않은 채로 남아, 여전히 너무나 많은 문제들이 유저에게 경험되는 원인이 되고 있다.
It seems that people are taking this state of affairs for granted, accepting it as a nature of software development.
사람들이 이러한 상황을 용인하고, 소프트웨어 개발의 자연스러운 현상으로 받아들이고 있는 것처럼 보인다.
A solution is mostly sought in technical means like process descriptions, metrics and tools. If this really would have helped, it should have shown by now.
대부분의 해결책이라는 것이 프로세스 작성 또는 메트릭이나 툴 같은 기술적인 방법에서 찾아지고 있다. 이런 것들이 정말로 도움이 되어 왔다면, 이제는 그 진가가 드러났어야 한다.

Oddly enough, there is a lot of knowledge about how to significantly reduce the generation and proliferation of defects and deliver the right solution quicker.
이상하게도, 어떻게 하면 확실하게 결함의 생성과 확산을 줄이고, 더 빠르게 올바른 제품을 출하할 수 있는지에 대한 많은 방법들이 존재한다.
Still, this knowledge is ignored in the practice of many software development organizations.
하지만, 여전히 이러한 방법들은 많은 소프트웨어 개발 조직의 작업에서 무시되고 있다.
In papers and in actual projects I’ve observed that the time spent on testing and repairing (some people call this debugging) is quoted as being 30 to 80% of the total project time.
문헌이나 실제 프로젝트에서, 나는 테스팅과 수정 (어떤 사람은 디버깅이라 부른다)이 전체 프로젝트 기간의 30%에서 80%까지 차지하는 것을 목격해왔다.
That’s a large budget and provides excellent room for a lot of savings.
이 부분은 예산의 큰 부분을 차지하고, 절약할 수 있는 여지가 큰 부분이다.

In 2004, I published a booklet: How Quality is Assured by Evolutionary Methods [2], describing practical implementation details of how to organize projects using this knowledge, making the project a success.
2004년에 나는 "진화적인 방법으로 어떻게 품질을 확보할 수 있나? [2]"라는 소책자를 출간했다. 이 책에서는 이러한 방법들을 사용해서 어떻게 하면 프로젝트를 조직화할 수 있는지, 어떻게 하면 프로젝트를 성공시킬 수 있는지에 대한 실용적인 지침을 기술했다.
In an earlier booklet: Evolutionary Project Management Methods [3], I described issues to be solved with these methods and my first practical experiences with the approach.
최근의 소책자인 "진화적인 프로젝트 관리의 방법 [3]"에서, 이러한 방법들을 사용할 때 해결되어야 하는 이슈들과, 이 접근법을 사용한 첫번째 실제 경험도 기술했다.
Tom Gilb published already in 1988 about these methods [4].
톰 길브는 이미 1988년에 이러한 방법에 대해 발표했었다 [4].

In this booklet we’ll extend the Evo methods to the testing process, in order to optimize the contribution of testing to project success.
이 소책자에서 우리는 프로젝트 성공에 테스팅의 기여도를 최적화하기 위해 이 Evo 방법론을 테스팅 프로세스로 확장할 것이다.

Important ingredients for success are: a change in attitude, taking the Goal seriously, which includes working towards defect-free results, focusing on prevention rather than repair, and constantly learning how to do things better.
성공을 위한 재료들은 변화의 마음가짐, 결함없는 결과물을 위해 작업하는 것을 포함해 목표를 진지하게 추구하기, 수정 보다는 예방에 집중하기, 어떻게 하면 더 나아질 수 있는지 항상 배우는 것이다.

2. The Goal
2. 목표

Let’s define as the main goal of our software development efforts:
우리의 소프트웨어 개발 노력의 주요 목표를 정의해 보자.

Providing the customer with what he needs, at the time he needs it,
to be satisfied, and to be more successful than he was without it …
고객이 원하는 것을 적시에, 만족하도록, 그것이 없었을 때보다 그의 업무에 도움이 되도록...

If the customer is not satisfied, he may not want to pay for our efforts. If he is not successful, he cannot pay. If he is not more successful than he already was, why should he invest in our work anyway? Of course we have to add that what we do in a project is:
그 고객이 만족하지 못하는 경우, 그는 우리 노력에 대한 대가를 지불하지 않을 것이다. 그가 성공하지 못한다면, 그는 돈을 지불할 수 없을 것이다. 그가 이전에 이룬 성공 보다도 더 성공하지 못한다면, 이유가 어찌되었든 그가 우리의 작업 결과에 투자할 이유가 없다! 물론 우리도 한 프로젝트에서 해야만 하는 것보다 더 많은 걸 해야 한다.

… constrained by what the customer can afford and what we mutually
beneficially and satisfactorily can deliver in a reasonable period of time.
... 고객이 감당할 수 있고, 상호간에 이익이 되며, 적당한 기간 내에 전달되어햐 하는 제약...

Furthermore, let’s define a Defect as:
더 나아가서 결함을 정의해보자.

The cause of a problem experienced by the stakeholders of the system.
시스템의 이해관계자에 의해 경험되는 문제의 근원.

If there are no defects, we’ll have achieved our goal. If there are defects, we failed.
아무런 결함이 없다면, 우리는 우리의 목표를 달성할 것이다. 결함이 있다면, 우리는 실패한 것이다.

3. The knowledge
3. 방법

Important ingredients for significantly reducing the generation and proliferation of defects and delivering the right solution quicker are:
결함의 생성과 확산을 획기적으로 줄이기 위해 필요한 요소와, 올바른 제품의 출하를  더 빠르게 하기 위해서는:

    * Clear Goal: If we have a clear goal for our project, we can focus on achieving that goal. If management does not set the clear goal, we should set the goal ourselves.
    * 명확한 목표설정: 우리가 우리 프로젝트의 명확한 목표를 설정한다면, 우리는 그 목표를 달성하는데 집중할 수 있다. 만일 경영진이 명확한 목표를 설정해 주지 못한다면, 우리 스스로가 우리의 목표를 설정해야 한다.


    * Prevention attitude: Preventing defects is more effective and efficient than injecting-finding-fixing, although it needs a specific attitude that usually doesn’t come naturally.
    * 문제 예방의 자세: 결함 예방은 결함을 넣고, 찾고, 수정하는 것보다 더 효과적이며 효율적이다. 비록 이러한 자세가 대개는 자연적으로 발생하지 않는 특정한 태도를 요구해도 말이다.


    * Continuous Learning: If we organize projects in very short Plan-Do-Check-Act (PDCA) cycles, constantly selecting only the most important things to work on, we will most quickly learn what the real requirements are and how we can most effectively and efficiently realize these requirements. We spot problems quicker, allowing us more time to do something about them. Actively learning is sped up by expressly applying the Check and Act phases of PDCA.
    * 지속적인 학습: 만일 우리가 프로젝트를 매우 짧은 Plan-Do-Check-Act (PDCA) 싸이클로 조직화할 수 있고, 작업해야 할 가장 중요한 것만 지속적으로 선정한다면, 우리는 무엇이 진정으로 원하는 요구사항인지 빠르게 알 수 있으며, 어떻게 해야 이러한 요구사항을 효과적이고 효율적으로 구현할 수 있을지 알게 된다. 우리는 문제를 빠르게 찾아내어, 그것을 처리하는 더 많은 시간을 벌 수 있다. 능동적인 학습은 PDCA의 Check와 Act 단계를 확실하게 적용함으로써 가속화된다.


    * Evolutionary Project Management (Evo for short) uses this knowledge to the full, combining Project-, Requirements- and Risk-Management into Result Management. The essence of Evo is actively, deliberately, rapidly and frequently going through the PDCA cycle, for the product, the project and the process, constantly reprioritizing the order of what we do based on Return on Investment (ROI), and highest value first. In my experience as project manager and as project coach, I observed that those projects, who seriously apply the Evo approach, are routinely successful on time, or earlier [5].
    * 진화적인 프로젝트 관리 (줄여서 Evo)는 이러한 방법을 전체 프로젝트에, 프로젝트와 결합해서, 요구사항과 결합해서, 위험 관리에서 결과 관리까지 사용한다. Evo의 요체는 능동적이고, 성실하고, 빠르며, 빈번하게 제품, 프로젝트, 프로세스가 PDCA 싸이클에 들어가서, ROI에 기반해서 우선순위를 지속적으로 정렬하고, 가장 가치있는 것을 먼저 수행하는 것이다. 프로젝트 매니저와 프로젝트 코치로서의 내 경험으로 볼 때, 내가 본 프로젝트의 경우, Evo 접근법을 진지하게 적용한 경우, 대개 적시에 또는 더 빨리 성공할 수 있었다 [5].


Evo is not only iterative (using multiple cycles) and incremental (we break the work into small parts), like many similar Agile approaches, but above all Evo is about learning. We proactively anticipate problems before they occur and work to prevent them. We may not be able to prevent all the problems, but if we prevent most of them, we have a lot more time to cope with the few problems that slip through.
Evo는 다른 애자일 접근법과는 반복식이나(다중 싸이클을 사용하는), 점증식 (작업을 작은 단위로 쪼개는)이지만, 특히 배움에 관한 것이 그 요체이다. 우리는 자연스럽게 문제가 발생하기전에 이를 예상하고 미연에 방지하려고 한다. 그렇지만, 우리는 모든 문제들을 예방할 수 없을 것이다. 하지만, 우리가 대부분의 문제를 예방할 수 있다면, 우리는 심각한 결과를 야기할 수 있는 소수의 문제들을 다루는데 많은 시간을 쓸 수 있다.

4. Something is not right
4. 무언가가 올바르지 않다

Satisfying the customer and making him more successful implies that the software we deliver should show no defects. So, all we have to do is delivering a result with no defects. As long as a lot of software is delivered with defects and late (which I consider a defect as well), apparently something is not right.
고객이 만족하고, 성공한다는 것은 우리가 제공한 소프트웨어에 결함이 없는 것을 의미한다. 따라서, 우리가 해야 되는 지상최대의 과제는 결함이 없도록 하는 것이다. 많은 수의 결함이 있는 소프트웨어가 늦게 제공되는 것은 (내가 볼때는 결함도 그러하다) 명백히 무언가 올바르지 않은 것이다.

Customers are also to blame, because they keep paying when the software is not delivered as agreed. If they would refuse to pay, the problem could have been solved long ago. One problem here is that it often is not obvious what was agreed. However, as this is a known problem, there is no excuse if this problem is not solved within the project, well before the end of the project.
또한 고객들은 비난한다. 왜냐하면, 소프트웨어가 합의한 대로 전달되지 않아도 비용을 지불해왔기 때문이다. 그들이 지불을 거절했다면, 그 문제는 이전에 벌써 해결되었을 것이다. 여기서의 한 가지 문제는 무엇이 합의되었는지 종종 명확하지 않다는 것이다. 하지만, 이것이 알려진 문제라서 이 문제가 프로젝트 내에서 해결되지 않는 것은 변명이 되지 못한다. 그 프로젝트가 종료되기 전까지는 해결되어야 한다.

5. The problem with bugs
5. 버그와 관련된 문제

In a conventional software development process, people develop a lot of software with a lot of defects, which some people call bugs, and then enter the debugging phase: testers testing the software and developers repairing the bugs.
일반적인 소프트웨어 개발 프로세스에서, 사람들은 누군가는 버그라 부르는 많은 결함을 가진 다수의 소프트웨어를 개발한다. 그리고나서, 테스터들이 소프트웨어를 테스팅하고, 개발자가 수정하는 디버깅 단계에 진입한다.

Bugs are so important that they are even counted. We keep a database of the number of bugs we found in previous projects to know how many bugs we should expect in the next project.
버그들은 개수가 카운트될 때만 중요해진다. 우리는 다음 프로젝트에서 얼마나 많은 수의 버그들이 예상될 것인지 알기 위해 이전 프로젝트에서 발견된 버그의 수를 데이터베이스화 한다.

Software without bugs is even considered suspect. As long as we put bugs in the center of the testing focus, there will be bugs. Bugs are normal. They are needed. What should we do if there were no bugs any more?
심지어 버그가 없는 소프트웨어는 의혹의 눈길을 받게된다. 우리가 테스팅의 초점을 버그에만 두는 한, 버그가 앞으로도 존재할 것이다. 버그는 정상이다. 그들은 필요하다. 더 이상 버그가 없으려면 어떻게 해야 할까?

This way, we endorse the injection of bugs. But, does this have anything to do with our goal: making sure that the customer will not encounter any problem?
이런식으로 우리는 버그가 집어 넣어지는 것을 용인한다. 고객이 어떠한 문제라도 발견하지 않도록 하는 일이 우리의 목표에 부합하는 일일까?

Personally, I dislike the word bug. To me, it refers to a little creature creeping into the software, causing trouble beyond our control. In reality, however, people make mistakes and thus cause defects. Using the word bug, subconsciously defers responsibility for making the mistake. In order to prevent defects, however, we have to actively take responsibility for our mistakes.
개인적으로, 나는 버그라는 단어를 싫어한다. 나에게 있어서, 이건 소프트웨어에 무언가 기어다니는 작은 생물을 집어 넣어, 우리의 제어범위를 벗어나는 문제를 야기시키는 것이다. 하지만, 실제로는 사람들이 실수를 하고, 그게 결함을 유발시킨다. 버그라는 단어를 사용하면, 실수를 만든 책임을 무의식적으로 미루게 된다. 하지만, 결함을 방지하려면, 우리는 능동적으로 우리의 실수에 대해 책임을 져야 한다.

6. Defects found are symptoms
6. 결함 발견은 증상을 의미한다

Many defects are symptoms of deeper lying problems. Defect prevention seeks to find and analyze these problems and doing something more fundamental about them.
많은 결함들은 이면에 감추어진 더 심각한 문제들의 증상이다. 결함 방지는 이러한 문제들을 찾고 분석하여, 그것에 대해 좀더 근원적인 무엇인가를 행하는 일이다.

Simply repairing the apparent defects has several drawbacks:
단순히 외적으로 보이는 결함들을 수정하는 것은 몇가지 문제를 가지고 있다.

    * Repair is usually done under pressure, so there is a high risk of imperfect repair, with unexpected side effects.
    * 수정은 대개 어떤 압박하에서 이루어진다. 따라서, 예상치 못한 부작용이 발생하는 부정확한 수정을 할 리스크가 대단히 높다.


    * Once a bandage has covered up the defect, we think the problem is solved and we easily forget to address the real cause. That’s a reason why so many defects are still being repeated.
    * 결함에 대해 미봉책을 수행한 다음에, 우리는 그 문제가 해결되었고, 따라서, 근원적인 원인을 처리하는 것을 쉽게 잊는다. 이것이 왜 그 수많은 결함들이 반복적으로 존재하는지에 대한 이유이다.


    * Once we find the underlying real cause, of which the defect is just a symptom, we’ll probably do a more thorough redesign, making the repair of the apparent defect redundant.
    * 그 결함이 증상이어서 근원적인 문제를 찾은 후에, 우리는 좀더 충분히 재디자인을 수행해서, 동일한 결함들의 수정을 수행한다.


As prevention is better than cure, let’s move from fixation-to-fix to attention-to-prevention.
치료보다 예방이 좋듯이, 고착화되어서 수정하지말고 주의를 기울여 예방하는 단계로 나아가보자.

Many mistakes have a repetitive character, because they are a product of certain behavior of people. If we don’t deal with the root causes, we will keep making the same mistakes over and over again. Without feedback, we won’t even know. With quick feedback, we can put the repetition immediately to a halt.
많은 실수들이 반복적인 특성을 보인다. 왜냐하면, 이것들은 사람들의 어떤 행동의 산물이기 때문이다. 만일 우리가 그 근본원인을 처리하지 못한다면, 우리는 시간이 지날 수록 같은 실수를 계속할 것이다. 피드백이 없다면, 우리는 알 수가 없다. 빠른 피드백을 준다면, 우리는 반복을 중단하게 될 것이다.

7. Defects typically overlooked
7. 결함들은 간과된다

We must not only test whether functions are correctly implemented as documented in the requirements, but also, a level higher, whether the requirements adequately solve the needs of the customer according to the goal. Typical defects that may be overlooked are:
우리는 기능이 요구사항에 문서화 된 대로 올바르게 구현되었는지만 테스트 해서는 안된다. 오히려, 더 높은 수준인 목표와 관련된 고객의 니즈가 적절하게 해결되었는지를 테스트해야 한다. 간과되는 전형적인 결함들은 다음과 같다.

    * Functions that won’t be used (superfluous requirements, no Return on Investment)
    * 사용되지 않는 기능들 (ROI 없는 과잉 요구사항)


    * Nice things (added by programmers, usefulness not checked, not required, not paid for)
    * 좋은 것들 (프로그래머에의해 추가된 것, 유용성이 검증되지 않은 것, 불필요한 것, 합의되지 않은 것)


    * Missing quality levels (should have been in the requirements)
          o e.g.: response time, security, maintainability, usability, learnability
    * 품질 수준을 맞추지 못함 (요구사항에 언급되어야 함)
          o 예를 들면, 응답시간, 보안성, 유지보수성, 사용편의성, 배우기 용이한 정도


    * Missing constraints (should have been in the requirements)
    * 빠진 제약사항 (요구사항에 언급되어야 함)


    * Unnecessary constraints (not required)
    * 불필요한 제약사항 (필요치 않음)


Another problem that may negatively affect our goal is that many software projects end at “Hurray, it works!”. If our software is supposed to make the customer more successful, our responsibility goes further: we have to make sure that the increase in success is going to happen.
우리 목표에 부정적인 영향을 끼치는 또 다른 문제는 많은 소프트웨어 프로젝트가 "와 잘 된다!" 하는 시점에 종료하는 것이다. 우리 소프트웨어가 고객의 성공을 도우려면, 우리의 책임이 더 많아져야 한다. 즉, 성공이 지속적으로 증가함을 확실해 해야 한다.

This awareness will stimulate our understanding of quality requirements like “learnability” and “usability”. Without it, these requirements don’t have much meaning for development. It’s a defect if success is not going to happen.
이러한 인식은 "배움 용이성"이나 "사용 편의성" 같은 품질 요구사항에 대한 우리의 이해를 고양시킬 것이다. 그것이 없다면, 이러한 요구사항들은 개발에 있어서 그다지 의미가 없을 것이다. 성공이 일어나지 않는다면 결함이다.

8. Is defect free software possible?
8. 결함 없는 소프트웨어가 가능한가?

Most people think that defect free software is impossible. This is probably caused by lack of understanding about what defect free, or Zero Defects, really means. Think of it as an asymptote (Figure 1). We know that an asymptote never reaches its target. However, if we put the bar at an acceptable level of defects, we’ll asymptotically approach that level. If we put the bar at zero defects, we can asymptotically approach that level.
많은 사람들이 결함이 없는 소프트웨어는 불가능하다고 생각한다. 이것은 결함이 없다는 것이 실제로는 무엇을 의미하는지에 대한 이해가 부족하기 때문이다. 이것을 점선이라고 생각하자 (그림 1). 우리는 점선이 그 목표지점에 영원히 도달할 수 없다고 알고 있다. 하지만, 우리가 그 선을 허용할 수 있는 수준의 결함수로 이동시킨다면, 우리는 점차적으로 그 레벨에 도달할 것이다. 만일 우리가 그 선을 결함 제로선으로 이동시킨다면, 우리는 점진적으로 그 수준에 접근할 수 있다.

Philip Crosby writes [6]:
Conventional wisdom says that error is inevitable. As long as the performance standard requires it, then this self-fulfilling prophecy will come true. Most people will say: People are humans and humans make mistakes. And people do make mistakes, particularly those who do not become upset when they happen. Do people have a built-in defect ratio? Mistakes are caused by two factors: lack of knowledge and lack of attention. Lack of attention is an attitude problem.
필립 크로스비는 [6]:
상식적으로 에러는 피할 수 없다고 말한다. 성과 표준이 그것을 필요로 하는한, 자기 만족적인 예언은 실행될 것이다. 많은 사람들이 말한다. 사람들은 인간이며, 인간들은 실수를 한다. 따라서, 사람들은 실수를 한다. 특히 결함이 발생했을 때 당황하지 않는 사람들이 더욱 그러하다. 사람들에게는 내재된 결함 생산 비율이 있는 걸까? 실수는 두 가지 요인에 의해서 야기된다. 지식과 주의력의 부족이다. 주의력의 부족은 태도의 문제이다.

When Crosby first started to apply Zero Defects as performance standard in 1961, the error rates dropped 40% almost immediately [6]. In my projects I’ve observed similar effects.
크로스비가 1961년에 성과 표준으로서의 제로 결함을 처음으로 적용했을 때, 에러율은 거의 즉시적으로 40%나 떨어졌다. 나의 프로젝트에서도 유사한 현상을 경험했다.

Experience: No defects in the first two weeks of use
경험담: 최초 2주 동안의 사용에서 아무런 결함이 없다.

A QA person of a large banking and insurance company I met in a SPIN metrics working group told me that they got a new manager who told them that from now on she expected that any software delivered to the (internal) users would run defect free for at least the first two weeks of use. He told me this as if it were a good joke. I replied that I thought he finally got a good manager, setting them a clear requirement: “No defects in the first two weeks of use.”
SPIN 메트릭스 워킹 그룹에서 내가 만난 큰 은행, 보험사의 QA 담당은 내게 이제부터 출시되는 소프트웨어가 (내부) 유저들에게 출시 후 최소 2주동안 사용에서 결함이 없도록 하라고 지시한 새로운 매니저가 부임했다고 말했다. 그는 이것이 재밌는 농담인양 내게 말했다. 나는 그에게 결국 요구사항으로 "출시 후 첫 2주동안에 결함이 없음"이라는 명백한 요구사항을 정의하는 새로운 매니저를 만나게 될 것이라고 답했다.

Apparently this was a target they had never contemplated before, nor achieved. Now they could focus on how to achieve defect free software, instead of counting function points and defects. Remember that in bookkeeping being one cent off is already a capital offense, so defect free software should be a normal expectation for a bank. Why wouldn’t it be for any environment?
명백히 이 이야기는 이전에는 한 번도 진지하게 고민되거나, 실행된 적이 없는 주제였다. 이제 그들은 펑션 포인트나 결함수를 카운트하는 대신에 어떻게 하면 결함없는 소프트웨어를 달성할 수 있을지 고민해야 한다. 회계장부에서 하나만 어긋나도 중대한 문제가 되는 것을 기억한다면, 결함없는 소프트웨어는 은행에서 바라는 정상적인 기대여야 한다. 다른 환경에서 이것이 적용되지 못할 이유가 있는가?

Zero Defects is a performance standard, set by management. In Evo projects, even if management does not provide us with this standard, we’ll assume it as a standard for the project,
because we know that it will help us to conclude our project successfully in less time.
제로 결함은 경영진에 의해 설정된 성과 표준이다. Evo 프로젝트에서 경영진이 그러한 표준을 제시하지 않았어도, 우리는 프로젝트의 표준으로 삼았다. 왜냐하면, 이 목표가 짧은 시간 안에 프로젝트를 성공적으로 종료하는데 도움이 될 것이라는 점을 알기 때문이었다.

9. Attitude
9. 태도

As long as we are convinced that defect free software is impossible, we will keep producing defects, failing our goal. As long as we are accepting defects, we are endorsing defects. The more we talk about them, the more normal they seem. It's a self-fulfilling prophecy. It will perpetuate the problem. So, let’s challenge the defect-cult and do something about it.
결함없는 소프트웨어가 불가능하다고 우리가 믿는한, 우리는 결함을 만들것이며, 우리의 목표 달성에 실패할 것이다. 우리가 결함을 허용하는 한, 우리는 결함을 용인할 것이다. 우리가 그것에 대해서 더 많이 이야기 할수록, 그들은 더욱 더 정상으로 보일 것이다. 이것은 자기 만족적인 예언이다. 이것은 영원히 지속되는 문제가 될 것이다. 따라서, 우리는 결함을 허용하는 문화에 도전해서, 무언가를 해야 한다.

From now on, we don’t want to make mistakes any more. We get upset if we make one. Feel the failure. If we don't feel failure, we don’t learn. Then we work to find a way not to make the mistake again. If a task is finished we don’t hope it’s ok, we don’t think it’s ok, no, we’ll be sure that there are no defects and we’ll be genuinely surprised when there proves to be any defect after all. In my experience, this attitude prevents half of the defects in the first place. Because we are humans, we can study how we operate psychologically and use this knowledge to our advantage. If we can prevent half of the defects overnight, then we have a lot of time for investing in more prevention, while still being more productive. This attitude is a crucial element of successful projects.
이제부터 우리는 더 이상의 실수를 하지 않아야 한다. 우리가 그것을 하나라도 만들어내는 경우 놀라며, 실패를 느껴야 한다. 우리가 실패를 느끼지 못한다면, 그것에서 배울 수 없다. 이렇게함으로써 우리는 다시는 실수를 하지 않기 위한 방법을 찾는다.  내 경험으로 볼 때, 이러한 태도는 시도 자체에서 결함을 절반으로 줄인다. 한 작업이 잘 되리라는 기대없이 완료되었다면, 그것이 멀쩡할 것이라고 생각하지는 않지만, 아무런 결함이 없을 것이라고 생각한다. 하지만, 결국 결함이 있는 것으로 증명이 될 때 우리는 정말로 놀라게 된다. 우리는 인간이기 때문에 어떻게 심리적인 요인을 감안하여 작업할 수 있는지, 이러한 지식이 도움이 되는지 알고 있다. 만일 우리가 한밤중에 만들어지는 결함을 절반가량 예방할 수 있다면, 우리는 결함을 예방하는데 더 많은 시간을 투자할 수 있게 되어, 더 생산적이 될 것이다. 이러한 태도는 성공적인 프로젝트의 필수적인 요소이다.

Experience: No more memory leaks
경험담: 더 이상의 메모리 릭은 안된다

My first Evo project was a project where people had been working for months on software for a hand-held terminal. The developers were running in circles, adding functions they couldn’t even test, because the software crashed before they arrived at their newly added function. The project was already late and management was planning to kill the project. We got six weeks to save it.
나의 첫 Evo 프로젝트는 핸드 헬드 터미널용 소프트웨어 회사에서의 몇 달간의 작업했던 프로젝트였다. 개발자는 수차례 바뀌었고, 새로 추가된 기능은 테스트조차 되지 않았다. 왜냐하면, 새로 추가된 기능에 도달하기 전에 소프트웨어가 크래쉬되었기 때문이다. 그 프로젝트는 이미 늦어버렸고, 경영진은 그 프로젝트를 중단시키려 했었다. 우리는 6주만에 그 프로젝트의 생명을 연장시켰다.

The first goal was to get stable software. After all, adding any function if it crashes within a few minutes of operation is of little use: the product cannot be sold. I told the team to take away all functionality except one very basic function and then to make it stable. The planning was to get it stable in two weeks and only then to add more functionality gradually to get a useful product.
첫번째 목표는 안정화된 소프트웨어를 만드는 것이었다. 작동한지 몇 분만에 크래쉬를 일으키는 기능이 사용 빈도가 적었지만 추가되었다. 그 제품은 팔릴 수가 없었다. 나는 그 팀에 아주 기본적인 기능만 제외하고는 모든 기능을 빼도록 요청했고, 이후 그것을 안정화시켰다. 이 계획으로 2주만에 안정화가 되었고, 이후 쓸만한 제품이 되도록 점차적으로 기능을 추가해 나갔다.

I still had other business to finish, so I returned to the project two weeks later. I asked the team “Is it stable?”. The answer was: “We found many memory leaks and solved them. Now it’s much stabler”. And they were already adding new functionality. I said: “Stop adding functionality. I want it stable, not almost stable”. One week later, all memory leaks were solved and stability was achieved. This was a bit of a weird experience for the team: the software didn’t crash any more. Actually, in this system there was not even a need for dynamically allocatable memory and the whole problem could have been avoided. But changing this architectural decision wasn’t a viable option at this stage any more.
나는 여전히 마쳐야할 다른 임무가 있었다. 따라서, 나는 2주후에 그 프로젝트로 되돌아갔다. 나는 그 팀에 "이제 안정화되었나요?"라고 물었다. 대답은 이랬다. "우리는 많은 메모리 릭을 찾았고 그걸 해결했어요. 이제 더 안정적이 되었을거예요". 그리고 그들은 이미 새로운 기능을 추가하고 있었다. 나는 말했다. "기능 추가를 중단하세요. 나는 안정적인 것을 원하지, 안정적인 것에 가까운 것을 원하지 않아요." 1주후에, 모든 메모리 릭이 제거되었고, 안정성도 달성되었다. 이것은 그 팀에 있어서 생소한 경험이었다. 그 소프트웨어는 더 이상의 크래쉬를 내지 않았다. 실제로, 이 시스템에서 동적으로 메모리를 할당할 필요는 없었다. 따라서, 전체적인 문제가 해결되었다. 하지만, 이러한 아키텍쳐적인 결정을 변경하는 일은 이 이후의 (개발) 단계에서는 가능한 선택이 아니었다.

Now that the system was stable, they started adding more functions. We got another six weeks to complete the product. I made it very clear that I didn’t want to see any more memory leaks. Actually that I didn’t want to see any defects. The result was that the testers suddenly found hardly any defect any more and from now on could check the correct functioning of the device. At the end of the second phase of six weeks, the project was successfully closed. The product manager was happy with the result.
이제 시스템이 안정화되었다. 그들은 기능들을 추가하기 시작했다. 우리는 다시 6주가 걸려 제품을 완성할 수 있었다. 나는 더 이상의 메모리 릭을 보고 싶지 않다는 점을 분명히 했다. 실제로 나는 더 이상의 결함을 보고 싶지 않았다. 결과적으로 테스터가 더 이상의 결함을 찾기가 어려워졌다. 이제는 그 디바이스의 기능이 올바른지만 체크하였다. 6주 기간의 두번째 단계의 말미에 그 프로젝트는 성공적으로 종료되었다. 프로덕트 매니저는 이러한 결과를 좋아했다.

Conclusion: after I made it clear that I didn’t want to see any defects, the team hardly produced any defects. The few defects found were easy to trace and repair. The change of attitude saved a lot of defects and a lot of time. The team could spend most of its time adding new functionality instead of fixing defects. This was Zero Defects at work. Technical knowledge was not the problem to these people: once challenged, they quickly came up with tooling to analyze the problem and solve it. The attitude was what made the difference.
결론: 내가 더 이상의 결함을 보고 싶지 않다는 점을 분명히 한 후, 그 팀은 결함을 잘 만들지 않았다. 발견된 몇 개의 결함은 추적과 수정이 용이했다. 태도의 변화가 많은 결함과 시간을 절약했다. 그 팀은 결함을 수정하는 대신에 새로운 기능 추가에 대부분의 시간을 쓸 수 있었다. 이것은 일에서 결함이 없는 것이다. 기술적인 지식은 이러한 사람들에게 문제가 되지 않는다. 그들이 도전을 한 이후에는 문제를 분석하는데 도구를 사용했고, 그 문제를 해결했다. 이러한 태도가 차이를 만든다.

10. Plan-Do-Check-Act
10. Plan-Do-Check-Act

I assume the Plan-Do-Check-Act (PDCA- or Deming-) cycle [7] is well known (Figure 2, next page). Because it’s such a crucial ingredient, I’ll shortly reiterate the basic idea:
PDCA 싸이클 [7]이 널리 알려져 있다고 가정하겠다 (그림 2). 이것들이 가장 중요한 요소이기 때문에, 짧게 그 기본 아이디어를 반복하겠다.

    * We Plan what we want to accomplish and how we think to accomplish it best.
    * 우리는 달성하기 원하는 것에 대해 계획을 세우고, 어떻게 그것을 최고로 달성할 수 있는지 생각한다.


    * We Do according to the plan.
    * 계획대로 수행한다.


    * We Check to observe whether the result from the Do is according to then Plan.
    * 수행한 것이 계획과 일치하는지 관찰하고 체크한다.


    * We Act on our findings. If the result was good: what can we do better. If the result was not so good: how can we make it better. Act produces a renewed strategy.
    * 우리가 찾은 결과대로 행동한다. 결과가 좋았다면, 더 낫게 할 수 있을 것이고, 결과가 좋지 못했다면, 어떻게 하면 낫게 할 수 있을지 알 수 있다. 행동은 새로운 전략을 만들어 낸다.

The key-ingredients are: planning before doing, systematically checking and above all acting: doing something differently. After all, if you don’t do things differently, you shouldn’t expect a change in result.
핵심요소는 수행하기 전에 계획을 세우는 것으로, 시스템적으로 점검하고, 행동을 하는 것으로 무언가를 다르게 수행하는 것이다.  결국, 당신이 일을 다르게 하지 않으면, 결과가 다를 것을 기대해서는 안 된다.

In Evo we constantly go through multiple PDCA cycles, deliberately adapting strategies in order to learn how to do things better all the time, actively and purposely speeding up the evolution of our knowledge.
Evo에서 우리는 지속적으로 다중 PDCA 싸이클을 돌았고, 꾸준히 어떻게 하면 더 낫게할 수 있는지 배우기 위해 전략을 수정해 나갔으며, 의도적이고 능동적으로 우리 지식의 진화를 가속화시켰다.

As a driver for moving the evolution in the right direction, we use Return on Investment (ROI): the project invests time and other resources and this investment has to be regained in whatever way, otherwise it’s just a hobby. So, we’ll have to constantly be aware whether all our actions contribute to the value of the result. Anything that does not contribute value, we shouldn’t do.
진화를 올바른 방법으로 이끌어가기 위한 동인으로, 우리는 ROI를 사용했다. 그 프로젝트에 시간과 또 다른 리소스들을 투자했고, 이러한 투자는 어떤 식으로든 회수되어야 했다. 그렇지 않으면, 취미에 불과했다. 따라서, 우리는 우리의 액션들이 결과에 가치를 제공할 것인지 아닌지 끊임없이 주의해야만 했다. 가치를 줄 수 없는 것은 수행할 필요가 없었다.

Furthermore, in order to maximize the ROI, we have to do the most important things first. In practice, priorities change dynamically during the course of the project, so we constantly reprioritize, based on what we learnt so far. Every week we ask ourselves: “What are the most important things to do. We shouldn’t work on anything less important.” Note that priority is molded by many issues: customer issues, project issues, technical issues, people issues, political issues and many other issues.
더 나아가서, ROI를 최대화시키기 위해, 우리는 가장 중요한 것을 먼저 했다. 실무에서 우선 순위 변경은 프로젝트 기간 동안에 동적으로 이루어진다. 따라서, 우리는 지금까지 배운 것에 의거해서 늘 우선순위를 재평가했다. 매주 스스로에게 질문했다. "해야할 가장 중요한 일은 무엇인가? 덜 중요한 것은 하지 않아야 한다." 우선순위라는 것은 수많은 이슈들, 고객 이슈, 프로젝트 이슈, 기술적인 이슈, 사람 이슈, 정치적인 이슈 등의 다른 모든 이슈들에 의해서 형성된다는 점을 기억하라.

11. How about Project Evaluations
11. 프로젝트 평가는?

Project Evaluations (also called Project Retrospectives, or Post-Mortems - as if all projects die) are based on the PDCA cycle as well. At the end of a project we evaluate what went wrong and what went right.
프로젝트 평가 (모든 프로젝트가 죽었다고 보았는지, 프로젝트가 종료되었을 때의 프로젝트 회고나 포스트 모텀으로도 불린다) 역시 PDCA 싸이클에 기반을 둔다. 프로젝트의 말미에 무엇이 잘못되었고, 무엇이 옳았는지 평가한다.

Doing this only at the end of a project has several drawbacks:
이것을 프로젝트 말미에 하는 것은 몇 가지 단점을 가진다.

    * We tend to forget what went wrong, especially if it was a long time ago.
    * 우리는 아주 오래전에 발생한 일인 경우 무엇이 잘못되었는지 자주 잊어버린다.


    * We put the results of the evaluation in a write-only memory: do we really remember to check the evaluation report at the very moment we need the analysis in the next project?

    Note that this is typically one full project duration after the fact.

    * 우리는 평가 결과를 적기만 한다. 우리가 다음 프로젝트에서 분석이 필요한 바로 그 시점에 평가 리포트를 살펴보고 있나? 이러한 일은 프로젝트가 끝난 후 늘상 일어난다.


    * The evaluations are of no use for the project just finished and being evaluated.
    * 평가는 막 끝낸 프로젝트나 평가중인 프로젝트에는 쓸모가 없다.


    * Because people feel these drawbacks, they tend to postpone or forget to evaluate. After all, they are already busy with the next project, after the delay of the previous project.

    In short: the principle is good, but the implementation is not tuned to the human time-constant.

    * 사람들이 이러한 단점들을 인지하고 있기 때문에, 평가를 미루거나 잊어버리곤 한다. 결국, 그들은 이전 프로젝트가 지연된 이후에 다음 프로젝트에서 또 바쁘게 된다. 요약하면, 원리는 좋으나, 시간의 제약때문에 적용되지 않는다.

In Evo, we evaluate weekly (in reality it gradually becomes a way-of-life), using PDCA cycles, and now this starts to bear fruit (Figure 3):
Evo에서 우리는 PDCA 싸이클을 이용해서 주간 단위로 평가를 실시 했다 (현실에서도 인생의 단위이기도 하다). 이제는 결실을 보기 시작했다 (그림 3).

    * Not so much happens in one week, so there is not so much to evaluate.
    * 1주 동안에 그다지 많은 일이 발생하지 않았다면, 평가할 꺼리도 많지 않았다.


    * It’s more likely that we remember the issues of the past five days.
    * 지난 5일간의 이슈에 대해서 더 잘 기억한다.


    * Because we most likely will be working on the same kind of things during the following week, we can immediately use the new strategy, based on our analysis.
    * 다음 1주일 간 동일한 유형의 일들을 할 가능성이 높기 때문에, 우리는 우리가 행한 분석에 의거해 새로운 전략을 즉시 적용할 수 있었다.


    * One week later we can check whether our new strategy was better or not, and refine.
    * 1주가 지난 후에 우리의 전략이 적합했는지 점검해 보고, 세부 조정한다.


    * Because we immediately apply the new strategy, it naturally is becoming our new way of working.
    * 우리가 즉시로 새로운 전략을 적용했기 때문에, 자연적으로 새로운 작업 방식이 되었다.


    * The current project benefits immediately from what we found and improved.
    * 현재 프로젝트는 우리가 찾고 개선한 것들로 부터 즉시 효과를 보았다.


So, evaluations are good, but they must be tuned to the right cycle time to make them really useful. The same applies to testing, as this is also a type of evaluation.
따라서, 평가를 수행하는 것은 좋은 것이지만, 진정으로 유용해지기 위해서는 올바른 싸이클을 통해 적용되어야 한다. 이것 또한 평가이기 때문에, 테스팅에도 동일한 원리가 적용된다.

12. Current Evo Testing
12. 현재의 Evo 테스팅

Conventionally, a lot of testing is still executed in Waterfall mode, after the Code Complete milestone. I have difficulty understanding this “Code Complete”, while apparently the code is not complete, witness the planned “debugging” phase after this milestone. Evo projects do not need a separate debugging phase and hardly need repair after delivery. If code is complete, it is complete. Anything is only ready if it is completely done, not to worry about it any more. That includes: no defects. I know we are human and not perfect, but remember the importance of attitude: we want to be perfect. (주1)
관례적으로, 많은 테스팅이 여전히 코드 컴플릿 마일스톤 이후 워터폴 모델에서 실행되고 있다. 나는 명백하게 코드가 완료된 것이 아니기 때문에 "코드 컴플릿"이라는 용어를 이애하기 어렵다. 또, 이러한 마일스톤 이후에 "디버깅"이라는 단계가 계획되어 있기 때문에도 그렇다. Evo 프로젝트는 별개의 디버깅 단계를 필요로하지 않으며, 산출 이후에 수정할 필요도 거의 없었다. 코드가 완성되면, 그건 완료된 것이다. 무언가가 완전하게 마무리되면, 이미 준비가 된 것으로, 더 이상 그것에 대해 고민하지 않아야 한다. 이것에는 무결점도 포함된다. 우리 인간은 완벽하지 않지만, 태도의 중요성을 기억해야 한다. 우리는 완벽해지기를 원한다. (주1)

Because we regularly deliver results, testers can test these intermediate results (Figure 4). They feed back their findings, which we will use for prevention or optimization. Most issues that are not caught by the testers (I suppose testers are human as well) may be found in subsequent deliveries. This way, most of any undiscovered defects will be caught before the final delivery and, more importantly, be exploited for prevention of further injection of similar defects. Because all people in the project aim for Zero Defects delivery, the developers and testers work together in their quest for perfection. Note that perfection means: freedom from fault or defect. It does not mean: gold plating.
우리가 주기적으로 결과를 내었기 때문에, 테스터들은 이러한 중간 결과에 대해서 테스트를 할 수 있었다 (그림 4). 그들은 찾은 것에 대해 피드백을 주었고, 우리는 그것을 (문제) 예방이나 최적화에 사용했다. 테스터에 의해 발견되지 않는 대부분의 문제들은 (테스터 또한 인간이라고 가정한다) 연속적인 산출에서도 발견될 것이다. 이런 식으로 발견되지 않은 대부분의 결함들이 최종 산출 이전에 제거되었다. 더 중요한 것은, 유사 결함의 추가적인 유입을 방지하기 위해 사용되었다는 점이다. 프로젝트의 모든 인력이 무결점의 산출을 추구했기 때문에, 개발자와 테스터들은 협력해서 자신들의 임무를 완벽하게 수행하였다. 완벽이라는 말은 "실수나 결함으로 부터의 자유"를 의미하지, 말 그대로의 완벽을 말하는 것이 아님을 주의하라.

13. Further improvement
13. 더 나은 개선

To further improve the results of the projects, we can extend the Evo techniques to the testing process and exploit the PDCA paradigm even further:
그 프로젝트의 결과를 더 낫게 하기 위해, 우리는 Evo 기법을 테스팅 프로세스에도 적용할 수 있고, 더욱 개선하기 위해 PDCA 패러다임을 활용할 수도 있다.

    * Testers focus on a clear goal. Finding defects is not the goal. After all, we don’t want defects. Any defects found are only a means to achieve the real goal: the success of the project.

    * 테스터들은 명확한 목표에 집중한다. 결함을 찾는 것은 목표가 아니다. 결국, 우리는 결함을 원치 않는다. 결함을 찾는 것은 실제 목표인 프로젝트의 성공을 달성하는 수단일 뿐이다.


    * Testers will select and use any method appropriate for optimum feedback to development, be it testing, review or inspection, or whatever more they come up with.
    * 테스터들은 테스팅하거나, 리뷰나 인스펙션을 하거나 무엇을 하든간에 개발팀에 최적의 피드백을 줄 수 있는 방법을 선정해서 사용한다.


    * Testers check work in progress even before it is delivered, to feedback issues found, allowing the developer to abstain from further producing these issues for the remainder of his work.

    * 테스터들은 작업이 산출되기도 전에, 진행 중일 때 체크한다. 발견된 이슈를 피드백하고, 개발자들이 자신이 해야 될 나머지 작업에서 더 이상 이러한 이슈들을 만들지 못하도록 한다.


    * “Can I check some piece of what you are working on now?” “But I’m not yet ready!” “Doesn’t matter. Give me what you have. I’ll tell you what I find, if I find anything”. Testers have a different view, seeing things the developer doesn’t see. Developers don’t naturally volunteer to have their intermediate work checked. Not because they don’t like it to be checked, but because their attention is elsewhere. Testers can help by asking. Initially the developers may seem a little surprised, but this will soon fade.

    * "지금 당신이 작업하고 있는 일부분을 내가 체크해 볼 수 있나요?" "하지만 아직 준비가 안 되었는데요!" "걱정말아요. 지금하고 있는 걸 보여주세요. 내가 찾은 것이 있다면 찾은 것을 말해줄께요." 테스터들은 개발자가 보지 못하는 것을 보는 다른 관점을 가지고 있다. 개발자들은 본래 자신들의 중간 산출물을 체크하도록 스스로 자원하지 않는다. 그들이 자신의 작업이 체크되는 것을 싫어하기 때문이 아니라, 그들의 관심이 다른 곳에 있기 때문이다. 테스터들은 질문을 통해 도울 수 있다. 최초에는 그 개발자들이 놀라는 것처럼 보일 수 있지만, 곧 안정될 것이다.


    * Similarly, testers can solve a typical problem with planning reviews and inspections. Developers are not against reviews and inspections, because they very well understand the value. They have trouble, however, planning them in between of their design work, which consumes their attention more. If we include the testers in the process, the testers will recognize when which types of review, inspections or tests are needed and organize these accordingly. This is a natural part of their work helping the developers to minimize rework by minimizing the injection of defects and minimizing the time slipped defects stay in the system.

    * 마찬가지로, 테스터들은 리뷰와 인스펙션을 계획하는데 있어 발생하는 일반적인 문제들을 해결할 수 있다. 개발자들은 리뷰와 인스펙션을 반대하지 않는다. 왜냐하면, 이들은 그 가치를 너무나 잘 알고 있기 때문이다. 하지만, 그들이 자신들의 주의를 쏟아야 하는 디자인 작업들 간에 리뷰 일정을 계획하는데 어려움을 겪는다. 만일 그 테스터가 프로세스 안에 포함된다면, 그 테스터는 어떤 유형의 리뷰, 인스펙션 또는 테스트가 필요한지 인식하고, 그것들을 잘 조직화할 것이다. 이것이 이들이 결함의 유입을 최소화하고, 시스템에 실수로 빠뜨리는 결함을 적게해서 재작업을 줄여 개발자를 돕는 자연스러운 업무이다.


    * In general: organizing testing the Evo way means entangling the testing process more intimately with the development process.
    * 일반적으로 Evo 방식으로 테스팅을 조직화하는 것은 테스팅 프로세스와 개발 프로세스가 더욱 밀접하게 되도록 확장하는 것을 의미한다.

14. Cycles in Evo
14. Evo에서의 싸이클

In the Evo development process, we use several learning cycles:
Evo 개발 프로세스에서 우리는 몇 가지 배움의 싸이클을 사용한다.

    * The TaskCycle [9] is used for organizing the work, optimizing estimation, planning and tracking. We constantly check whether we are doing the right things in the right order to the right level of detail. We optimize the work effectiveness and efficiency. TaskCycles never take more than one week.

    * 태스크싸이클 [9]은 작업을 조직화하고 추정, 계획, 추적을 최적화하는데 사용된다. 우리는 끊임없이 우리가 올바른 것을 올바른 순서로, 올바른 세밀함으로 수행하고 있는지 체크한다. 우리는 그 작업효율성과 효과성을 최적화한다. 태스크싸이클은 1주 이상으로 잡지 않는다.


    * The DeliveryCycle [10] is used for optimizing the requirements and checking the assumptions. We constantly check whether we are moving to the right product results. DeliveryCycles focus the work organized in TaskCycles. DeliveryCycles normally take not more than two weeks.
    * 딜리버리싸이클 [10]은 요구사항과 가정의 확인을 최적화하는데 사용한다. 우리는 끊임없이 우리가 올바른 제품으로 나아가고 있는지 체크한다. 딜리버리싸이클은 태스크싸이클안에서 조직화된 작업에 집중한다. 대개 딜리버리싸이클은 2주 이상으로 잡지 않는다.


    * TimeLine [11] is used to keep control over the project duration. We optimize the order of DeliveryCycles in such a way that we approach the product result in the shortest time, with as little rework as possible.
    * 타임라인 [11]은 프로젝트 기간 동안에 제어를 유지하는데 사용한다. 우리는 최대한 짧은 시간, 최대한 적은 재작업을 유도하는 제품이 되도록 딜리버리싸이클의 순서를 최적화한다.


During these cycles we are constantly optimizing:
이러한 싸이클동안에 우리는 지속적으로 최적화를 한다.

    * The product [12]: how to arrive at the best product (according to the goal).
    * 제품 [12]: 어떻게 해야 최고의 제품을 내놓을 수 있을까? (목표에 맞추어)


    * The project [13]: how to arrive at this product most effectively and efficiently.
    * 프로젝트 [13]: 어떻게 해야 이 제품을 가장 효과적이고 효율적으로 내놓을 수 있을까?


    * The process [14]: finding ways to do it even better. Learning from other methods and absorbing those methods that work better, shelving those methods that currently work less effectively.
    * 프로세스 [14]: 무언가 더 낫게할 수 있는 방법을 찾음. 다른 방법론으로부터 배우거나 그 방법론으로부터 더 낫게할 수 있는 걸 차용함. 현재 덜 효과적인 작업을 그 방법론으로 제거함.


If we do this well, by definition, there is no better way.
정의상, 우리가 이것을 잘하고 있다면, 더 나아질 수 있는 방법은 없다.

15. Evo cycles for testing
15. 테스팅에서의 Evo 싸이클

Extending Evo to testing adds cycles for feedback from testing to development, as well as cycles for organizing and optimizing the testing activities themselves.
Evo를 테스팅으로 확장하는 것은 테스팅에서 개발로의 피드백 싸이클을 추가하는 것 뿐만 아니라, 테스팅 활동 그 자체를 최적화하고 조직화하는 싸이클도 포함된다.

    * Testers organize their work in weekly, or even shorter TaskCycles.
    * 테스터들은 자신들의 작업을 주간단위로 조직화하거나 태스크싸이클 보다 적게 잡기도 한다.


    * The DeliveryCycle of the testers is the Test-feedback cycle: in very short cycles testers take intermediate results from developers, check for defects in all varieties and feed back optimizing information to the developers, while the developers are still working on the same results. This way the developers can avoid injecting defects in the remainder of their work, while immediately checking out their prevention ideas in reality.
    * 테스터의 딜리버리싸이클은 테스트 후 피드백의 싸이클이다. 아주 짧은 싸이클에서 테스터들은 개발자로 부터 중간산출물을 가져와서, 다양한 방면의 결함을 체크하고, 개발자에 최적화된 정보를 피드백한다. 반면에 개발자는 동일한 작업물을 가지고 계속 작업한다. 이러한 방식은 개발자들이 즉시로 현실적인 결함방지 아이디어를 시험하도록 해서 남아 있는 작업물로의 결함유입을 줄인다.


    * The Testers use their own TimeLine, synchronized with the development TimeLine, to control that they plan the right things at the right time, in the right order, to the right level of detail during the course of the project and that they conclude their work in sync with development.
    * 테스터들은 개발과 자신들의 작업의 동기를 맞추고, 프로젝트의 일정 동안에 올바른 수준의 세밀함과, 올바른 순서, 적시에 필요한 일을 하기 위해서, 개발 타임라인과 맞추어진 자신들의 타임라인을 사용한다.


During these cycles the testers are constantly optimizing:
이러한 싸이클 동안에 테스터들은 끊임없이 최적화를 수행한다.

    * The product: how to arrive at the most effective product.
    * 제품: 어떻게 해야 가장 효과적인 제품을 내놓을 수 있을까?


    * Remember that their product goal is: providing their customer, in this case the developers, with what they need, at the time they need it, to be satisfied, and to be more successful than they were without it.
    * 이 제품의 목표를 기억하자. 고객에게 제공되며, 이 경우에는 개발자가 고객이 된다. 그들의 필요에 따라 적시에, 만족할 수 있도록, 그러한 피드백이 성공에 도움이 되도록...


    * The project: how to arrive at this product most effectively and efficiently. This is optimizing in which order they should do which activities to arrive most efficiently at their result.
    * 프로젝트: 어떻게 하면 이 제품을 효과적으로 효율적으로 내놓을 수 있을까? 이것은 가장 효과적으로 결과를 내놓기 위해서는 어떤 활동이 어떤 순서로 최적화되어야 하는지를 말한다.


    * The process: finding ways to do it better. Learning from other methods and absorbing those methods that work better, shelving those methods that currently work less effectively. Testers are part of the project and participate in the weekly 3-step procedure [15] using about 20 minutes per step:
    * 프로세스: 더 나아질 수 있는 방법을 찾는다. 다른 방법론에서 배우고, 적용한다. 덜 효과적인 방법이 있다면 그 방법론을 사용해 제거한다. 테스터들은 프로젝트의 구성원으로, 단계별로 20분 가량을 투입하여 주간 3스텝 프로시저에 참여한다.


1. Individual preparation.
1. 개별 준비.

2. 1-to-1’s: Modulation with and coaching by Project Management.
2. 1에서 1'까지 프로젝트 관리자에 의해 코칭받거나 조정됨.

3. Team meeting: Synchronization and synergy with the team.
3. 팀 미팅: 팀 작업에 동기를 맞추고, 시너지를 발휘.

Project Management in step 2 is now any combination, as appropriate, of the following functions:
단계 2에서의 프로젝트 관리가 적절한 경우, 이제 다음 기능의 어떤 조합도 가능하다.

    * The Project Manager or Project Leader, for the project issues.
    * 프로젝트 이슈에 대해서 PM 또는 PL


    * The Architect, for the product issues.
    * 제품 이슈에 대한 아키텍쳐


    * The Test Manager, for the testing issues.
    * 테스팅 이슈에 대한 테스트 매니저.


There can be only one captain on the ship, so the final word is to the person who acts as Project Manager, although he should better listen to the advice of the others.
배에는 한 명의 선장만 가능하다. 따라서, 그가 다른 이들의 충고에 귀를 기울이는게 나을 지는 모르겠지만, 최종 결정은 PM 역할을 하는 사람에게 있다.

Testers participate in requirements discussions. They communicate with developers in the unplannable time [16], or if more time is needed, they plan tasks for interaction with developers. If the priority of an issue is too high to wait for the next TaskCycle, the interrupt procedure [17] will be used. If something is unclear, an Analysis Task [18] will be planned. The Prevention Potential of issues found is an important factor in the prioritizing process.
테스터들은 요구사항 토의에 참여한다. 그들은 자주 개발자들과 의사소통 하거나 [16], 시간이 더 필요한 경우 개발자들과 상호작용할 시간 계획을 세운다. 다른 태스크싸이클 동안 기다리기에 이슈의 우선순위가 높은 경우, 인터럽트 프로시저 [17]가 사용된다. 무언가가 명확하지 않으면, 분석 태스크 [18]가 계획된다. 발견된 이슈의 잠재적인 예방 능력은 우선 순위 프로세스에서 중요한 요인이다.

In the team meeting testers see what the developers will be working on in the coming week and they synchronize with that work. There is no ambiguity any more about which requirements can be tested and to which degree, because the testers follow development, and they design their contribution to assist the project optimally for success.
팀 미팅에서 테스터는 차주에 개발자들이 어떤 일을 하게되는지 알게되어, 그 작업과 동기를 맞춘다. 어떤 요구사항이 어느 정도로 테스트되어야 하는지에 대해서 더이상 모호하지 않다. 왜냐하면, 테스터가 개발에 맞추어 프로젝트 성공을 위해 프로젝트에 어떻게 기여해야 되는지 디자인하기 때문이다.

In Evo Testing, we don’t wait until something is thrown at us. We actively take responsibility. Prevention doesn’t mean sitting waiting for the developers. It means to decide with the developers how to work towards the defect free result together. Developers doing a small step. Testers checking the result and feeding back any imperfections before more imperfections are generated, closing the very short feedback loop. Developers and testers quickly finding a way of optimizing their cooperation. It’s important for the whole team to keep helping each other to remind that we don’t want to repair defects, because repair costs more. If there are no defects, we don’t have to repair them.
Evo 테스팅에서, 우리는 어떤 것이 그들에 의해 던져질 때까지 기다리지 않는다. 우리는 능동적으로 책임을 진다. 예방은 개발자들을 앉아서 맞이하는게 아니다. 개발자와 함께 어떻게 작업 결과에 결함이 없도록 할 것인지 협력하는 것이다. 개발자들은 작은 단위의 작업을 한다. 테스터는 그 결과를 체크하고, 더 많은 불합치가 발생하기 전에 발견된 불합치에 대해서 피드백을 준다. 매우 짧은 피드백 루프가 완료된다. 개발자와 테스터는 그들이 협력할 수 있는 최적의 방법을 빠르게 찾는다. 이것은 결함을 수정하는 것보다 리마인드를 해주어 서로간에 돕는 것으로 전체 팀에게 중요하다. 왜냐하면, 수정 비용이 더 많기 때문이다. 만일 아무런 결함도 없다면, 우리가 그것을 수정할 필요가 없다.

Doesn’t this process take a lot of time? No. My experience with many projects shows that it saves time, projects successfully finishing well before expected. At the start it takes some more time. The attitude, however, results in less defects and as soon as we focus on prevention rather than continuous injection-finding-fixing, we soon decrease the number of injected defects considerably and we don’t waste time on all those defects any more.
이 프로세스가 시간이 많이 들까? 아니다. 수많은 프로젝트에서의 내 경험으로 볼 때, 이렇게 하면 시간이 절약되고, 예상했던 것보다 더 빨리 프로젝트가 성공적으로 종료된다. 물론 처음 시작할 때는 더 많은 시간이 걸린다. 하지만, 이러한 태도는 더 적은 결함을 만들어 내고, 지속적으로 결함이 유입되고 수정되는 싸이클에서 예방으로 초점이 이동한다. 우리는 곧 결함 유입이 확연히 줄고, 더 이상 그러한 결함을 수정하는데 시간을 쏟지 않아도 된다.

16. Database for Change Requests and Problem Reports and Risk Issues
16. 요구사항 변경 요청과 문제 리포트 그리고, 리스크 이슈 데이터 베이스

Most projects already use some form of database to collect defects reported (Problem Report/PR: development pays) and proposed changes in requirements (Change Request/CR: customer pays).
대부분의 프로젝트들은 이미 결함 리포트 (문제 리포트/PR: 개발이 비용을 지불하는), 요구사항의 변경 요청 (변경 요청/CR: 고객이 비용을 지불하는)을 위한 어떤 형태의 데이터베이스를 사용한다.

If we are seriously in Prevention Mode, striving for Zero Defects, we should also collect Risk Issues (RI): issues which better be resolved before culminating into CR’s or PR’s.
만일 우리가 진지하게 예방 모드에 돌입해 있고, 무결점에 대한 갈망이 있다면, 우리는 리스트 이슈 (RI) 즉, CR이나 PR의 정점을 찍기전에 더 좋게 해결될 수 있는 이슈에 대해서 수집해야 한다.

With the emphasis shifted from repair to prevention, this database will, for every RI/CR/PR, have to provide additional space for the collection of data to specifically support the prevention
process, like:
수정에서 예방으로 관점을 돌릴 때, 이 데이터베이스는 모든 RI/CR/PR에 대해서 특별히 예방 프로세스에 대한 데이터를 수집하기 위한 공간을 제공해야 한다.

    * Follow-up status.
    * 후속 조치 상태.


    * When and where found.
    * 언제, 어디서 발견되었나.


    * Where caused and root cause
    * 어디서 연유되었으나 근본 원인은 무엇인가


    * Where should it have been found earlier
    * 이전 단계 어느 부분에서 찾았어야 하나


    * Why didn’t we find it earlier
    * 왜 이전 단계에서 찾지 못했나


    * Prevention plan
    * 예방 플랜


    * Analysis task defined and put on the Candidate Task List [19].
    * 분석 태스크를 정의하고, 후보 태스크 리스트를 넣음 [19].


    * Prevention task(s) defined and put on the Candidate Task List.
    * 예방 태스크를 정의하고, 후보 태스크 리스트를 넣음.


    * Check lists updated for finding this issue easier, in case prevention doesn’t work yet.
    * 예방이 이루어지지 않은 경우에, 이 이슈를 이전 단계에서 쉽게 찾기위해 체크리스트를 업데이트 한다.


Analysis tasks may be needed to sort out the details. The analysis and repair tasks are put on the Candidate Task List and will, like all other candidate tasks, be handled when their time has come: if nothing else is more important. Analysis tasks and repair tasks should be separated, because analysis usually has priority over repair. We better first stop the leak, to make sure that not more of the same type of defect is injected.
분석 태스크는 더 상세한 것으로 나누어야 한다. 분석과 수정 태스크는 후보 태스크 리스트로 들어가며, 다른 모든 후보 태스크들처럼 다른 중요한 것이 없고, 해당 시간이 될 때 발생한다. 분석 태스크와 수정 태스크는 서로 나뉘어야 한다. 왜냐하면, 대개 분석은 수정보다 비중이 있기 때문이다. 문제가 처음 발생했을 때 더 이상 동일한 유형의 결함이 유입되지 않도록 하기 위해 멈추는 것이 좋다.

17. How about metrics?
17. 메트릭은 어떤가?

In Evo, the time to complete a task is estimated as a TimeBox [20], within which the task will be 100% done. This eliminates the need for tracking considerably. The estimate is used during the execution of the task to make sure that we complete the task on time. We experienced that people can quite well estimate the time needed for tasks, if we are really serious about time.
Evo에서 한 태스크를 완료하는 시간은 그 태스크가 100% 달성될 수 있는 시간 내인, 타임박스 [20]로 추정된다. 이것은 추적에 대한 필요성을 극적으로 없애준다. 추정은 태스크를 실행하는 동안에 적시에 그 태스크를 완료하였는지 확인하는데 사용된다. 우리는 우리가 시간에 대해서 정말 진지해진다면, 해당 태스크에 필요한 시간을 사람들이 매우 잘 추정한다는 걸 경험했다.

Note that exact task estimates are not required. Planning at least 4 tasks in a week allows some estimates to be a bit optimistic and some to be a bit pessimistic. All we want is that, at the end of the week, people have finished what they promised. As long as the average estimation is OK, all tasks can be finished at the end of the week. As soon as people learn not to overrun their (average) estimates any more, there is no need to track or record overrun metrics. The attitude replaces the need for the metric.
정확한 태스크 추정을 요구하는게 아니라는 점이 중요하다. 한 주에 최소 4개의 태스크를 계획할 때, 누군가는 낙관적으로, 누군가는 비관적으로 추정할 수 있다. 우리 모두가 원하는 것은 해당 업무 주간의 마지막에 사람들이 약속한 것을 완료하는 것이다. 평균적인 추적이 용인되는 한, 모든 태스크는 그 주의 마지막에 완료될 수 있다. 사람들의 (평균적인) 추정이 더 이상 과도한 것이 아니라면, 과도한 메트릭을 기록하고 추적할 필요가 없다. 태도가 바뀌면 메트릭의 필요성도 없어진다.

In many cases, the deadline of a project is defined by genuine external factors like a finite market-window. Then we have to predict which requirements we can realize before the deadline or “Fatal-Date”. Therefore, we still need to estimate the amount of work needed for the various requirements. We use the TimeLine technique to regularly predict what we will have accomplished at the FatalDate and what not, and to control that we will have a working product well before that date. Testers use TimeLine to control that they will complete whatever they have to do in the project, in sync with the developers.
많은 경우에, 프로젝트의 데드라인은 마케팅 이슈 같은 순수하게 외부적인 요인에 의해 결정된다. 따라서, 우리는 데드라인 이나 "운명의 날"이 닥치기 전에 어떤 요구사항들이 구현될 수 있는지 예측해야 한다. 그러므로, 우리는 다양한 요구사항에 맞추어 필요한 작업의 양을 여전히 추정해야 한다. 우리는 운명의 날에 무엇을 완료할 수 있는지 또는 그렇지 않은지 주기적으로 예측하고 제대로 된 제품을 손에 넣을 수 있도록 (프로젝트를) 제어할 수 있도록 주기적으로 예측하는데 타임라인 기법을 사용한다. 테스터는 개발자와 동기를 맞추고, 프로젝트에서 그들이 완료해야 하는 것들을 제어하는데 타임라인을 사용한다.

Several typical testing metrics become irrelevant when we aim for defect free results, for example:
결함없는 결과물을 목표로 할 때 몇가지 전형적인 테스팅 메트릭들이 쓸모없게 된다. 예를 들면,

    * Defects-per-kLoC or Defects-per-page

    Counting defects condones the existence of defects, so there is an important psychological reason to discourage counting them.

    * KLOC 또는 페이지당 결함
          o 결함을 세는 것은 결함의 존재에 대해 용서하는 것이다. 결함을 세지 않도록 하는 중요한 심리적인 이유가 있다.


    * Incoming defects per month, found by test, found by users

    Don’t count incoming defects. Do something about them. Counting conveys a wrong message. We should better make sure that the user doesn’t experience any problem.

    * 테스트 또는 유저에 의해 발견된 월간 유입 결함 수
          o 유입 결함 수를 세지 마라. 그것에 대해 무언가만 해라. 세는 것은 잘못된 메시지를 전달한다. 유저가 어떤 문제도 경험하지 않도록 하는 것이 더 낫다.


    * Defect detection effectiveness or Inspection yield (found by test / (found by test + customer)

          o There may be some defects left, because perfection is an asymptote. It’s the challenge for testers to find them all. Results in practice are in the range of 30% to 80%. Testers apparently are not perfect either. That’s why we must strive towards zero defects before final test. Whether that is difficult or not, is beside the point.
          o 몇몇 결함들은 남겨질 수도 있다. 왜냐하면 완벽이라는 건 점선이기 때문이다. 그들 모두를 찾아내는 것은 테스터들에게 도전이다. 실무에서의 결과는 30%에서 80%까지이다. 테스터들은 명백하게 완전하지 않다. 이것이 왜 우리가 최종 테스트 이전까지 무결정을 추구해야 하는지에 대한 이유이다. 그것이 어렵거나 어렵지 않거나 하는 문제는 논점이 아니다.


    * Cost to find and fix a defect

          o The less defects there are, the higher the cost to find and fix the few defects that slip through from time to time, because we still have to test, to see that the result is OK. This was a bad metric anyway.
    * 결함 한 개를 발견하고 수정하는 비용을 산출하기
          o 소수의 결함이 존재한다면, 때로는 놓치기도 하는 소수의 결함을 찾고 수정하는 비용은 높다. 왜냐하면, 우리는 여전히 테스트를 해야 하고, 그 결과가 OK인지 확인해야 하기 때문이다. 이것은 어쨌든 좋지 않은 메트릭이다.


    * Closed defects per month or Age of open customer found defects

          o Whether and how a defect is closed or not, depends on the prioritizing process. Every week any problems are handled, appropriate tasks are defined and put on the Candidate Task List, to be handled when their time has come. It seems that many metrics are there because we don’t trust the developers to take appropriate action. In Evo, we do take appropriate action, so we don’t need policing metrics.
    * 월간 종료 결함수 또는 고객이 발견한 결함이 살아있는 기간
          o 결함이 종료되는지 아닌지는 우선 순위 프로세스에 달려있다. 매 주간마다 모든 결함이 다루어지고, 적절한 태스크가 정의되고, 후보 태스크 리스트가 추천되며, 시간이 되면 처리된다. 많은 메트릭들이 여기에 있는 것처럼 보인다. 왜냐하면, 우리는 개발자가 적절한 액션을 하고 있다고 믿지 않기 때문이다. Evo에서 우리는 적절한 액션을 수행한다. 따라서, 상벌을 위한 메트릭들은 필요없다.


    * When are we done with testing?

          o Examples from conventional projects: if the number of bugs found per day has declined to a certain level, or if the defect backlog has decreased to zero. In some cases, curve fitting with early numbers of defects found during the debugging phase is used to predict the moment the defect backlog will have decreased to zero. Another technique is to predict the number of defects to be expected from historical data. In Evo projects, the project will be ready at the agreed date, or earlier. That includes testing being done.
    * 언제 테스팅을 종료하나?
          o 전형적인 프로젝트의 예를 보면, 하루에 발견되는 버그의 수가 특정 수준으로 떨어지거나 결함 백로그가 0으로 감소한다. 어떤 경우, 디버깅 기간 초기에 발생한 결함수의 곡선이 평평해 지는 것을, 결함 백로그가 0으로 감소하는 지점으로 추정하는데 사용한다. 또 다른 기법은 과거의 데이터로 부터 예상된 결함수로 추정한다. Evo 프로젝트에서는 그 프로젝트가 합의된 기간 또는 그 보다 빨리 준비가 되었다. 테스팅 완료도 포함해서 말이다.


Instead of improving non-value adding activities, including various types of metrics, it is better to eliminate them. In many cases, the attitude, and the assistance of the Evo techniques replace the need for metrics. Other metrics may still be useful, like Remaining Defects, as this metric provides information about the effectiveness of the prevention process. Still, even more than in conventional metrics activities, we will be on the alert that whatever we do must contribute value.
가치가 없는 활동, 다양한 메트릭을 개선하는 대신에 그것들을 없애는 것이 더 낫다. 많은 경우에 태도와 Evo 기법의 지원이 메트릭에 대한 필요를 대신한다. 잔존 결함수 같은 다른 메트릭들이 여전히 유용할 수 있다. 이 메트릭이 예방 프로세스의 효과성에 대한 정보를 제공하기 때문이다. 관례적인 메트릭 활동들 넘어서 가치를 제공할 수 있는 것이라면 어떤 것에도 관심을 가져야 한다.

If people have trouble deciding what the most important work for the next week is, I usually suggest as a metric: “The size of the smile on the face of the customer”. If one solution does not get a smile on his face, another solution does cause a smile and a third solution is expected to put a big smile on his face, which solution shall we choose? This proves to be an important Evo metric that helps the team to focus.
만일 사람들이 차주에 해야 할 가장 중요한 것을 결정하지 못한다면, 나는 대개 "고객의 얼굴에서 보이는 웃음의 크기"라는 메트릭을 추천한다. 한 솔루션이 그의 얼굴에 미소를 주지못한다면, 또 다른 솔루션이 웃움을 줄 수 있고, 세 번째 솔루션에서 함박웃음을 기대할 수 있다. 어떤 솔루션을 선택해야 하나? 이것은 그 팀이 집중해야 하는 중요한 Evo 메트릭으로 판명된다.

18. Finally
18. 맺으며

Many software organizations in the world are working the same way, producing defects and then trying to find and fix the defects found, waiting for the customer to experience the reminder. In some cases, the service organization is the profit-generator of the company. And isn’t the testing department assuring the quality of our products?
전 세계의 많은 소프트웨어 조직들이 같은 방식으로 일하고, 같은 방식으로 결함을 만들어 내며, 고객들이 문제를 경험하는 것을 기다리며 발견된 결함을 찾고 수정한다. 어떤 경우에는 서비스 조직이 회사의 이익창출 집단인 경우가 있다. 그리고 테스팅 부서가 제품의 품질을 보증하지 않는가?

That’s what the car and electronics manufacturers thought until the Japanese products proved them wrong. So, eventually the question will be: can we afford it?
이것은 일본산 제품들이 그들의 제품이 잘못되었다고 증명해 주기 전까지 느끼는 차량이나 전자업체들의 생각과 같다. 따라서, 최종적인 질문은 다음과 같을 것이다. 우리가 그것을 감당할 수 있는가?

Moore’s Law is still valid, implying that the complexity of our systems is growing exponentially, and the capacity needed to fill these systems with meaningful software is growing exponentially even faster with it. So, why not better become more productive by not injecting the vast majority of defects. Then we have more time to spend on more challenging activities than finding and fixing defects.
무어의 법칙은 여전히 유효하다. 이것은 우리 시스템의 복잡도가 기하급수적으로 늘어남을 암시한다. 그리고, 의미있는 소프트웨어를 가지고 이러한 시스템들을 충당하는데 필요한 역량은 빠르게 커지고 있다. 따라서, 결함들을 집어넣지 않음으로써 더욱 생산적이 되는 것이 좋을 것이다. 따라서, 우리는 결함을 발견하고 수정하는 것보다 더욱 도전적인 일에 더 많은 시간을 써야 한다.

I absolutely don’t want to imply that finding and fixing is not challenging. Prevention is just cheaper. And, testers, fear not: even if we start aiming at defect free software, we’ll still have to learn a lot from the mistakes we’ll still be making.
나는 결코 결함의 발견과 수정이 도전적인 일이 아니라고는 생각하지 않는다. 단지 예방이 더 값쌀 뿐이다. 그리고 테스터들은 결함 없는 소프트웨어를 목표로 하는 것에 두려움을 가지지 말아라. 우리는 여전히 우리가 저지르고 있는 실수들에서 많은 것을 배울 것이다.

Dijkstra [8] said:
It is a usual technique to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. Where we first pursued the very effective way to show the presence of bugs, testing will now have to find a solution for the hopeless inadequacy of showing their absence.

다익스트라의 [8] 코멘트:
이것은 프로그램을 만들고, 테스트하는 일상적인 기법이다. 프로그램 테스팅은 버그의 존재를 보여주는 가장 좋은 방법이다. 하지만, 안타깝게도 그것의 부재를 보여주기에는 적합하지 않다. 우리가 먼저 버그의 존재를 가장 효과적으로 보일 수 있는 방법을 추구할 때, 버그의 부재를 가장 효과적으로 보여주기 위해 가장 먼저 해야될 것은, 테스팅이 버그의 존재를 보여주려고 시도했으나 실패했다고 보여줄 방법을 찾는 것이다.

Where we first pursued the very effective way to show the presence of bugs, testing will now have to find a solution for the hopeless inadequacy of showing their absence. That is a challenge as well.
버그의 존재를 보여주기 위해 가장 효과적인 방법을 추구할 때, 테스팅은 그 존재를 증명하는데 실패했다고 보여줄 방법을 찾는 것이 된다. 이것 또한 도전과제이다.

I invite testers from now on to change their focus from finding defects, to working with the developers to minimize the generation of defects in order to satisfy the real goal of software development projects. Experience in many projects shows that this is not an utopia, but that it can readily be achieved, using the Evo techniques described.
나는 지금부터 테스터들에게 그들의 관심을 결함을 찾는 것에서, 소프트웨어의 진정한 목표를 만족하기위해 결함의 생성을 최소화하여 개발자와 함께 작업하는 것으로 바꾸고자 한다. 많은 프로젝트에서의 나의 경험으로 볼 때 이것은 유토피아가 아니다. 오히려, 앞에서 언급한 Evo 기법을 사용할 때 즉시 달성할 수 있다.

References

[ 1] The Standish Group: Chaos Report, 1994, 1996, 1998, 2000, 2002, 2004.
www.standishgroup.com/chaos/intro1.php

[ 2] N.R. Malotaux: How Quality is Assured by Evolutionary Methods, 2004.
PNSQC 2004 Proceedings. Also downloadable as a booklet:
www.malotaux.nl/nrm/pdf/Booklet2.pdf

[ 3] N.R. Malotaux: Evolutionary Project Management Methods, 2001.
www.malotaux.nl/nrm/pdf/MxEvo.pdf

[ 4] T. Gilb: Principles of Software Engineering Management, 1988.
Addison-Wesley Pub Co, ISBN: 0201192462.

[ 5] See cases: www.malotaux.nl/nrm/Evo/EvoFCases.htm

[ 6] P.B. Crosby: Quality Without Tears, 1984.
McGraw-Hill, ISBN 0070145113.

[ 7] W.E. Deming: Out of the Crisis, 1986. MIT, ISBN 0911379010.
M. Walton: Deming Management At Work, 1990. The Berkley Publishing Group, ISBN
0399516859.

[ 8] E. Dijkstra: Lecture: The Humble Programmer, 1972.
Reprint in Classics in Software Engineering. Yourdon Press, 1979, ISBN 0917072146.

[ 9] TaskCycle ref [2] chapter 5.1 ref [3] chapter 3C

[10] DeliveryCycle ref [2] chapter 5.1 ref [3] chapter 3C

[11] TimeLine ref [2] chapter 5.5 and 6.8

[12] Product ref [2] chapter 4.2

[13] Project ref [2] chapter 4.3

[14] Process ref [2] chapter 4.4

[15] 3-step procedure ref [2] chapter 6.9

[16] Unplannable time ref [2] chapter 6.1

[17] Interrupt procedure ref [2] chapter 6.7

[18] Analysis task ref [2] chapter 6.6 ref [3] chapter 8

[19] Candidate Task List ref [2] chapter 6.5 ref [3] chapter 8

[20] TimeBox ref [2] chapter 6.4 ref [3] chapter 3D

Fin.