状態遷移テストのカバレッジについて、astah*とともに整理してみる

　『ソフトウェアテスト技法 練習帳』のPart3「状態遷移テスト」の章で、カバレッジ基準の表現が2種類あることに気が付きました。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

　「1スイッチカバレッジ」と、「C1カバレッジ（遷移網羅）」という表現です。
　「C1カバレッジ」という表現はコードカバレッジの文脈でしか見たことがなく、状態遷移テストにおいてあたるのは初めてだったのでつぶやいてみたところ、秋山さんからコメントいただきました。

29119-4では、状態、0スイッチ、全パス、Nスイッチが定義されていて、0スイッチは有効パスだけです。
C1については、どこの定義を見たら良いか分かりませんが、『知識ゼロ』本あたりから、「N/Aもテストしよう」というのが広まっているように思います。

— あきやま🐾 (@akiyama924) 2020年5月6日

　これを機に、状態遷移テストのカバレッジ基準について整理しておきましょう。
　ちなみに、コードカバレッジについては以下で書いてます。

www.kzsuzuki.com

キャッツの方の連載における定義

　まずは、状態遷移テストにおける「C0」について調べてみましょう。
　浅く検索しただけではあまり見当たらないのですが、キャッツの塚田 雄一さんによるMONOistの連載「状態遷移表による設計手法」では、状態遷移表に基づくホワイトボックステストが解説されています。

monoist.atmarkit.co.jp

　この記事には「C0」「C1」という表現が出てくるのですが、状態遷移テストにC0・C1という網羅基準があるという話ではなく、コードカバレッジのC0・C1を、状態遷移表から簡易に導出することができるというお話です*1。

　この記事では、C0は命令網羅、C1は分岐網羅のことを指しています。状態遷移表におけるアクションを「命令」と見なし、これをすべて通過するようにテストケースを導出することで、命令網羅を達成できます。
　また、（後述のastah*でいう）「ignore」や「cannot happen」も含めてすべてのアクションセルをカバーするようにテストケースを導出することで、分岐網羅を達成できるという考え方です。

　いずれにせよ、『練習帳』でいう「C1カバレッジ（状態網羅）」とは違うものですね。

ISO/IEC/IEEE 29119 Part4における定義

　国際規格をのぞいてみましょう。
　ソフトウェアテスト設計技法を扱うISO/IEC/IEEE 29119 Part4では、状態遷移テストの網羅対象として、以下の4つを扱っています。

• 状態: モデルにおけるすべての状態に到達する。
• 単一遷移（0スイッチカバレッジ）: モデル内の有効な単一遷移をすべてカバーする。
• 全遷移: モデルにおける有効な遷移と無効な遷移をともにすべてカバーする。（無効な遷移とは、有効な遷移が指定されていないイベントによる遷移）
• 複数遷移（Nスイッチカバレッジ）: モデルにおける連続(N+1)回の有効な遷移をカバーする。

　「C1カバレッジ」はありませんが、「遷移網羅」に近いのは、「単一遷移」でしょう。
　また『練習帳』では「C1カバレッジ（遷移網羅）、および、遷移しない無効トリガー動作」と表現されています。これは「全遷移」に対応すると考えてよさそうです。無効な遷移は、『練習帳』では「N/A」、後述のastah*でいう cannot happen に相当します。

astah*によるモデリング

　いきなりですが、モデリングツール「astah*」で、問題3.5の状態遷移をモデリングしてみましょう。
　なおastah*は「新型コロナウイルスで働き方に影響を受ける皆様へ」という形で、暫定的な無償ライセンスを提供してくださっています。粋な計らいですね。
　今回はこのライセンスを使用させていただきます！

astah.change-vision.com

状態遷移図と状態遷移表

　描いた状態遷移図は以下の通り。問題の内容は、書籍を読んでくださいね！
　「超電磁バリア」→「超電磁バリア」の遷移は、あえて省いています。

状態遷移図

　ここから自動生成される*2状態遷移表は、以下の通りです。

生成された状態遷移表

