Test Patterns By Michael Bolton

JUNE 2006 BETTER SOFTWARE, pp.14 ~ 15에 실린 Test Patterns By Michael Bolton을 번역해 보았다. 원문은 여기에.

Summary: Building on his earlier columns covering James Bach's Heuristic Test Strategy Model, Michael Bolton delivers nine techniques--each of which affords a different way of modeling the product--to help you test your systems for a greater variety of bugs.
In this series, I've focused on the parts of James Bach's Heuristic Test Strategy Model (HTSM) that help us generate test ideas. For the next several columns, I'll discuss how to exercise these ideas using test techniques.
 
A test technique is a general pattern describing what we do when we test. We start by modeling the test space. We then determine coverage, oracles, and activities. We configure, operate, and observe the system under test, and finally we evaluate the result. Sometimes these tasks happen so quickly and intuitively that we don't even notice we're performing them.
 
테스트 기법은 우리가 테스트 할 때 무엇을 수행해야 하는지에 대해 기술한 일반적인 패턴이다. 우리는 테스트 공간을 모델링함으로써 시작하게 된다. 그 다음 커버리지, 오라클, 활동들을 결정한다. 우리는 테스트 중인 시스템을 구성하고, 운용하고, 관찰한다. 그리고 결국에는 결과를 평가한다. 때로는 이러한 과업들이 매우 빨리 발생하고 직관적이기 때문에 우리가 수행하고 있는 것을 알아차리지 못하기도 한다.

In this column I'll summarize the HTSM's nine categories of techniques for testing systems. Notice the term "systems" rather than "programs." The former, more general term allows flexibility in modeling what we have to test, from a single line of code to a functional module, an application, or a suite of interacting applications and the platforms on which they work. The scope of the effort affects the techniques we choose and the ways in which we use them.
 
이 컬럼에서 나는 시스템을 테스팅하는데 사용되는 아홉가지 카테고리의 HTSM 기법을 요약하겠다. "프로그램"이란 말보다 "시스템"이란 용어를 사용했음을 주의하라. 전자는 우리가 테스트 해야하는 것을 모델링하는데 유연성을 허용하는 좀 더 일반적인 용어로, 단일 코드부터 기능 모듈이나 어플리케이션까지 또는 상호작용하는 어플리케이션의 집합이나 그들이 동작하는 플랫폼까지를 망라한다. 활동의 범위는 우리가 선택하는 테크닉과 시스템을 사용하는 방법에 영향을 미친다.
 
Function testing involves identifying each function and then testing it independently. A function causes the system under test to exercise some behavior, either changing or maintaining the system's state. The object is to ensure that each function does what it should, but also that it doesn't do what it shouldn't. For each function, we need a reliable oracle-a principle or mechanism that will allow us to recognize a problem.
 
기능 테스팅은 각각의 기능을 확인하고 독립적으로 그것을 테스팅하는 것을 말한다. 기능은 테스트 중인 시스템에 어떤 동작을 유발시키는 것으로, 시스템의 상태를 변경하거나 유지하기도 한다. 목적은 각 기능이 그것이 해야한 것을 하는지, 하지 않아야 하는 것을 하지 않는지에 대해 확신하는 것이다. 우리는 각각의 기능에 대해서 믿을 수 있는 오라클을 필요로 한다. (오라클: 우리가 문제를 인식할 수 있도록 해주는 원칙이나 메커니즘)
 
Function testing is good for identifying the capabilities of a system, but the technique has weaknesses, too. First, unless we choose our models carefully, the number of functions in a system could be intractably large. To be effective, we need to make pragmatic choices about the scale of our functional tests. Second, function tests are intended to test each function in isolation, but some of the riskiest areas of any system are in the interactions between functions. Third, some defects may depend upon exercising a function more than once.
 
기능 테스팅은 시스템의 가용성을 확인하는데도 좋은 방법이다. 하지만, 기능 테스팅 기법은 약점이 있다. 첫째로, 우리가 신중하게 모델을 선택하지 않는다면, 시스템 내의 기능들의 수가 다루기 어렵게 거대해질 것이다. 효과적으로 다루려면, 우리의 기능적인 테스트에 대해서 실용적인 선택을 할 필요가 있다. 둘째로, 기능 테스트는 각각의 기능을 고립적으로 테스트 하는 의도가 있다. 하지만, 어떤 시스템의 몇몇 가장 위험한 영역들은 기능들 간에 상호작용을 한다. 세째로, 몇몇 결점들은 한 번 이상 기능을 구동해야지만 발견될 수 있다.
 
