ソフトウェアテスト界隈で探索的テストがビッグウェーブのようなので、便乗して過去の資産をリサイクルします！（ぬけぬけ）
5年ほど前、「探索的テスト研究会」というチームで活動していたときに読んだ、『Exploratory Testing 3.0』という記事の翻訳です。
当時の翻訳のブラッシュアップ版ではなく、再利用です。
探索的テスト3.0
- 元記事: Exploratory Testing 3.0（2015年3月18日時点）
- 原著者: James Bach氏、Michel Bolton氏
- 翻訳者: Kazu SUZUKI @kz_suzuki
- 作成日: 2015年3月15日
- 最終更新日: 2015年8月30日
- 状態: 翻訳中
- 備考:
- 翻訳を完成させることを優先しているため、精度が犠牲になっています（言い訳）。誤訳などのご指摘は歓迎します。赤字が怪しいです！
- この翻訳では、exploratory testingを「探索的テスト」、scripted testingを、「手順付きテスト」と訳しています。JSTQBの用語集では後者を「スクリプトテスト」としていますが、「スクリプト」と書くと、プログラミングされたテストスクリプトを連想しがちのため、あえてこの訳としました。
March 16, 2015
By James Bach and Michael Bolton
2015年3月16日
James BackとMichael Boltonによる
In the beginning, there was testing. No one distinguished between exploratory and scripted testing. Jerry Weinberg’s 1961 chapter about testing in his book, Computer Programming Fundamentals, depicted testing as inherently exploratory and expressed caution about formalizing it. He wrote, “It is, of course, difficult to have the machine check how well the program matches the intent of the programmer without giving a great deal of information about that intent. If we had some simple way of presenting that kind of information to the machine for checking, we might just as well have the machine do the coding. Let us not forget that complex logical operations occur through a combination of simple instructions executed by the computer and not by the computer logically deducing or inferring what is desired.”
はじめに、テスティングがあった。探索的テストと手順付きテストを区別できる者はいなかった。
1961年のJerry Weinbergの書籍『Computer Programming Fundamentals』のテスティングに関する章では、テスティングを、本来探索的なものであると表現し、それを形式化することに警告を与えた。
「当然のことながら、プログラマの”意図”について膨大な情報を与えることなく、プログラムがその”意図”にどれほど合致しているかを機械にチェックさせることは難しい。チェックを行う機械に与えるその種の情報を簡易に表現する方法があるのなら、同じようにその機械にコーディングさせることもできるだろう。複雑な論理操作が発生してしまうのは、コンピュータが実行する単純な命令を組み合わせるからであり、「何が望ましいか」をコンピュータが論理的に演繹・推論するためではない、ということを忘れないでおこう」。
Jerry understood the division between human work and machine work. But, then the formalizers came and confused everyone. The formalizers—starting officially in 1972 with the publication of the first testing book, Program Test Methods—focused on the forms of testing, rather than its essences. By forms, we mean words, pictures, strings of bits, data files, tables, flowcharts and other explicit forms of modeling. These are things that we can see, read, point to, move from place to place, count, store, retrieve, etc. It is tempting to look at these artifacts and say “Lo! There be testing!” But testing is not in any artifact. Testing, at the intersection of human thought processes and activities, makes use of artifacts. Artifacts of testing without the humans are like state of the art medical clinics without doctors or nurses: at best nearly useless, at worst, a danger to the innocents who try to make use of them.
Jerryは、人間の仕事と機械の仕事の区分を理解していた。しかし、「形式屋」がやってきて、すべてに混乱をもたらした。
形式屋―――公式には1972年に出版されたテスティングに関する最初の書籍『Program Test Methods』から始まった―――は、テスティングの本質ではなく、形式にフォーカスしていた。「形式」というのはここで、文書、写真、ビット文字列、データファイル、テーブル、フローチャート他、モデリングの明示的な形のことを指している。これらはわたしたちが見たり、読んだり、指示したり、移動したり、数えたり、格納したり、検索したりができるものである。
こういった成果物（artifacts）を見て、「ほら！ これがテスティングだ！」と言いたいという誘惑はあるが、テスティングというのは成果物の中にあるわけではない。テスティングは、人間の思考プロセスと行動の交差点において、成果物を利用するものだ。人間不在のテスティングの成果物など、医者も看護師も置き去りにした医療技術のようなものだ。役に立たないだけならまだいいが、悪いことに、成果物を利用しようとしている初学者にとっては危険なものなのだ。
We don’t blame the innovators. At that time, they were dealing with shiny new conjectures. The sky was their oyster! But formalization and mechanization soon escaped the lab. Reckless talk about “test factories” and poorly designed IEEE standards followed. Soon all “respectable” talk about testing was script-oriented. Informal testing was equated to unprofessional testing. The role of thinking, feeling, communicating humans became displaced.
彼らイノベーターを責めるつもりはない。当時においては、新しく輝かしい考え方を扱っていたのだ。世界は彼らの思うままだった！
しかし、形式化・機械化はすぐに研究所から飛び出してきた。「テスト工場」という無謀な話題と、ろくに設計されていないIEEEの標準がそれに続いた。間もなく、「立派な」テスティングの話題とはすべて、手順志向のものであることになった。非形式的なテスティングはプロフェッショナルらしからぬものと見なされた。考えること、感じること、人間とコミュニケーションすることの役割は、置き去りにされてしまったのだ。
James joined the fray in 1987 and tried to make sense of all this. He discovered, just by watching testing in progress, that “ad hoc” testing worked well for finding bugs and highly scripted testing did not. (Note: We don’t mean to make this discovery sound easy. It wasn’t. We do mean to say that the non-obvious truths about testing are in evidence all around us, when we put aside folklore and look carefully at how people work each day.) He began writing and speaking about his experiences. A few years into his work as a test manager, mostly while testing compilers and other developer tools, he discovered that Cem Kaner had coined a term—”exploratory testing”—to represent the opposite of scripted testing. In that original passage, just a few pages long, Cem didn’t define the term and barely described it, but he was the first to talk directly about designing tests while performing them.
これらの役割を知らしめるため、Jamesは1987年に論争に加わった。テスティングの進行を観察することによって、「アドホックな」テスティングが役に立ち、しっかり手順を書くテスティングでは見つけられないようなバグを見つられることに気づいた（注意：この気づきが簡単だったと思ってほしくない。簡単ではない。よくわからず信じられているものを脇にやり、人間が毎日どのように働いているかを注意深く観察することで、テスティングに関して当たり前ではなかった真実が明らかになると言いたいのだ）。
彼は自分の経験について書き、話すようになった。テストマネージャとしての数年間、主にコンパイラやその他の開発者向けツールをテストする過程で、手順付きテストの反対のものを示すためにCem Kanerが「探索的テスト」という言葉を創り出していることがわかった。元々の文章は数節程度の長さでしかなく、Cemはその言葉を定義していなかったし、説明もわずかであったが、テストを実行しながら設計するということについて直接的に述べた最初の人間であった。
Thus emerged what we, here, call ET 1.0.
こうして、「探索的テスト1.0」（ET 1.0）が生まれた。
(See The History of Definitions of ET for a chronological guide to our terminology.)
（わたしたちの言葉の用法の時系列的ガイドとして、「ETの定義の歴史」を参照のこと）
ET 1.0: Rebellion
ET 1.0：反乱
Testing with and without a script are different experiences. At first, we were mostly drawn to the quality of ideas that emerged from unscripted testing. When we did ET, we found more bugs and better bugs. It just felt like better testing. We hadn’t yet discovered why this was so. Thus, the first iteration of exploratory testing (ET) as rhetoric and theory focused on escaping the straitjacket of the script and making space for that “better testing”. We were facing the attitude that “Ad hoc testing is uncontrolled and unmanageable; something you shouldn’t do.” We were pushing against that idea, and in that context ET was a special activity. So, the crusaders for ET treated it as a technique and advocated using that technique. “Put aside your scripts and look at the product! Interact with it! Find bugs!”
手順付きでテストすることと、手順なしでテストすることは、まったく別の経験である。わたしたちは最初、手順なしでのテスティングから生まれたアイデアの特性に、強く惹きつけられた。ETで見つけられるバグはより多く、より良いものであり、より良いテストを行っていると感じられた。しかしその理由はまだわかっていなかった。このように、レトリック・理論としての探索的テスト（ET）の最初のイテレーションでは、手順の拘束から逃れ、「より良いテスティング」のための余地を設けることにフォーカスした。
わたしたちは、「アドホックテストは制御も管理もできないもの、避けるべきものである」という態度に直面していた。わたしたちはその考えに対抗していた。そのコンテキストにおいて、ETは特別なアクティビティであった。だからETの十字軍は、ETを技法として扱い、その技法を使うよう提唱していたのだ。「手順を脇によけて、プロダクトを見よう！ 交流しよう！ バグを見つけよう！」
Most of the world still thinks of ET in this way: as a technique and a distinct activity. But we were wrong about characterizing it that way. Doing so, we now realize, marginalizes and misrepresents it. It was okay as a start, but thinking that way leads to a dead end. Many people today, even people who have written books about ET, seem to be happy with that view.
世間の大部分が未だにETを、一つの技法、一つの個別のアクティビティであると捉えている。しかしそのように特徴づけることは間違いであった。今ならわかるが、それではETを軽んじることになり、正しく説明できてもいない。最初のうちはそれでもいいが、そのように考えていては行き詰ってしまう。多くの人、ETについての本を書いている人ですら、今でもそのような捉え方に満足しているようだ。
This era of ET 1.0 began to fade in 1995. At that time, there were just a handful of people in the industry actively trying to develop exploratory testing into a discipline, despite the fact that all testers unconsciously or informally pursued it, and always have. For these few people, it was not enough to leave ET in the darkness.
ET 1.0の自体は、1995年に終息し始めた。あらゆるテスターが無意識に、あるいは非公式に探索的テストを行っていたにも関わらず、そのころ探索的テストを一つの規律として積極的に発展させようとしている者は、業界でも数えるほどしかいなかった。そのわずかな人々は、ETを日の当たらないところに放っておきはしなかった。
ET 1.5: Explication
ET 1.5：詳細化
Through the late ‘90s, a small community of testers beginning in North America (who eventually grew into the worldwide Context-Driven community, with some jumping over into the Agile testing community) was also struggling with understanding the skills and thought processes that constitute testing work in general. To do that, they pursued two major threads of investigation. One was Jerry Weinberg’s humanist approach to software engineering, combining systems thinking with family psychology. The other was Cem Kaner’s advocacy of cognitive science and Popperian critical rationalism. This work would soon cause us to refactor our notions of scripted and exploratory testing. Why? Because our understanding of the deep structures of testing itself was evolving fast.
1990年代後半を通して、北米のテスターの小さなコミュニティ（アジャイルテスティングのコミュニティから、最終的には、世界規模のコンテキスト駆動のコミュニティに発展する）は、テスティングの作業を構成する一般的なスキルと思考プロセスを理解しようとやっきになっていた。そのためには、二種類の大きな研究を遂行する必要があった。一つは、Jerry Weinbergによる、ソフトウェア工学への人間学的アプローチで、システム思考と家族心理学を結びつけるものであった。もう一つは、Cem Kanerの提唱した認知心理学と、Karl Popperの批判的合理主義であった。
この研究によってわたしたちはすぐに、手順付きのテストと探索的テストに関する概念を再構築することになるはずだった。なぜか。テスティング自体の深い構造に対するわたしたちの理解は、急速に進んでいたからである。
When James joined ST Labs in 1995, he was for the first time fully engaged in developing a vision and methodology for software testing. This was when he and Cem began their fifteen-year collaboration. This was when Rapid Software Testing methodology first formed. One of the first big innovations on that path was the introduction of guideword heuristics as one practical way of joining real-time tester thinking with a comprehensive underlying model of the testing process. Lists of test techniques or documentation templates had been around for a long time, but as we developed vocabulary and cognitive models for skilled software testing in general, we started to see exploratory testing in a new light. We began to compare and contrast the important structures of scripted and exploratory testing and the relationships between them, instead of seeing them as activities that merely felt different.
Jamesが1995年にSTラボに加わったとき、彼は初めて本格的に、ソフトウェアテスティングのビジョンと方法論の開発に従事することになった。これは、JamesとCemの15年に及ぶ協働の始まりでもあった。ラピッドソフトウェアテスティングが初めて作られた時期ともいえる。
このことによってもたらされた最初の大きなイノベーションは、テスティングプロセスの基礎となる包括的なモデルを、リアルタイムテストを行うテスターに意識してもらうための一つの実用的な方法として、「ガイドワードヒューリスティックス」を導入したことである。テスト技法やドキュメントのテンプレートのリストはずっと周りにあったが、わたしたちが一般的に優れたソフトウェアテスティングのための語彙と認知モデルを開発するにつれて、探索的テストの新しい一面が見えるようになった。手順付きのテストと探索的テストを、単に別のアクティビティとみなすのではなく、両者の重要な構造やお互い関係を比較し始めたのだ。
In 1996, James created the first testing class called “Exploratory Testing.” He had been exposed to design patterns thinking and had tried to incorporate that into the class. He identified testing competencies.
1996年、Jamesは「探索的テスト」という名の最初のテスティングのクラスを作った。彼はデザインパターン思考に触れ、クラスにもそれを取り入れようとしていた。テスティングの力というものを認識していたのだ。
Note: During this period, James distinguished between exploratory and ad hoc testing—a distinction we no longer make. ET is an ad hoc process, in the dictionary sense: ad hoc means “to this; to the purpose”. He was really trying to distinguish between skilled and unskilled testing, and today we know better ways to do that. We now recognize unskilled ad hoc testing as ET, just as unskilled cooking is cooking, and unskilled dancing is dancing. The value of the label “exploratory testing” is simply that it is more descriptive of an activity that is, among other things, ad hoc.
注意：この時期、Jamesは探索的テストとアドホックテストを区別していた。今となっては、わたしたちはその区別をしていない。辞書通りに捉えると、ETはアドホックなプロセスである。ad hocとは、「それに向かって、目的に向かって」という意味なのだから。
彼は実は、スキルの高いテスティングとそうでないテスティングを区別しようとしいていたのだ。今ならその方法がわかる。スキルの低いアドホックテストもETであると、今は考えている。下手な料理だって料理ではあるし、下手なダンスもダンスではあるのと同じだ。「探索的テスト」というラベルの価値は単に、他のものに比べてアドホックなアクティビティをわかりやすく表現できるということでしかない。
In 1999, James was commissioned to define a formalized process of ET for Microsoft. The idea of a “formal ad hoc process” seemed paradoxical, however, and this set up a conflict which would be resolved via a series of constructive debates between James and Cem. Those debates would lead to we here will call ET 2.0.
1999年、JamesはMicrosoftにおいて、ETの定型的なプロセスを定義するよう委託された。「定型的なアドホックプロセス」という考え方は矛盾をはらんでいるようにみえるし、衝突を生むことにもなったが、JamesとCemの間で交わされた一連の建設的な議論を通して解決されることになる。その議論が、「探索的テスト2.0」と今は呼んでいるものにつながっている。
There was also progress on making ET more friendly to project management. In 2000, inspired by the work for Microsoft, James and Jon Bach developed “Session-Based Test Management” for a group at Hewlett-Packard. In a sense this was a generalized form of the Microsoft process, with the goal of creating a higher level of accountability around informal exploratory work. SBTM was intended to help defend exploratory work from compulsive formalizers who were used to modeling testing in terms of test cases. In one sense, SBTM was quite successful in helping people to recognize that exploratory work was entirely manageable. SBTM helped to transform attitudes from “don’t do that” to “okay, blocks of ET time are things just like test cases are things.”
プロジェクトマネジメントにとって、ETがなじみのあるものにするという点でも進歩があった。Microsoftでの仕事に触発され、James BachとJon Bachが2000年に、Hewlett-Packardのために「セッションベーストテストマネジメント（SBTM）」を開発したのだ。これは、非公式な探索的作業に関する高度なアカウンタビリティを与えることを目標としており、ある意味で、Microsoftのプロセスを一般化したものである。
SBTMは、テスティングをテストケースという形でモデリングすることに慣れきった強迫神経症的な型式屋から、探索的作業を守る助けになることを意図していた。探索的作業が完全にマネジメント可能であることを人々が知る助けになったという点で、SBTMはまったくもって成功であった。SBTMは、「そんなことするな」という態度を、「ETを行う時間帯は、テストケースが有形のモノであるのと同様、ETを行う時間のブロックもまた、有形のモノである」という態度に変えるのに役立ったのだ。
By 2000, most of the testing world seemed to have heard something about exploratory testing. We were beginning to make the world safe for better testing.
2000年までに、テスティングの業界の大部分の人が、探索的テストについて何がしか聞いたことがあるようになっていたようだ。業界を、より良いテスティングにとって安全なところにし始めていたのだ。
ET 2.0: Integration
ET 2.0：統合
The era of ET 2.0 has been a long one, based on a key insight: the exploratory-scripted continuum. This is a sliding bar on which testing ranges from completely exploratory to completely scripted. All testing work falls somewhere on this scale. Having recognized this, we stopped speaking of exploratory testing as a technique, but rather as an approach that applies to techniques (or as Cem likes to say, a “style” of testing).
ET 2.0は長く続いた時代で、「探索的テストから手順付きテストへの連続体」という重要な洞察に基づいている。これは、「完全に探索的」から「完全に手順付き」までのテスティングの範囲を描いたスライドバーだ。あらゆるテスティング作業が、このものさしのどこかに乗る。これに気づいてから、わたしたちは探索的テストを技法として語ることを止め、技法に対して適用される一つのアプローチ（あるいはCemが好んでいうように、テスティングの「スタイル」）と語るようにした。
We could think of testing that way because, unlike ten years earlier, we now had a rich idea of the skills and elements of testing. It was no longer some “creative and mystical” act that some people are born knowing how to do “intuitively”. We saw testing as involving specific structures, models, and cognitive processes other than exploring, so we felt we could separate exploring from testing in a useful way. Much of what we had called exploratory testing in the early 90’s we now began to call “freestyle exploratory testing.”
テスティングをこのように捉えることができたのは、その前の10年間と違って、テスティングのスキルと要素についてたくさんの考え方を手にしていたからである。テスティングはもはや、一部の人々だけが生まれつきやり方を本能的に知っている、クリエイティブで神秘的な活動ではなかった。
わたしたちはテスティングを、探索以外の特定の構造、モデル、認知プロセスを含むものと見なしていたので、テスティングと探索をうまく分けられると考えた。この90年代前半に「探索的テスト」と呼んでいたものの多くは、現在では「フリースタイル探索的テスト」と呼び始めているものである。
By 2006, we settled into a simple definition of ET, simultaneous learning, test design, and test execution. To help push the field forward, James and Cem convened a meeting called the Exploratory Testing Research Summit in January 2006. (The participants were James Bach, Jonathan Bach, Scott Barber, Michael Bolton, Elisabeth Hendrickson, Cem Kaner, Mike Kelly, Jonathan Kohl, James Lyndsay, and Rob Sabourin.) As we prepared for that, we made a disturbing discovery: every single participant in the summit agreed with the definition of ET, but few of us agreed on what the definition actually meant. This is a phenomenon we had no name for at the time, but is now called shallow agreement in the CDT community. To combat shallow agreement and promote better understanding of ET, some of us decided to adopt a more evocative and descriptive definition of it, proposed originally by Cem and later edited by several others: “a style of testing that emphasizes the freedom and responsibility of the individual tester to continually optimize the quality of his work by treating test design, test execution, test result interpretation, and learning as mutually supporting activities that continue in parallel throughout the course of the project.” Independently of each other, Jon Bach and Michael had suggested the “freedom and responsibility” part to that definition.
2006年までに、わたしたちのETの定義はシンプルなもの落ち着いた。
「学習、テスト設計、そしてテスト実行を同時に行うこと」。
この分野を前に進めるために、JamesとCemは2006年春、「探索的テスト 研究サミット」と呼ばれる会を開いた（参加者はJames Bach、Jonathan Bach、Scott Barber、Michael Bolton、Elisabeth Hendrickson、Cem Kaner、Mike Kelly、Jonathan Kohl、James Lyndsay、Rob Sabourin）。あらかじめ覚悟していたことながら、わたしたちは不穏な気づきに至ることになった。つまり、サミットの出席者のすべてが上述のETの定義に賛成していながら、この定義が実際のところ何を意味しているのかという点ではほとんどが合意できなかったのだ。そのような事態に当時は名前がなかったが、今ではコンテキスト駆動テスティングのコミュニティで、「浅い合意」と呼ばれている。
浅い合意と戦い、ETをよりよく理解するために、わたしたちはもっとイメージしやすく、説明的な定義を採用することにした。
「テスター一人ひとりの自由と責任を前面に出し、テスト設計、テスト実行、テスト結果の解釈、そして学習を、プロジェクトを通じて並行に、かつ相互補完的に続くアクティビティと捉えることで、テスターの仕事の質を継続的に最適化する、テスティングのスタイル」。
これはもともとCemが提案し、後に複数の人間によって編集されたものである。この定義のうち「自由と責任」という部分を、Jon BachとMichael Boltonはそれぞれ独立に提案したのであった。
And so we had come to a specific and nuanced idea of exploration and its role in testing. Exploration can mean many things: searching a space, being creative, working without a map, doing things no one has done before, confronting complexity, acting spontaneously, etc. With the advent of the continuum concept (which James’ brother Jon actually called the “tester freedom scale”) and the discussions at the ExTRS peer conference, we realized most of those different notions of exploration are already central to testing, in general. What the adjective “exploratory” added, and how it contrasted with “scripted,” was the dimension of agency. In other words: self-directedness.
こうしてわたしたちは、テスティングにおける探索とその役割について、より具体的で精妙な考え方に至った。
探索というものは、たくさんの意味を持っている。空間を探ること、クリエイティブであること、地図なしに仕事をすること、かつて誰もしていないことをすること、複雑さと向き合うこと、自発的に動くこと、などなど。上述の「連続体」のコンセプト（実はJamesの兄弟のJonは、これを「テスターの自由の物差し」と呼んでいた）の登場と、サミットにおける親密な議論を通じて、探索に関するこれらのさまざまな概念の大部分は一般に、すでにテスティングの中心をなすものだと気づいた。
「探索的」という形容詞が付加するもの、あるいは「手順付き」と比べて際立っている点は、主体性の程度である。言い換えれば、「自分で方向付けができる」（self-directedness）ということである。
The full implications of the new definition became clear in the years that followed, and James and Michael taught and consulted in Rapid Software Testing methodology. We now recognize that by “exploratory testing”, we had been trying to refer to rich, competent testing that is self-directed. In other words, in all respects other than agency, skilled exploratory testing is not distinguishable from skilled scripted testing. Only agency matters, not documentation, nor deliberation, nor elapsed time, nor tools, nor conscious intent. You can be doing scripted testing without any scrap of paper nearby (scripted testing does not require that you follow a literal script). You can be doing scripted testing that has not been in any way pre-planned (someone else may be telling you what to do in real-time as they think of ideas). You can be doing scripted testing at a moment’s notice (someone might have just handed you a script, or you might have just developed one yourself). You can be doing scripted testing with or without tools (tools make testing different, but not necessarily more scripted). You can be doing scripted testing even unconsciously (perhaps you feel you are making free choices, but your models and habits have made an invisible prison for you). The essence of scripted testing is that the tester is not in control, but rather is being controlled by some other agent or process. This one simple, vital idea took us years to apprehend!
ETの新しい定義の意味するところのすべてが次の数年間で明らかになり、JamasとMichaelはラピッドソフトウェアテスティングの方法論の中でそれを教え、指導した。
わたしたちは現在、「探索的テスト」という言葉によって、「自分で方向付けのできる、豊かで効果のあるテスティング」を表現しようとしていたことに気づいている。言い換えれば、主体性を除くすべての側面において、スキルの高い探索的テストは、スキルの高い手順付きテストと見分けがつかない。問題は主体性だけであって、ドキュメンテーション、計画の度合い、経過時間、ツール、意識した意図のいずれでもないのだ。
近くに紙の束がなくても手順付きテストはできる（手順付きテストは、文字通りの「手順書」に従うことを求めていない）。事前の準備がまったくない手順付きテストだってできる（誰か他の人間が、アイデアを考えながらその場で、するべきことを教えてくれるかもしれない）。手順付きテストを、その場で気づいたことで行うこともできる（誰かが手順書を渡してくれることもあれば、自分自身で作成することもある）。手順付きテストは、ツールがあってもなくても行うことができる（ツールはテスティングを変えるが、必ずしも手順を細かくするわけではない）。手順付きテストは意識せずに行うことだってできる（おそらく、自分では自由に選択していると感じるだろうが、自分のモデルと癖が、見えない牢獄を作り出している）。
手順付きテストの本質は、テスターがコントロールしているのではなく、自分以外の主体やプロセスにコントロールされているという点だ。このシンプルで重大な発想にたどり着くまでに、何年もかかってしまったのだ！
In those years we worked further on our notions of the special skills of exploratory testing. James and Jon Bach created the Exploratory Skills and Tactics reference sheet to bring specificity and detail to answer the question “what specifically is exploratory about exploratory testing?”
この数年でわたしたちは、探索的テストの特別なスキルに関する概念について、ずいぶんと歩を進めた。James BachとJon Bachは、「探索的テストにおいて、”探索的”とは具体的に何を意味するのか」という質問に答えるために、具体的で詳細な「探索的スキルと戦術」のリファレンスシートを作った。
In 2007, another big slow leap was about to happen. It started small: inspired in part by a book called The Shape of Actions, James began distinguishing between processes that required human judgment and wisdom and those which did not. He called them “sapient” vs. “non-sapient.” This represented a new frontier for us: systematic study and development of tacit knowledge.
2007年、ゆっくりとだが巨大な飛躍が起ころうとしていた。
起こりは小さなものだった。『The Shape of Actions』という本の一部に触発されたJamesが、人間の判断や知性を必要とするプロセスと、必要としないプロセスを区別し始めた。Jamesはそれらを「知性的」「非知性的」と呼んだ。これはわたしたちにとって新しい地平を意味していた。つまり、システマティックな学習と、暗黙知の発達である。
In 2009, Michael followed that up by distinguishing between testing and checking. Testing cannot be automated, but checking can be completely automated. Checking is embedded within testing. At first, James objected that, since there was already a concept of sapient testing, the distinction was unnecessary. To him, checking was simply non-sapient testing. But after a few years of applying these ideas in our consulting and training, we came to realize (as neither of us did at first) that checking and testing was a better way to think and speak than sapience and non-sapience. This is because “non-sapience” sounds like “stupid” and therefore it sounded like we were condemning checking by calling it non-sapient.
2009年にMichaelが、テスティングとチェッキングを区別することでこれに続いた。テスティングは自動化できないが、チェッキングは完全に自動化できる。チェッキングはテスティングに組み込まれている。
「知性的なテスティング」というコンセプトがすでにあったので、Jamesは当初これに反対し、新しい区別は必要ないとしていた。彼にとってチェッキングとは、単に「非知性的なテスティング」だったのだ。
しかし、チェッキングとテスティングという考え方をコンサルティングやトレーニングに適用して数年すると、知性的・非知性的というよりもそちらの方が、考えたり話したりするのに適しているとわかったのだった。なぜなら、「非知性的な」という言葉は「まぬけな」と言っているように聞こえるし、そのせいで「非知性的な」と呼ぶことがチェッキングを否定しているかのように聞こえてしまうからだ。
Do you notice how fine distinctions of language and thought can take years to work out? These ideas are the tools we need to sort out our practical decisions. Yet much like new drugs on the market, it can sometimes take a lot of experience to understand not only benefits, but also potentially harmful side effects of our ideas and terms. That may explain why those of us who’ve been working in the craft a long time are not always patient with colleagues or clients who shrug and tell us that “it’s just semantics.” It is our experience that semantics like these mean the difference between clear communication that motivates action and discipline, and fragile folklore that gets displaced by the next swarm of buzzwords to capture the fancy of management.
言葉や思考をはっきりと識別できるようになるまでに何年もかかることがある、ということに気づいただろうか？ これらの考え方は、わたしたちが実際の判断を整理するのに必要なツールである。
ただ、市場に出てくる新薬によく似て、わたしたちの考え方や用語がもたらす利益だけでなく、それらが潜在的に持つ有害な副作用まで理解するには、しばしば多くの経験が必要になる。「そんなもの、ただの言葉の意味の問題ではないか」と肩をすくめて言ってくる同僚やクライアントに対して、この作業を始めて長いわたしたちがなぜ必ずしも我慢強くないのか、これでわかってもらえるかもしれない。こういった言葉の意味が、行動と規律を動機づける明確なコミュニケーションと、経営陣の歓心を得るための次なるバズワードの大群に取って代わられる脆弱な都市伝説との違いを意味している、というのがわたしたちの経験である。
ET 3.0: Normalization
ET 3.0：標準化
In 2011, sociologist Harry Collins began to change everything for us. It started when Michael read Tacit and Explicit Knowledge. We were quickly hooked on Harry’s clear writing and brilliant insight. He had spent many years studying scientists in action, and his ideas about the way science works fit perfectly with what we see in the testing field.
2011年、社会学者のHarry Collinsがすべてを変え始めた。それは、Michaelが『暗黙知と形式知（Tacit and Explicit Knowledge）』を読んだのがきっかけであった。わたしたちはすぐに、Harryの明瞭な著作と素晴らしい洞察に夢中になった。彼は長年、活動中の科学者たちについての研究を行っているが、科学というものがどのように進んでいくかについての考えが、わたしたちがテスティングという分野において見てきたものと完全に一致するのだ。
By studying the work of Harry and his colleagues, we learned how to talk about the difference between tacit and explicit knowledge, which allows us to recognize what can and cannot be encoded in a script or other artifacts. He distinguished between behaviour (the observable, describable aspects of an activity) and actions (behaviours with intention) (which had inspired James’ distinction between sapient and non-sapient testing). He untangled the differences between mimeomorphic actions (actions that we want to copy and to perform in the same way every time) and polimorphic actions (actions that we must vary in order to deal with social conditions); in doing that, he helped to identify the extents and limits of automation’s power. He wrote a book (with Trevor Pinch) about how scientific knowledge is constructed; another (with Rob Evans) about expertise; yet another about how scientists decide to evaluate a specific experimental result.
Harryとその同僚の研究を学ぶことで、わたしたちは暗黙知と形式知の違いについてどのように語るべきかを知ることになり、どんなものが手順やその他の成果物に変換できて、どんなものができないのかを認識することができるようになった。彼は「振る舞い」（活動のうち、観察と記述が可能な側面）と「行動」（意図を伴った振る舞い）を区別していた（これに触発されて、Jamesは知性的テスティングと非知性的テスティングを区別した）。「ミミオモーフィック（mimeomorphic）な行動」（複製し、毎回同じように実行したい行動）と、「ポリモーフィック（poliprphic）な行動」（周りの条件に応じて変化させるべき行動）の違いに取り組んでいたのだ。これによって彼は、自動化の力の程度と限界を認識することの助けになった。彼はTrevor Pinchと、科学的な知識がいかにして構築されるかについての本を著し、またRob Evansとは専門性についての本を、また科学者がどのようにして、特定の実験の結果の評価を決定するかについて著した。
Harry’s work helped lend structure to other ideas that we had gathered along the way.
- McLuhan’s ideas about media and tools
- Karl Weick’s work on sensemaking
- Venkatesh Rao’s notions of tempo which in turn pointed us towards James C. Scott’s notion of legibility
- The realization (brought to our attention by an innocent question from a tester at Barclays Bank) that the “exploratory-scripted continuum” is actually the “formality continuum.” In other words, to formalize an activity means to make it more scripted.
- The realization of the important difference between spontaneous and deliberative testing, which is the degree of reflection that the tester is exercising. (This is not the same as exploratory vs. scripted, which is about the degree of agency.)
- The concept of “responsible tester” (defined as a tester who takes full, personal, responsibility for the quality of his work).
- The advent of the vital distinction between checking and testing, which replaced need to talk about “sapience” in our rhetoric of testing.
- The subsequent redefinition of the term “testing” within the Rapid Software Testing namespace to make these things more explicit (see below).
Harryの研究は、わたしたちがこれまで集めてきた他の考えについても、構造を与えるのに役立った。
- メディアとツールに関するMcLuhanの考え
- 「意味を成す」（sensemaking）ということについてのKarl Weickの研究
- わたしたちが、James C. Scottの「認識可能性」の概念に向かうきっかけとなった、Venkatesh Raoによる「テンポ」の概念
- 「探索的テストから手順付きテストへの連続体」が、実は「型式の度合いの連続体」であるという気づき（これはバークレイ銀行のテスターからの何気ない質問がもたらしたものだった） 。言い換えれば、アクティビティを形式化するというのは、より手順を細かくするということを意味している。
- 自然発生的なテスティングと、計画に基づくテスティングの重要な違いに関する気づき。これは、テスターが実行していることの反映の度合いである（探索的テストと手順付きテストの違いと同じではない。こちらは主体性の度合いである）。
- 「責任あるテスター」というコンセプト（自身の仕事の質について、完全で個人的な責任を果たすテスターと定義されている）
- チェッキングとテスティングの重要な区別の登場。これが、テスティングを語るうえでの表現であった「知性的」というものについて語る必要がなくなった。
- 続けて、それらをよりわかりやすいものにするための、ラピッドソフトウェア開発の名前空間における「テスティング」という用語の再定義。
About That Last Bullet Point
箇条書きの最後の項目について
ET 3.0 as a term is a bit paradoxical because what we are working toward, within the Rapid Software Testing methodology, is nothing less than the deprecation of the term “exploratory testing.”
ET 3.0は、若干逆説的な用語である。
ラピッドソフトウェアテスティングの方法論においてわたしたちが築いてきたものは、「探索的テスト」という用語に対する否定に他ならないからである。
Yes, we are retiring that term, after 22 years. Why?
そう、22年を経て、わたしたちはこの用語を引退させようとしているのだ。なぜか。
Because we now define all testing as exploratory. Our definition of testing is now this:
今や、すべてのテスティングが探索的であると定義付けているからである。テスティングの現在の定義は、以下の通りだ。
“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”
「テスティングとは、探索と試行を通じてプロダクトについての知識を得ることでそれを評価するプロセスである。これには、質問、学習、モデリング、観察、推論、出力のチェッキングなどが含まれる。」
Where does scripted testing fit, then? By “script” we are speaking of any control system or factor that influences your testing and lies outside of your realm of choice (even temporarily). This does not refer only to specific instructions you are given and that you must follow. Your biases script you. Your ignorance scripts you. Your organization’s culture scripts you. The choices you make and never revisit script you.
それでは、手順付きテストはどこに位置するのか。「手順」という言葉によってわたしたちは、テスティングに影響を与え、（たとえ一時的であっても）選択の体系の外側に位置する、何らかのコントロールシステムあるいは要因を指している。必ずしも、誰かに与えられ、従うよう義務付けられた具体的な指示を指すわけではない。あなたの先入観が、手順に影響する。あなたの無知が、手順に影響する。あなたの組織の文化が、手順に影響する。あなたが成し、二度とはやり直せない選択が、手順に影響する。
By defining testing to be exploratory, scripting becomes a guest in the house of our craft; a potentially useful but foreign element to testing, one that is interesting to talk about and apply as a tactic in specific situations. An excellent tester should not be complacent or dismissive about scripting, any more than a lumberjack can be complacent or dismissive about heavy equipment. This stuff can help you or ruin you, but no serious professional can ignore it.
テスティングを探索的なものであると定義することで、手順化というものは、わたしたちの仕事においてはゲストということになった。役に立つものではあるが、テスティングの外にあるもので、語るに興味深く、特定の状況では戦術として用いられる。木こりが重い道具について無関心・否定的でないのと同様、有能なテスターであれば、手順化に無関心であったり否定的であるべきではない。これはあなたを助けることもあれば滅ぼすこともあるが、真剣なプロフェッショナルであれば無視することがないものだ。
Are you doing testing? Then you are already doing exploratory testing. Are you doing scripted testing? If you’re doing it responsibly, you are doing exploratory testing with scripting (and perhaps with checking). If you’re only doing “scripted testing,” then you are just doing unmotivated checking, and we would say that you are not really testing. You are trying to behave like a machine, not a responsible tester.
あなたはテスティングを行っているだろか。であれば、探索的テストを行っているのだ。あなたは手順付きテストを行っているだろうか。責任をもってそれを行っているのであれば、手順とともに探索的テストを（おそらくはチェッキングも一緒に）行っているのだ。あなたが「手順付きテスト」のみを行っているのであれば、それはやる気のないままチェッキングを行っているに過ぎず、本当の意味でテストを行っているとは言えないということになる。あなたは責任あるテスターとしてではなく、機械のように振る舞おうとしているのだ。
ET 3.0, in a sentence, is the demotion of scripting to a technique, and the promotion of exploratory testing to, simply, testing.
一言で表現するならET 3.0は、手順化を一つの技法に格下げし、探索的テストをテストそのものであると格上げしたのである。