　たくさんのセルが空白のまま残っています。別の状態に遷移しない場合、以下の2つのいずれかを入力します*3。

• ignore: 当該イベントが発生しても、発生しなかったように扱う。
  • たとえば、「超電磁バリア」中に「敵を発見する」*4。
• cannot happen: 当該イベントは発生しえない。
  • たとえば、「停止中」に「敵を発見する」。

　なお『練習帳』では、ignore は同じ状態への遷移（たとえば超電磁バリア→超電磁バリア）と扱われ、cannot happen は「N/A」と表記されています。

空白セルを埋めた状態遷移表

テストケースの導出

　さてastah*では、プラグインを導入することで、状態遷移表からテストケースまで導出することができます*5。その結果が以下です。

0スイッチカバレッジのテストケース

　遷移回数が「1」というのは、0スイッチカバレッジを意味します。
　状態遷移表の紫色をカバーすることで、0スイッチカバレッジ = 100% を達成できます*6。
　ただ上図を見てわかる通り、ここに現れるのは「有効な遷移」のみです。cannot happen セルは含まれていません。

　遷移回数を2にすると、1スイッチカバレッジとなります。
　状態→遷移→状態→遷移→状態 となっていることがわかります。
　遷移が2つ、状態が3つなのに「1」スイッチカバレッジというのは正直いまだにしっくりきませんが。

1スイッチカバレッジのテストケース

他の網羅基準

　さて、ちょっと余談。
　「遷移網羅」というのは一見、もっとも基本的な網羅基準にも思えますが、実はより単純な網羅基準があります。

• イベントカバレッジ: 定義されたすべてのイベントをカバーしている。
• 状態カバレッジ: 定義されたすべての状態をカバーしている。
• アクションカバレッジ: 定義されたすべてのアクションをカバーしている。

　まあそのままなのですが。
　たとえば以下のテストケースがあるとしましょう。

1. 状態「停止中」でイベント「スイッチを押す」を起こす
2. 状態「起動中」でイベント「敵を発見する」を起こす
3. 状態「超電磁バリア」でイベント「敵がいなくなってから30秒経過する」を起こす

　この場合、イベント網羅は100%(3/3)ですが、「停止中」に遷移するテストケースはないので、状態網羅は67%(2/3)になってしまいます*7 。さらに、有効な遷移5つのうち3つしか実行していないので、遷移網羅は60%ですね。

　また、ファンクションネットでは reachability という言葉が出てきました。指定した状態に到達できるか否かという話です。

www.kzsuzuki.com

　状態遷移テストでも、開始状態と指定状態を指定した場合に可能な経路の網羅など、遷移の数とはまた違う視点のカバレッジ基準があるようです。

*1:実際のコードではないので、「モデルベースのコードカバレッジ」とでも呼べるかもしれません。

*2:astah*素晴らしいですね。

*3:詳細説明は以下。 www.changevision.co

*4:この場合、30秒タイマーがリセットされると考えると、「無視する」とするのは適切でないかもしれません。

*5:astah*素晴らしいですね。

*6:秋山さんに指摘されて気づいたのですが、状態遷移表では紫になっていない ignore も含めてパスが導出されていますね。ignore を29119でいう「無効」と考えると、astah*における「遷移回数=1」のカバレッジは、29119における無効パスも含むと考えられます。全網羅に相当・・・？

*7:ここでは「遷移後」に状態が出てきて初めて網羅されたとみなしています。29119の状態網羅の定義に visited という言葉があるというのが、その根拠です。

【翻訳】テストにおいて避けるべき、6つのペルソナ

　Kristin Jackvonyさんのブログ「Think Like a Tester」に掲載されたポスト『Six Testing Personas to Avoid』を、許可を得て翻訳してみました。

thethinkingtester.blogspot.com

　「ダメエンジニアの類型」みたいな記事って、バーナム効果的に「どれも自分に当てはまるかも・・・」となって面白いので、反省のために読んでしまいますね。

テストにおいて避けるべき、6つのペルソナ (翻訳)