Domain testing focuses on clarifying and simplifying the testing effort by classifying things associated with the system. Identifying equivalence classes-groups of things that we deem interchangeable for the purposes of a given test-is the key task in domain testing. Practically anything to do with the system-input and output data, platforms, peripherals, users, functions-can be classified by some criterion. Good domain testing involves selecting items from the identified classes such that we cover the territory (e.g., normal data values vs. exceptional data values, representative platforms vs. unusual platforms, or expert users vs. novice users). If we observe clear divisions between classes in defined ranges, such as elements on a number line, we might test at the boundaries between them, where some theories of error suggest that mistakes are most likely to occur and easiest to detect. Boundary analysis-a subset of domain testing-may reduce the number of tests we believe we need, but some classifications don't have clear linear boundaries. To do domain testing well, we must develop skill at dividing and conquering the data and at identifying risk.
 
도메인 테스팅은 시스템과 관련이 있는 것들을 분류함으로써 테스팅 활동을 단순화하고 명확히 하는데 집중하는 것이다. 동치분할 영역(테스트를 위해서 상호 변경할 수 있다고 생각되는 그룹들)을 확인하는 것이 도메인 테스팅에서의 핵심 작업이다. 실제로는 시스템과 함께 무언가를 하는 것들 (입력과 출력 데이터, 플랫폼, 주변장치, 유저, 기능 등)을 어떤 기준에 의해 분류할 수 있다. 훌륭한 도메인 테스팅은 영역을 커버하는 확인된 클래스들로부터 아이템들을 선택하는 것이다. (예를 들면, 노말 데이터 값들 대 예외적인 데이터 값들, 대표적인 플랫폼들 대 특정한 플랫폼들 또는 기대 유저들 대 초심자 유저들) 우리가 정의된 영역 내에서 클래스들 간의 명확한 구역을 관찰할 수 있다면(예를 들면, 숫자 라인으로 구별되는 요소들 처럼), 우리는 그들 간의 경계를 테스트 할 수 있을 것이다. (경계는 몇몇 에러 이론에서 결점을 찾기도 쉽고 결점도 자주 발견되는 곳으로 추천된다.) 경계 분석(도메인 테스팅의 하위 세트인)은 우리가 필요로 하다고 생각하는 테스트의 수를 줄일 수 있게 한다. 하지만, 어떤 분류들은 명확한 직선적 경계들을 가지지 않는다. 도메인 테스팅을 잘 하기 위해서는 데이터를 분할 정복하고 위험을 파악해내는 기술을 개발할 필요가 있다.
 
Stress testing is the process of overfeeding or starving the system, or both. This includes overwhelming the system with input, tasks, or users, or removing resources like memory, disk space, network bandwidth, or connectivity. The system under test can be anything from a single input field to the entire business process. We use stress testing to better understand the capacities and limitations of the system, looking for bottlenecks, constraints, and dependencies. The goal is to fix intolerable weaknesses in the program and prepare for and mitigate the tolerable weaknesses.
 
스트레스 테스팅은 시스템에 과도한 데이터를 입력하거나 아예 데이터 입력을 없게하거나 또는 둘 다를 하는 프로세스이다. 이것은 시스템에 입력, 작업 또는 유저를 과도하게 주입하거나 메모리, 디스크 공간, 네트워크 대역폭 같은 리소스를 없애거나, 접속성을 과도하게 하는 것이다. 테스트 중인 시스템은 단일 입력 필드이거나 전체 비즈니스 프로세스 이거나 어떤 것도 될 수 있다. 우리는 시스템의 제약이나 용량, 병목지점 파악, 의존성 등을 잘 파악하기 위해서 스트레스 테스팅을 사용한다. 최종 목적은 프로그램 내의 견디지 못하는 약점을 개선하고 견딜만한 약점은 완화시키도록 하는 것이다.
 
Flow testing involves running the system without halting or resetting it. When designing a system, we typically simplify by describing single transactions or events in isolation from each other. Flow testing introduces the system to a more realistic, complex world, where transactions happen in sequence, concurrently, or with interruptions. Good flow testing doesn't decompose the system as function testing does, or undermine it as stress testing does. Instead flow tests model realistic system operation, ensuring that things are done correctly and in the right order.
 
