Exploratory testing: Wikipedia

適当訳シリーズ。WikipediaのExploratory testing。

Exploratory testing is an approach in software testing with simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.

探索型テスト（Exploratory testing）は、ソフトウェアテストの設計と実施、そして学習を同時に行うアプローチである。テスト技術者は、テストを実施しながら、経験や創造性と共に新たに良いテストを思いつける能力を身につけていく。

History: 歴史

Exploratory testing has been performed for a long time, and has similarities to ad hoc testing. In the early 1990s, ad hoc was too often synonymous with sloppy and careless work. As a result, a group of test methodologists (now calling themselves the Context-Driven School) began using the term "exploratory" seeking to emphasize the dominant thought process involved in unscripted testing, and to begin to develop the practice into a teachable discipline. This new terminology was first published by Cem Kaner in his book Testing Computer Software. Exploratory testing can be as disciplined as any other intellectual activity. thats it

探索型テストは、昔から行われてきた。アドホックテスト（ad hoc testing）に似ている。1990年代前半、アドホックテストはいい加減で注意の足りない作業のことだと考えられることが非常に多かった。それに対し、"Context-Driven School"と称するテストメソドロジストのグループが「探索型」という用語を用いるようになった。あらかじめテスト項目を決めておかないからこそ必要となる思考プロセスを強調し、かつ勘や経験から伝承可能な技術にするのが目的である。この新しい用語はCem Kanerの"Testing Computer Software"（邦訳：基本から学ぶソフトウェアテスト）が初出である。探索型テストは、他の取り組みや技法と同じように、いい加減なものではない。

Description: 内容

Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The testing is dependent on the testers skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.

探索型テストは、ソフトウェアが実際のところどのように振る舞うのか、ソフトウェアが複雑なテストケースや単純なテストケースをどのように扱うのかを調べるために実施する。探索型テストの良し悪しは、テストケースを作り不具合を見つけるテストエンジニアのスキルに依存する。テストエンジニアがテスト対象について知っており、また様々なテスト技法を使うほど、探索型テストは良いものとなる。

To further explain, comparison can be made to the antithesis scripted testing, which basically means that test cases are designed in advance, including steps to reproduce and expected results. These tests are later performed by a tester who compares the actual result with the expected.

もっと説明するのであれば、探索型テストと対照的な存在となる記述型テストと比較するとよい。記述型テストは、基本的には、再現するために必要な操作手順と期待結果をテストケースとし、事前に設計しておくテストを意味している。設計と同時に実施されるのではなく、設計した後に実施され、期待結果と実際の動作結果が比較される。

When performing exploratory testing, there are no exact expected results; it is the tester that decides what will be verified, critically investigating the correctness of the result.

探索型テストを実施する際には、きちんとした期待結果は必要ない。実施しているテストエンジニアが、実際の動作結果のどこを検証すべきなのかを判断し、特に重要だと思われるところは不具合が無いかどうか、しっかり調査する。

In reality, testing almost always is a combination of exploratory and scripted testing, but with a tendency towards either one, depending on context.

実際のところ、テストというものは、ほとんど必ず探索型テストと記述型テストの組み合わせとなる。しかしどちらに重きを置くかは状況によって異なる。

The documentation of exploratory testing ranges from documenting all tests performed to just documenting the bugs. During pair testing, two persons create test cases together; one performs them, and the other documents. Session-based testing is a method specifically designed to make exploratory testing auditable and measurable on a wider scale.

探索型テストのドキュメントは、実施したテストを全て記録するような場合から、見つけたバグだけを記録する場合まで様々である。ペアテスト（pair testing）を実施する場合、テストの設計は2人で行い、片方が実施しつつもう片方がドキュメントを作成する。セッションベースドテスト（Session-based testing）は、探索型テストできちんと測定し監査するためのテストプロセスである。

Benefits and drawbacks: メリットとデメリット

The main advantage of exploratory testing is that less preparation is needed, important bugs are found fast, and is more intellectually stimulating than scripted testing.

探索型テストの主なメリットは、記述型テストに比べ、準備が少なく済み、重要なバグが早く見つかり、かつ知的な刺激が得られることである。

Disadvantages are that the tests can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.

デメリットは、事前にテストケースのレビューができないこと（およびソースコードやテストケースの誤りが予防できないこと）と、どんなテストケースが実施されたのかを正確に表すのが難しくなりうることである。

When repeating exploratory tests, they will not be performed in the exact same manner, which can be an advantage if it is important to find new errors; or a disadvantage if it is more important to know that exact things are functional.

逆に正確に同じ方法で探索型テストを繰り返せないということは、新しいバグを見つけることが重要な場面ではメリットになりうるし、機能的に正確な記述がより重要な時はデメリットになる。

Usage: 使い方

Exploratory testing is extra suitable if requirements and specifications are incomplete, or if there is lack of time. The method can also be used to verify that previous testing has found the most important defects. It is common to perform a combination of exploratory and scripted testing where the choice is based on risk.

探索型テストは、要求や仕様が不完全だったり、時間が無い時には極めて有用である。また、それまでのテストで検出しておくべき重大なバグを見つけられているかどうかをチェックしたい場合にも用いられる。探索型テストと記述型テストの組み合わせは、品質リスクを基にして判断するのが普通である。

An example of exploratory testing in practice is Microsofts verification of Windows compatibility.

探索型テストは、MicrosoftがWindowsの互換性テストに使ったという実例がある。