　エンドユーザ向けのソフトウェアを作っている会社で働いていれば、「ユーザペルソナ」について聞いたことがあるでしょう。ユーザペルソナとは、アプリケーションのエンドユーザの一つの側面を表現したものです。
　たとえば、自宅を改善するための製品のウェブサイトを作っている会社で働いているとしましょう。この場合、最初の家を購入したてで、自宅のこまごまとした点を直す経験はあまりない、「新居を買ったばかりのNick」が、ユーザペルソナの一つとなりえます。他には、家を自分でなんでも直せる経験をもつ、「DIYのDora」もペルソナになるかもしれません。

　わたしは最近、テストにおいてもペルソナというものがあるのではないか、と思いつきました。ただこれらのペルソナは、ユーザペルソナとは違って、わたしたちが避けるべきものです！ 当てはまるペルソナがないか、読んでみてください。

1. テスト手順派のTed (Test Script Ted)

　Tedはテストを手動で行い、終わったときにチェックマークを付けることが大好きです。テストが通ったことを見ると、満たされた気持ちになります。
　アプリケーションがどう動くかを理解しているかどうかについては特に気にしていません。言われたことをすることで満足してしまっています。アプリケーションがどう動くかを理解していないので、時に重大なバグを見逃します。おかしな動きを見かけても、テスト計画の中で扱われていないので、問題なしとしてしまうのです。彼の仕事はテストすることであり、物事を理解することではない、というわけです。

2. 自動化のAnnie (Automation Annie)

　Annieは自分のことを、自動化エンジニアを見なしてます。手動テストは大きな時間の無駄であり、もっと難しいこと―――自動テストの作成と保守にのめり込みたいと考えています。
　新しい機能が作られても、探索的テストに時間を割いたりはまったくしません。すぐにコーディングを初めて、自分の素晴らしい自動化によってどんなバグでも見つかると考えています。

TedとAnnieの共通点

　TedとAnnieは、違う理由で同じ失敗をしています。二人は、アプリケーションがどう動くかを真に理解するために時間を費やしていません。二人とも、理解不足からバグを見逃しているのです。Tedはフィーチャを動かすコードを理解せず、Annieはアプリケーションのユースケースを理解していません。

TedやAnnieにならないために・・・

　しっかりとしたテスターたるもの、フィーチャがどのように動くかを理解するために時間を使うことが重要です。手で試して、その制限を探索してみましょう。他にテストしようがないかを探るために、コードを覗いてみましょう。理解できない部分があれば、質問を投げてみましょう。

3. プロセス屋のPatty (Process Patty)

　Pattyは品質に情熱を持っています。物事が正しく動いていることを好みます。ですがそれ以上に、プロセスと基準があることを愛しているのです！
　 テスト計画とメトリクスを持ち込み、自分のチームは一語一句それに従うと思っています。探索的テストの前にリグレッションテストが完了していなければならず、そのリグレッションテストは大量にあります。問題は、隔週でリリースするにあたり、探索的テストを行う時間がないということです。プロダクトをテストする新しいやり方はないか、見逃していることはないかと立ち止まって考える余裕もありません。リグレッションテストがすべて終わっていることが必要なのです。

4. 深掘りしすぎのRay (Rabbit Hole Ray)

　Rayもまた、品質に対して熱い思いをもっていて、バグを見逃したくないと思っています。ですので、IE10でアプリケーションを動かしてみて何かおかしな点が見つかれば、何が悪いのかを解明しようと心に決めます。調査に何日もかけ、ログを見て、別の構成のシナリオでも再現しないか試します。フィーチャがリリースされようというときに、標準のリグレッションテストを終わらせずに放置していたとしても、関わりたがりません。IE10を使っているのが顧客のわずか1%だということなど、気にもしません。謎を解こうとするのです！

PattyとRayの共通点

　PattyとRayはともに、時間を無駄にしています。第一の目的、つまり「最低限の欠陥で、良いソフトウェアを、期日通りにリリースする」こと以外にフォーカスしているのです。
　Pattyはプロセスに捕らわれ過ぎて、新しいバグを見つけうる探索的テストの重要さをわかっていません。Rayは自分が探索している難しいバグに取りつかれ過ぎて、もっと多くのユーザに影響を与える重要なテストを無視してしまっています。