흐름 테스팅은 정지와 재구성 없이 시스템을 동작시키는 것과 연관이 있다. 시스템을 디자인 할때, 일반적으로 우리는 단일 트랜잭션 또는 서로 다른 곳과는 고립된 이벤트를 기술함으로써 단순화 한다. 흐름 테스팅은 시스템을 좀 더 현실적이고, 복잡한 세상인 트랜잭션이 연속적으로, 동시에 방해를 받으면서 발생하는 것으로 취급한다. 훌륭한 흐름 테스팅은 기능 테스팅이 하듯이 시스템을 분해하지 않으며, 스트레스 테스팅이 하듯이 서서히 문제가 되도록 하는 것이다. 흐름 테스트 대신에 모델 실제적인 시스템 운용은 작업들이 올바르게, 올바른 순서로 이루어졌음을 보증한다.

With scenario testing, we test to a compelling story about the system and its users. Powerful scenarios motivate interest and empathy. Scenario tests include use cases; user stories; the birth, life, and death of a piece of data within the system; and soap opera tests, which posit highly improbable but possible scenarios. Scenario testing tends to find more business-facing bugs than developer-facing bugs.
 
시나리오 테스팅을 사용하면, 우리는 시스템과 유저에 대한 감동적인 스토리를 테스트하게 된다. 강력한 시나리오는 흥미와 감정이입을 유발시킨다. 시나리오 테스트는 유스 케이스, 유저 스토리, 시스템 내부의 데이터 조각의 생성, 활동, 죽음을 다루며, 가능한 시나리오기는 하나 거의 발생할 가능성이 없는 '소프 오페라 테스트' 이다. 시나리오 테스팅은 개발측면의 버그보다는 비즈니스측면의 버그를 더 찾아내는 경향이 있다.
 
(* 역자주: 'soap opera'란 인간관계에서의 문제거리나 감정들을 다룬 라디오 또는 TV의 연속극입니다. Soap이란 단어가 붙게 된 것은 이 연속극의 후원자가 비누제조회사들이었기 때문입니다. 뮤지컬 오페라와 마찬가지로 soap opera도 실제 인물에 관한 것이 아닙니다. 그래서 비평가들은 soap opera가 현실세계를 올바르게 보여주지 못한다고 비난했습니다.)
 
In claims testing, we seek what anyone (a requirements author or marketer) or anything (a help file or a shrink-wrapped box) says about the system, and we test that claim's validity. Requirements documents and specifications are the most obvious sources, but we can also test claims made in emails and conversations, sales and marketing materials, end-user documentation, and tutorials. Some claims might be inaccurate, but if we identify where the claim and the system are inconsistent, the project team can fix one or the other.
 
클레임 테스팅에서 우리는 누군가 (요구사항 작성자나 마케터) 또는 어떤 것 (도움말 파일 또는 박스 포장 내용)이 시스템에 대해 설명하는 것을 찾으며, 그 주장의 정당성을 테스트 한다. 요구사항 문서나 명세는 가장 확실한 소스이지만, 이메일이나 대화 과정, 마케팅 자료, 최종 사용자 문서, 튜토리얼로 부터 만들어진 주장들도 테스트해야 한다. 어떤 주장들은 부정확할 수 있지만, 우리가 어느 부분의 주장인지 밝혀내고, 시스템이 불일치한다면, 프로젝트 팀은 그것들을 고칠 수 있게 된다.
 
User testing tells us to test with real users or real-user models. A user, in Rapid Testing parlance, is anyone who might use the system or have an interest in the test effort. I regularly run an exercise in which Rapid Testers try to identify all of the project's user roles; we don't stop until we reach thirty. We tend to focus our modeling on end-users (or their managers or customers), but we might also perform tests to serve the interests of the help desk, training staff, or chief financial officer. We'll also perform some security testing because black hat hackers are potential users (or abusers) of the system.
 
유저 테스팅은 실제 유저나 실제 유저 모델을 가지고 테스트 해야 함을 알려준다. 래피드 테스팅 용어에서 유저는 시스템을 사용하거나 테스팅 활동에 관심을 가진 사람을 말한다. 나는 정기적으로 프로젝트의 모든 유저의 역할을 확인해 내려는 래피드 테스터로서 행동을 한다. 우리는 30가지 역할을 수행할 때까지 계속 수행한다. 우리는 최종 사용자(또는 그들의 관리자나 고객)에 근거한 모델에 집중하는 경향이 있다. 하지만, 마찬가지로 헬프 테스트, 훈련 스탭, CFO 등의 관심을 지원하도록 테스트를 수행해야 한다. 또한 악의적인 해커들도 시스템의 사용자(또는 어뷰저)가 될 수 있기 때문에 보안성 테스팅도 수행해야 한다.
 
Risk-based testing posits the harm that could come to some person if a threat were to expose some vulnerability in the system; we recognize or imagine a risk and perform tests to reveal it. I've found three useful ways to generate risk-based test ideas:
 