PattyやRayにならないために・・・

　新しいフィーチャをテストしたり、既存のフィーチャのリグレッションテストを行う場合、もっとも大きなインパクトを与えるテストが何かを考え、それに応じてテストを計画することが重要です。プロセスに捕らわれ過ぎないように気を付けましょう。また調査中の捉えづらいバグがエンドユーザに大きな影響を与えそうにないのであれば、放っておきましょう。

5. 仕事の安定が一番のJim (Job Security Jim)

　Jimは今のポジションで何年も働いており、自分たちのアプリケーションのことを知り尽くしています。もっとも古いフィーチャがどのように振る舞うかといったどんな疑問に対しても、頼りになります。会社が自分を手放すことはできないとわかっています。わかり過ぎていると言えるでしょう。
　ですので、新しいスキルを学ぶ理由はあるとは思っていません。今のところ、彼の知識で十分やっていけるのです。仕事が終わった後に、最新のプログラミング言語やテストツールについて勉強したりすることなど、時間の無駄にしか思えないでしょう。

6. カンファレンス好きのConnie (Conference Connie)

　Connieは技術が大好き！ 最新のテスト技術や開発のトレンドについて話を聞くことが好きです。ウェビナーに参加登録し、カンファレンスに行き、ブログ記事を読み、オンラインコースを受講します。あらゆることについて、ちょっとだけ知っているのです！
　ですが新しく学んだことを実際に導入したことはまったくありません。カンファレンスやウェビナーに行くのに忙しくて、通常のテストのタスクをこなす時間しかないのです。それに加えて何かに取り組むというのは大きな仕事。他の人がどのように取り組んでいるかを見るだけの方が、楽です。

JimとConnieの共通点

　JimとConnieは一見、まったくの逆に見えますね。Jimは新しいことを何も学びたくはないし、Connieは新しいことなら何でも学びたい。ですが抱えている問題は同じです。テスターとして成長していないのです。
　Jimはすでに知っていることだけで満足していて、それ以上何かを学ぶ理由が見つけられません。ですがある日、会社がソフトウェアの書き直しを決め、突然新しいスキルが必要になったら・・・・彼はショックを受けることになるでしょう。
　Connieもたくさんの良いアイデアを持っているのですが、試してみないことには何の意味もありません。知識を実業務で使おうとしていないのですから、会社に何の利益ももたらしていないのです。

JimやConnieにならないために・・・

　新しい言語、ツール、技術について学ぶことで、テストの技術を維持することが重要です。世の中のすべてを学ぶ必要はありません。今の会社に一番メリットがあると思えるものをいくつか見繕ったうえで勉強し、一つ二つの領域でそれを実践してみましょう。あなたが導入したソリューションに、チームメイトは感謝してくれるでしょう。次のポジションに向けて、あなたの市場価値を向上させることにもなります。

ペルソナではなく、素晴らしいテスターでありましょう！

　わたしたちは誰でも、時にはこういったペルソナになってしまいます。ですがそれを意識していれば、自動化のAnnieや深掘りしすぎのRayや、他のどれかに陥りそうになっても気づくことができます。
　素晴らしいテスターは誰よりもアプリケーションについて学び、どんなテストをいつ行うかを正しく決め、テストをより良いものにし続けるために、自分のスキルをアップデートを継続するのです。

この記事を読んでみて

　正反対に見える2つのダメペルソナが、実は根本的には同じ間違いを犯している、という分類が面白いですね。
　また意外に、「ソフトウェアプロジェクトでのめんどくさい人の扱い方」とあまりかぶらないんですよね。

www.kzsuzuki.com

　最後に書かれている通り、誰もがこれらのダメペルソナになりうると思います。わたしは劣化版Connie（少しのことについて少しだけ知っている）になりがちかな・・・。
　良きエンジニアでいるために、アンチパターンを時々振り返るのは、いい習慣かもしれませんね。

Checking vs Testing 論争への強烈な皮肉

　Jason Arbonさんによるブログ記事「Checking vs Testing」は、「Checking vs Testing みたいな議論は、時間の浪費に過ぎない。この記事自体も含めて」という皮肉ですね。

medium.com

　なお、ほぼ同じタイトルの記事は、有名なコチラ。

www.developsense.com

　Jasonさんは記事の中で、「テストとチェック」と「手動テストと自動テスト」というよくある二つの比較について言及しています。そもそもこの議論の目的は、別に真実を追求したいわけではなく、ソフトウェアテストの現代化の波の中で、エキスパートとしてのロールを守りたいだけの人が騒いでいるのだろうと一刀両断しています。

testing と checking

　まず test と check については、「Googleで検索すれば、test の定義に check も入っている。以上。別に大した違いはない」としています。
　一部の人が、check に「機械的で単調」というイメージを押し付け、一方で test をより高尚なものと位置づけることで、自分たちが価値ある活動に従事していると言いたがっているというわけです。

　James BackさんやMichel Blotonさんの主張を皮肉っているようにも思えますが、「簡単なチェックを手動で実行するにしたって、頭は使う」「テストケースに基づくテストも探索的テストも、どちらも大事なんだ」という立場をみると、言っていることは同じかなという印象です。

www.kzsuzuki.com

automated と manual

　ここでも、「自動テストはチェック（上で述べた意味での）の繰り返ししかできない」という決めつけによって、「人間のテスターが重要」という主張を正当化しようとしていると言います。Jasonさんはこれを、2つの理由から否定しています。

1. スピード・コスト・再現性という自動テストのメリットを無視している
2. 二種類ある自動化のうち、一方しか見ていない。

　「二種類ある自動化」というのは、わたしにとって新鮮な分類でした。
　いわく、「リグレッション」と「生成的」の二つです。

　自動テストとしてまずイメージするのは一つ目ですよね。まず人間がテストケースを書き、それに従って自動化する。そのあと、リグレッションテストとして繰り返し実行されます。
　これは「毎回同じ」「単調」なものとされがちですが、賢いテスト自動化エンジニアだったら、実行のたびに環境やパラメタを変えたりしていると。殺虫剤のパラドックスを、自動テストでも回避しようと頭を使っているということですね。「同じことしかできない」という認識はあらためる必要があります。

　二つ目は、人間によるテストケースを前提とせず、仕様などの情報からテストを自動的に生み出すものです。最近も記事に書いたモデルベースドテストが該当しますよね。

www.kzsuzuki.com

　また他の例として、AIの強化学習によってテストを見つけ出すものを挙げています。ここまでくると、もう「単調」とはほど遠いですよね。

ためにする議論はもう・・・

　保身を目的として、あるいは自分を立派に見せたくてこの手の議論をする人たちを、Jasonさんは皮肉をこめていろいろな言葉で呼んでいます。testing philosopher、quirky deep thinkers、evangelists、sophists、・・・。

　「テストとは何か」を議論することが悪いわけではないと思います。
　ダメなのは、「自分は価値のある仕事をしているんだ！」とアピールするためだけに、この手の議論をふっかけて、耳目を集めようとすることです。

「シナリオテスト」とは一体、何なのか - その4

　シナリオテストについてのメモです。
　シナリオテストについては識者がいろいろな議論していますが、それらとの整合性とかは考えず、今わたしが考えている、わたしの知っているドメインでの「シナリオテスト」の話です。

　ただ、下書きを書いた後に、2012年の自分の記事を読んでみると、大きく変わってはいませんでした。。。まるで成長していない・・・ので、「その4」にしています。

www.kzsuzuki.com

シナリオテストの定義

　まず、ISTQBの定義。
　ISTQBでは、シナリオテストはユースケーステストの同義語として扱われています。

ユースケーステスト（use case testing）
ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。
Synonyms: シナリオテスト（scenario testing）, ユーザシナリオテスト（user scenario testing）

　次に、ISO/IEC/IEEE 29119 Part3の定義と勝手訳。