위험 기반 테스팅은 위협요소가 시스템의  어떤 취약점을 드러내는 경우 어떤 사람에게 위해가 가해질 수 있다고 가정한다. 우리는 위험, 성능 테스트가 그것을 드러내 줄것으로 기대한다. 나는 아래와 같은 위험 기반 테스트 아이디어를 만들어 내는 유용한 방법을 찾아냈다.

" Consider something that could go wrong, such as a programming error or an ambiguous requirement.
" Contemplate the consequences of something going wrong, such as a phone call to the help desk or a front-page story in the San Jose Mercury News.
" Determine what the development organization is prepared to risk (e.g., "A bug fix this late might have undesirable side effects; we'll risk leaving it in").
 
" 어떤 것이 잘못될 것이라고 가정하라. 예를 들면, 프로그래밍 에러나 모호한 요구사항 등이다.
" 무언가가 잘못되진 결과를 심사숙고하라. 예를 들면, 헬프 데스크로 전화가 오거나 산호세 머큐리 뉴스에 첫면을 장식하는 것 등이다.
" 개발 조직이 위험에 어떤 대비를 할 것인지 결정하라. (예를 들면, "이 버그 수정을 이후로 미루면 바람직하지 않은 부작용이 일어날 것이다. 하지만, 우리는 위험을 안고 가겠다.")

Automatic testing allows us to run a test zillions of times or in a zillion variations. The principal virtues of automatic testing are speed, precision, and repetition. However, test automation is software development, which can be tricky and expensive. We should balance the cost of repetition with the value of the problems it finds. Some tests we run repeatedly; others aren't even worth running twice.
 
자동화 테스팅은 수천억 시간과 수천억개의 변이들을 테스트할 수 있게 한다. 자동화 테스팅의 주요한 미덕은 속도와, 정확성, 그리고 반복성이다. 하지만, 소프트웨어 개발에서의 테스트 자동화는 다루기 어려우며, 비용이 많이 든다. 우리는 자동화가 발견해 내는 문제의 가치와 반복에 드는 비용 간의 균형을 맞춰야 한다. 어떤 테스트들은 반복적으로 수행해야 하지만, 어떤 테스트들은 두 번 이상 수행할 필요가 없다.

The boundaries between techniques are sometimes blurry, and our definitions are somewhat open. When the name of a given technique suggests multiple interpretations, Rapid Testers try to use as many interpretations as possible to create more diverse tests.
 
기법들간의 경계가 종종 모호하고, 우리의 정의들은 다소 불분명하다. 위에 언급된 기법들의 이름이 다양한 의미로 해석이 될 때, 래피드 테스터들은 더 많은 다양한 테스트를 생성하기 위해 가능한 한 많은 차용을 시도한다.
 
I've noted in previous columns that coverage is the extent to which we've tested the system according to our mental models. Each test technique in the HTSM affords us a different way of modeling the product. Each technique is a heuristic-a fallible method for solving testing problems. No single technique can reveal all of the information that we seek about a system, but a variety of techniques will reveal more bugs-and more varieties of bugs. {end}
 
내가 이전 컬럼에서도 언급했지만, 적용 범위는 우리가 이전에 테스트 했던 시스템과 관련된 사고 모델까지이다. HTSM 내의 각각의 테스트 기법은 제품을 모델링하는 서로 다른 방식을 제공해 준다. 각 기법은 자가 발견적이며, 테스팅 문제를 해결하는데 잘못 사용되기 쉬운 방법이다. 어떤 단일 기법도 시스템에 대해 우리가 찾으려고 하는 정보 모두를 드러나게 하지 않는다. 하지만, 다양한 기법은 더 많은 버그와 더 다양한 버그를 발견하게 해준다. {끝}

About the Author
Michael Bolton lives in Toronto and teaches heuristics and exploratory testing in Canada, the United States, and other countries as part of James Bach's Rapid Software Testing course. Michael is also program chair for the Toronto Association of System and Software Quality. He is a regular contributor to Better Software magazine. Contact Michael at mb@developsense.com.

(* 역자주: mental model: 사고 체계, 사고 모델, 사고 모델이란 우리가 세상을 바라보고 이해하는 방식을 말한다. 이는 좋거나 나쁜 것이 아니며, 우리 뇌가 정보를 처리하는 익숙한 방식일 뿐이다. 하지만 문제는 이미 세상이 바뀌었는데도 사고 모델은 옛날 그대로이며, 따라서 개인이나 조직의 성장을 자주 방해한다는 것이다.)