scenario testing
class of test design technique in which tests are designed to execute individual scenarios
Note 1 to entry: A scenario can be a user story, use-case, operational concept, or sequence of events the software may encounter etc.
個々のシナリオを実行するためにテストを設計する、テスト設計技法のクラス。
「シナリオ」とは、ユーザストーリー、ユースケース、運用の構想、ソフトウェアが遭遇しうるイベントの連なりなども含む。

　「シナリオテスト」周りにはいろいろな類似概念がありますが、ISTQB、29119ともに、それらをまるっと「シナリオ」「ユースケーステスト」に寄せようとしている印象です。

　で、オレオレ定義。

人間とシステムの相互作用によって、指定されたゴールが達成できることを確認するためのテスト。

　「ゴール」という言葉が逃げなのですが、「ユーザが達成したいこと」という意味です。
　「業務」というと業務系システムに限定してしまう感じなので、この言葉を使っています。

　このオレオレ定義の意図するところには、以下のようなものがあります。MECE性無配慮。

シナリオでは、人が中心であり、システムが絡まない部分がありうる

　シナリオにおいてはコンピュータシステムは要素の一つにすぎず、システムの現れない作業もありえます。
　たとえば「テレビ局の番組のための取材」という業務を考えてみましょう。取材のサブ業務として、以下を仮定します。

1. 取材に関する情報の登録と、取材に回す人間のアサイン
2. 取材自体
3. 取材で得た音声/映像コンテンツの持ち帰り
4. 当該の取材に関する情報の更新

　1と4はいかにもシステム化していそうな部分ですが、2はシステムからいったん離れています。
　3はもう少しややこしくて、電子的に転送できる環境であればコンテンツシステムに自動登録され、取材と関連付けられます。一方そうでない場合は「媒体を車両で物理的に持ち帰る」ことになります。ここにはシステムが現れません。
　1と4の間で、システムの利用が断絶しているわけです。

　シナリオテストでは、システムの利用が断絶しても、業務自体は断絶しないことを確認しなければなりません。もっと積極的には、「スムーズに回る」ことが理想です。
　これは1、3、4の個々の機能のテストではわからないことです。

シナリオは、機能の組み合わせからなるものではない

　ゴールは機能に先立ちます。まずゴールがあって、システムとその機能は、ゴールを達成するための補助的な存在です。
　よってシナリオテストのためのシナリオは、「ユーザは何を達成したいのか」からトップダウン的に作るのがメインルートであり、「おれたちの作った機能を組み合わせて何ができるだろう」からボトムアップ的に逆算するのはサブルートにするのがよいです。

　といっても、機能をいろいろ組み合わせてシナリオを作り上げることを否定するわけではありません。機械的に組み合わせてみると、トップダウンのアプローチでは思いつかなかったシナリオを発見できるかもしれない。ですので、発想を広げるためにはこのアプローチも有効だと思いますが、まずは「何を達成したいのか」から目をそらさないことが大事だと思います。

シナリオの網羅性は、機械的に説明しがたい

　テスト技法の中には、テストカバレッジの「分母」を数学的に導出できるものがありますよね。コードカバレッジがそうですし、組み合わせテストや状態遷移テストもそうです。

　一方シナリオテストにおいて、「全シナリオ」を機械的に導出できるとは考えづらいですね。
　シナリオの網羅性は、「ユーザが達成したいこと」とその「バリエーション」、そして「それを妨げる事象」をどれだけ洗い出せるかが勝負になります。特定のお客様がいるのであれば、そのお客様が示す明示的/暗黙的な要件。不特定多数のユーザがいるなら、それらのユーザから収集可能なオペレーションログから想定できる「使い方」。などなど、得られる情報から発想を繰り返すことが、シナリオテストにおける「テスト設計」になるのではないかと思います。

ということで

　昔考えていたことから特に進展はありませんでした。
　ただ当時は、シナリオを「ユースケースの接続」のように捉えていたのですが、現在は「ユースケースとユースケースの隙間に、システムの介在しない隙間があるよな」と考え直しております。

　ずーっと積読になっていたこの本を読み始めました。いつか記事書きます。

ユースケース導入ガイド―成功する要求収集テクニック

「探索的テスト3.0」における「探索」の位置づけなどの覚書

テストと探索的テスト

　James BackとMichael Boltonによる、「彼らの」探索的テストについて、簡単に振り返っておきます。これを読んでも、探索テキストがうまくなるわけではありません。

　『Exploratory Testing 3.0』（探索的テスト3.0）という記事は、「探索的テスト」が生まれた背景や変遷についても言及しており、とても長いです。

www.satisfice.com

　翻訳はこちらにあります。5年以上前の翻訳で粗も目立ちますが、許してください。*1

sites.google.com

　About That Last Bullet Point の部分を読めば、彼らの今の立場がわかります。

　まず大事なのは、「探索的」という言葉についての認識の刷新。

今や、すべてのテスティングが探索的であると定義付けている

　「探索的テスト」が旨としていた「探索」は、実はテスト自体が当然もつべき性質であるとしています。よって「探索的テスト」という言葉は、馬から落馬しているようなものなのです。

　そこで、この新しい認識を踏まえたうえで、Testing 自体に新しい定義を与えています。

テスティングとは、探索と試行を通じてプロダクトについての知識を得ることでそれを評価するプロセスである。これには、質問、学習、モデリング、観察、推論、出力のチェッキングなどが含まれる。

　つまり、よく対比される探索 (exploring) もチェック (checking) も含むプロセスを、テスト (testing) と再定義しているわけですね。
　現在の、探索（search ではなく exploration の方）を行わない自動テスト (automated testing) は、テストの役割のうち特にチェックを担うという位置づけになるでしょうか。

　ただし彼らは、チェックを「価値のないもの」「無意味なもの」と扱ってはいるわけではありません。テストに属する重要な要素の一つです。探索とチェック、それぞれの役割があるという考えですね。

　ダメなのは、人間による unmotivated checking、つまり「やる気なしチェック」です。これはまさに自動化で代替したいところ。逆に、モダンな自動テストであれば、「やる気なしチェック」よりよっぽど上等な学習や推測をしてくれるかもしれません。　

　同じように、スクリプトテストについても否定していません。

必ずしも、誰かに与えられ、従うよう義務付けられた具体的な指示を指すわけではない。あなたの先入観が、手順に影響する。あなたの無知が、手順に影響する。あなたの組織の文化が、手順に影響する。あなたが成し、二度とはやり直せない選択が、手順に影響する。

　一般的に「探索的テスト」といえば、手順が指定されていないことを特徴とされがちですが、「手順があること」は必ずしも「探索」を妨げるものではないからです。
　考えてみれば、手順が明確にされていたとしても、あやしい動きを見たら立ち止まることもありますし、そこから派生するテストケースを書き出したりもしますよね。

　もう一つのポイントが以下ですね。

ET 3.0は、手順化を一つの技法に格下げし、探索的テストをテストそのものであると格上げした

　従来は、「テスト」があって、その下に「手順のない探索的テスト」と「手順のあるスクリプトテスト」のように扱われていました。
　今は、探索行為を含む「テスト」があって、その方法の一つとして「手順のあるスクリプトテスト」を位置づけているということです。

　以上をまとめると、以下のようになります。

• 探索的なふるまいは、本来「テスト」自体が持つ要素である。
  • 「探索的テスト」という言葉は引退！
• 「テスト」には、探索やチェックの他、質問・学習・モデリング・観察・推論といった行動も含まれる。
• テストの手順は探索の否定にはならない。
  • ただし手順化は、テストの技法の一つに過ぎない。

　まあちょっと言葉遊び感も、あるにはあります。
　ただ、「探索的テスト」に限らず、テスト自体が人間の能力と自発性を要求するものだという位置づけは、納得のいくものだなと思います。

　・・・と書き終えたところで、また『Checking vs Testing』という記事が上がっているとにしさんのツイートを見かけたりして・・・。

medium.com

*1:またこのお詫び自体も、まるで「今ならもっといい翻訳ができる」と言わんばかりの見栄に満ちていますが、合わせて許してほしい。