ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

テストオラクルとは何か

File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg"File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg" is licensed under CC0 1.0

 ソフトウェアテストの有識者の方々と、「テストオラクル」について話す機会があったので、自分なりの理解を整理しておきます。

 まずはおなじみ、I/JSTQBの用語集から。

テストオラクル(test oracle)
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

 要するに、期待結果を作るための元ネタでふね。

 ここで2つ、気がつくことがあります。

  1. (少なくとも明示的には)仕様書はオラクルと見なされていない。
     → オラクルにはどんな種類があるのか
  2. オラクルは、期待結果そのものではない
     → オラクルが期待結果そのものではないとは、どういうことか

 本記事では、この2点について考えてみたいと思います。

1. オラクルにはどんな種類があるのか

 「期待結果のソース」というオラクルの定義を考えれば、明記こそされていないものの、仕様書自体もオラクルに含めてもかまわないでしょう。
 これを含めれば、オラクルは以下の3つに分類できます。

そのソフトウェアをふるまいを記述したドキュメント

 仕様書、ユーザマニュアルなどがこれに当たります。

比較対象にできるソフトウェア

 まず、用語集で「ベンチマーク」と表現されているものがあります。Cem Kaner氏は、Microsoft Officeの競合品としてOpenOfficeを開発しているとすると、OpenOfficeの動作が「正しいか」は、Microsoftの「Word」が教えてくれるとしています*1

www.testingeducation.org

 またJRの運賃計算では、膨大なテストケースの期待結果を、1つ1つ人間が考えるのではなく、Nバージョンプログラミング、つまり同じ出力を持つシステムを複数作って突き合わせるということをしています。

www.publickey1.jp

テスト対象となる実機用の運賃ソフトウェアと、検証用の運賃ソフトウェアは別のチーム、別のアルゴリズム、別のプログラミング言語で作ります。実機用はC++ですが、検証用はJavaで言語特有のバグをなくそうとしています。でも検証用のソフトウェアにはそんなに予算が掛けられず少人数で作っているので、実機用はどうやって作ったのか聞きたくなるのですが、そこを我慢して作る。

過去の履歴

 「そのソフトウェアの前バージョンと同じ動きであれば問題ない」というオラクルもあります。リグレッションテストは、「過去の想定した期待結果の通りに動作する」ことを確認するので、テストオラクルの一覧ということができるでしょう。

人間の知識

 用語集では「専門家の知識」とあります。
 ですが、たとえば文字判別のソフトウェアにおいては、一般の人が「妥当」と考える常識的な判断がオラクルになりうるでしょう。

その他

 メタモルフィックテスティングはちょっと異色で、「正しいことがすでに分かっている期待結果」を派生させていくものです。

www.kzsuzuki.com

 このように、「期待結果のソース」は様々な種類があることがわかります。

2. オラクルが期待結果そのものではないとは、どういうことか

 oracleとは、神託のことですね*2
 世界観がぐちゃぐちゃですが、こういう絵になります。

f:id:kz_suzuki:20210411174734p:plain
神と神託

 神からのお告げを巫女さんが受け取ります。お告げは神秘と暗示に満ちていますから、解釈が必要です。専門職たる巫女さんがこれを解釈し、人々に伝えます。
 このアナロジーから言えることが、これまた2つあります。

  • 間違いが入り込む
  • 細かいことを教えてくれるとは限らない

間違いが入り込む

 まず、巫女さんが間違えます。
 たとえば「18歳以下は無料」という仕様を、「18歳であれば有料」と解釈してしまうと、誤った期待結果を得ることになります。

 次に、神が間違えます。
 神の無謬性を信じたいところではありますが、ソフトウェア開発において神託を告げるのは神ならぬ人。「仕様通りの動作である」ことがテストで確認できても、「間違った仕様通りの動作」なら意味がありませんね。

細かいことを教えてくれるとは限らない

 たとえば神たるお客様が「性能要件は、“旧システムと同様“ね~」と重々しく宣われたとしましょう。このオラクルは、システムのあらゆる性能要件を余すところなく記述したものと言えますが、「旧システムの性能を一つ一つ確認する」という「解釈」なしには、何も言っていないのと同じです。
 つまり、オラクルがあったとしても、テスト設計においてはそれを解きほぐす必要があるかもしれない、ということです。

まとめ

 まとめると、「適切なオラクルを適切に解釈しないと、適切な期待結果は得られない」という、ごくごく当たり前の結論になります・・・!

*1:まったく同じ話を過去記事でも書いていました・・・ www.kzsuzuki.com

*2:甲骨のことは、oracle bone というらしいです。

スモークテストとサニティテストとは何なのか

Sanity check"Sanity check" by foreverdigital is licensed under CC BY-NC-ND 2.0

 「サニティテスト」(sanity test)という言葉を聴くことがちょいちょいあったので、意味を捉えておきたいなと思っての記事です。なお、「本当の」「正しい」定義を見つけることが目的ではなく、「こんな風に捉えられていることが多そう」を理解することを意図しています。

 また、調べる過程で、自分がかつてまとめた以下のtogetterも見つけてしまったので、「テストタイプなのか、テストレベルなのか、テストフェーズなのか」 という議論も、ここではしません。

togetter.com

I/JSTQBでは

 まずはいつものここからですね。
 結論からいうと、サニティテストはスモークテストの類語とされています。

スモークテスト(smoke test)
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
Synonyms: コンフィデンステスト(confidence test), サニティテスト(sanity test)

 「スモークテスト」の方は、これでしっくりきます。本格的なテストを始めるにあたって、「そもそも最低限のところは動くよね」を一通り、さらっと見ることが目的です。ここでダメ、つまり最低限すらまともに動かないなら、それ以上テストをすることは無駄と判断できます。
 ネットワーク接続チェックの一番素朴なものであるpingになぞらえて、「疎通確認」という呼び方も聞いたことがあります。

スモークテストの由来

 Wikipediaを信じると、スモークテストはまず配管工事の分野で使われ、それが電気の分野に輸入され、さらにソフトウェアテストの分野に入ってきたようですね。

en.wikipedia.org

 配管の世界では、下水管などに対し無毒な煙を流し込んで全体を通過させ、パイプの劣化やひび割れを見つけるということを行っているようです。煙が漏れ出ていれば、そこに不具合(defect!)があるわけですね。

 電気の世界でこの言葉が拡張され、「回路基板の電源を入れた途端に煙が出てくるようなら、電源と落としてテストはおしまい」という拡張されたとのことです*1

 ここで、違和感を覚える人もいるかもしれません。
 電気の文脈では、「テストのしょっぱなの段階で、いきなりダメ」で煙が出るんですね。ソフトウェアのアナロジーだと、「インストーラが途中で止まる」とか「プロセスが起動しない」とか、そんな感じでしょうか。テストは始まってもいません。
 上のISTQBの定義の通り、ソフトウェアの文脈では「主要機能を網羅」するのがスモークテストなので、由来元の由来元である「全体を通過させ」る配管の文脈でのスモークテストの方が近いんですね。

 主要機能を網羅するとなると、わたしは自動リグレッションテストを連想してしまいます*2が、ISTQBの定義だと、リグレッションテストに限定していません。修正・変更後だけでなく、新しく作ったものを動かしてみる際にも、本格的なテストの前に軽く動かしてみる、これがスモークテストといえそうですね。

サニティテスト

 sanityというのは、「健全さ」「正気」という意味です。sanity testは「まともに動いているか」を確認するテストということになります。これだけだと、サニティテストとスモークテストは似たような印象ですね。

 両者の違いを説明した記事はけっこうあって、それぞれの主張があるのですが、共通的に見られる主張をテーブルにしてみると、以下のような対照がメジャーのようです*3

項目 スモークテスト サニティテスト
目的 プログラムの機能の主要な部分が正しく動作するかを確認するために行われる。 新しい機能の追加やバグの改修後が適切に行われたかを確認するために行われる。
特徴 浅く広いテスト。 (スモークテストに比べて)深く狭いテスト。
範囲 システム全体のEnd to Endが対象である。 システム全体の特定の部分が対象である。
対象 各ビルドに対して行われる。 比較的安定したビルドに対して行われる。
タイミング リグレッションテストの前に行われる。 スモークテストの後、リグレッションテストの前に行われる。
実施者 開発者、またはテスターによって行われる。 テスターによって行われる。
他のテストとの関係 受入れテストのサブセットである。 リグレッションテストのサブセットである。

 「他のテストとの関係」については、まったく逆の位置づけをしているサイトもあります。つまり、スモークテストがリグレッションテストの一部で、サニティテストが受入れテストの一部ということです。
 ただ上述の通り、I/JSTQBではスモークテストの実施タイミングを、プログラム修正に限ってない(プログラムの新規追加も対象にしている)ことから、上表での位置づけの方が親和性が高そうです。

終わりに

 用語の定義や、世の中で一定以上の共通認識があるものと、そうでないものがあります。「サニティテスト」は後者の一つのように思います。
 このような場合、組織やチームの中で定義を合意しておかないと、混乱のもとになります。
 スモークテストとサニティテストを別の概念として扱う場合の定義の一案として、この記事を参考にしていただければと思います。

参考サイト

*1:ただしこの話が載っているのはソフトウェアテストの書籍のようですが。

*2:パイプを煙が通過していく様子も、自動テストをイメージさせませんか?

*3:調べてみると、言い回しを含めて似たようなテーブルがたくさん出てきます。

中学生くらいでも楽しんで読めそうな算数・数学の本を探してみた

Escher Cookie Cutters - The Sequel

 数学。
 得意にはほど遠いけど、日常で使うレベルならギリ何とかなるというレベルのわたしです。

 ただ、算数や数学って、一度苦手意識を持つとずっとつきまといそうだなと思っていて、自分の子どもに紹介できそうな本はないかなと、タイトル&見た目で図書館を漁ってみたものを紹介します。

『数字マニアック』

 サブタイトルにあるように、1から200までの数の特徴や、これにまつわるトリビアを盛り込みまくった本です。いや、よく200まで漏れなく集めたよな・・と感心する。

 へえ~とうなるものもあれば、「いちいちよくこんなこと指摘したな」と笑ってしまうものもあります。
 たとえば2。2は、

その綴りに「e」を含まないただひとつの素数でもある。*1

 いや、そうだけど・・・

 また、整数の特性として「偶数」「奇数」「素数」の他、「完全数」「結婚数」くらいまではメジャーだと思いますが、「名前つけたかっただけじゃないの!?」ってものも多いです。

 たとえば、スミス数
 ある数の各桁の数字の和が、その数を素因数分解して現れた数字の和に等しい、という性質を持ちます。
 具体例でみてみましょう。

 166は、
 1 + 6 + 6 = 13
 166 = 2 * 83、2 + 8 +3 = 13 (ドヤァ)

 いや、そうだけど・・・(再)

 ケチをつけてしまったようですが、整数論だけでなく図形、スポーツ、テレビ番組など、いろんなところにいろんな数字が隠れているんだな~と楽しんで読めました。

 わたしが一番気に入ったのは、「81」の項に出てくる問題です。
 以下の不等式は、とても鮮やかに証明することができます。

(p2+p+1)*(q2+q+1)*(r2+r+1)*(s2+s+1) / p*q*r*s ≧ 81

『ロマンティック数学ナイト』

 「エピソード」というと、数学にまつわる歴史的な小話という印象を受けますが、そうではありません。「ロマンティック数学ナイト」というイベントで語られた、プレゼンターが語る数学のお話集です。

 数学のお話といっても、難しい話が延々と続くわけではなく、高級な数学への深い理解を前提にしたものでもありません。
 一見数学とは関係なさそうな身近なものを数学の目で見るとどうなる?というお話であって、ものによってはかなりのおふざけ度合いでもあります。

 「みんながおいしいというのは、最大公約数的な味である」という表現は何となく意味がわかる気がするけれど、ここでいう「最大公約数」ってなんだ?
 「行けたら行く」という信用できない言葉を、記号論理学的に分析したらどういう結論になる?

 たとえばこんな話を真剣に、あるいは軽快に論じる。数学のスパイスの利いた奇妙な話を楽しめる本です。

『武器になる「わり算」』

 割り算って、四則演算の中でも特に、生活に根付いたものなんだなということに気づかされる一冊。

 たとえば小学校で習う人口密度や速度、つまり「割合」は、その名の通り割り算から生まれてくるものです。
 割合や比率はしばしば、「信頼できる数値データ」のような姿で、説得の材料にも使われます。数字に嘘やトリックがあるのは論外として、たとえ数値として正しかったとしても、だからといってそれに基づく論理が必ずしも正しいとは限りません。

 たとえば有効求人倍率。

有効求人倍率 = 有効求人数 ÷ 有効求職者数

という数字が向上するのを見て、「就職しやすい環境になった」と言えるのか。
 詳しく見てみると、「求人」が多いのは専門職である一方、「旧職」が多いのは事務職であったりと、需要と供給がマッチしていない場合も多いといいます。

 どちらかといえば、大人向けの算数の本といえます。
 後半では、保険や投資、そして政治について、割り算をベースに語られています。こう見てみると、割り算、割合や比率といった数字が、身の回りのできごとに直結していることがよくわかります。
 個人的には、しばらく見直していない、おそらくは無駄な保険について手厳しく分析されていたのがつらかったです・・・。

読むだけで楽しい 数学のはなし

読むだけで楽しい 数学のはなし

読むだけで楽しい 数学のはなし

  • 作者:池田 洋介
  • 発売日: 2017/02/24
  • メディア: 単行本(ソフトカバー)

 今回読んだ中で、中学生でも楽しめそうだなと一番思ったのが、こちらです。

 著者ご自身がまえがきに書かれている通り、「類似の本はすでに数多く世にあ」って、本書で扱っているトピックも目新しいものばかりではありません。サルが紡ぎだすシェークスピア、モンティーホールパラドックス、相関関係と因果関係、などなど。
 ですが、これも著者のおっしゃる通り、「新しい切り口」が加えられており、一味違う面白い読み物に仕上がっています。

 たとえば「マンホールのふたが丸い理由は?」という問い。
 「フタが穴の中に落ちないように」と言われますが、本当にそうなのか。それは後付けではないのか。と疑問を呈しながら、そのまま定幅図形の話、お掃除ロボットの話へとつながっていく、という具合です。

 トピックは数学ですが、言葉も表現も平易。わかりそうなところをつまみ食いするだけでも、「数学ってこんなところにも出てくるのかー」と感じてもらえると思います。

 なお、「扇形のおきあがりこぼし」を左右にゆらした場合、頂点はどのような軌道を描くか、という話が面白かったです。

f:id:kz_suzuki:20210307152829p:plain
頂点はどんな軌道を描く?

 答えは意外、でも説明されると納得。直観と理性がうまく一致しない、不思議な話です。

オイラーの贈物

 こちらは、たまたま同時期に読んだもの。まったくこども向けではありません
 帯も煽ってきます。

本邦初・本格的数学書の文庫化
予備知識、参考書、一切無用の完全独習書
数学美の頂点 eiπ=-1に誘う迫力の500ページ

 「迫力」、まったく嘘ではありません。
 まず、500ページもあるのに、それぞれのページの文字も行間も小さい。数式と表とグラフだらけ。「誰にでもわかるオイラーの公式」じゃないのです。「熱意と根気があればこの1冊で理解できるオイラーの公式」なのです。

 であるからして。
 まずは第Ⅰ部で、有理数・無理数、実数・虚数の説明から始まり、数列、方程式、微分、積分までを130ページかけて学びます。
 さらに第Ⅱ部で、テイラー展開、指数関数・対数関数、三角関数を、219ページまでに学びます。
 そんな生活を10余年続けて、気が付けばもう若くない・・・234ページ・・・
 そういうページになって初めて導出できる公式が、オイラーの公式(Euler's formula)なんだ。
 この機会を逃したら、オイラーの公式なんてもうおまえには生涯 手にできない・・・!
 オイラーの公式は大作・・・大作なんだ・・・!

 ・・・すみません、利根川先生が乗り移っていました。  そう、234ページでようやく、

e = cosθ + i*sinθ

が得られ、θ=πのとき、おなじみの

e = -1

が導かれます。

 このように、もっぱら硬派な本書なのですが、それは無味乾燥を意味しません。ところどころに挟まれる注釈に、著者・吉田武氏の人間性や主張が垣間見えるのです。

 この公式が出た後の「注意」を読んでみましょう。

右辺を移項して、e + 1 = 0 と書けば、さらに要素が加わって、e、π、i、1、0の五大定数の関係となるので、より素晴らしいとする向きもある。確かに一理ある。しかし、この「方程式風味の表現」は、たとえ数学的には等価であっても、eのiπ乗が整数値(-1)に等しくなる、という不思議さが滅殺されているのではないか。所詮、美意識の違いにしか過ぎないだろうが、本書ではこれを採らない。

 わたしはもともと「=0」派でしたが、これを読んで意見がすっかり変わりました。
 3つの、何の関係もなさそうな特別な数字が、-1というきわめてシンプルな数字に束ねられてしまう。そういうことがわかる「= -1」の方が、確かに美しいと感じます。

 ちなみにTwitterアンケート(有効投票12票)によると、「-1」派が42%、「=0」派が58%となりました。おおむね拮抗といえるのではないでしょうか。

 それにしても、常軌を逸した本です。2の平方根の値4,000桁を1ページに収める文庫本ってありますか?

 この『オイラーの贈物』の古文版が、小西 甚一・著の『古文の読解』と言えるでしょう。

古文の読解 (ちくま学芸文庫)

古文の読解 (ちくま学芸文庫)

 これまた大学受験生向けということになってはいるのですが、受験国語の一分野に過ぎない古典に、これだけの熱量を注ぐ者がどれだけいる?というほどの丁寧さとロジックをもって、古文を解読していきます。
 いや、ロジックといっても、古語の動詞の文法的活用とか、「たらちねのといえば母!」みたいな、受験勉強的暗記ルールではないですよ。「文章を解きほぐして地道に推論していくと、このように理解できる」という展開のことを言っています。

 ちくま学芸文庫は本当に恐ろしいです。
 どちらの本にも、吉田武氏のこの言葉がぴったりでしょう。

本書に即効性はない。じっくり、のんびり楽しみながら読んで頂きたい。

 本来、勉強ってそういうものなんですよね、きっと。

*1:2以外の素数はすべて奇数であり、one、three、five、seven、nineには「e」が含まれる。

テストに関するチケットに何を書いておくとよいのかのメモ

A return ticket to Hell"A return ticket to Hell" by aslakr is licensed under CC BY 2.0

 スクラム開発におけるチケット管理のベストプラクティスというものについて不勉強のまま書いた記事です(免責)。

 実装を行う人とテストを行う人が(ざっくりとでも)分かれている*1場合は、チケットも分けておくのがよいと感じています。
 あるフィーチャーの追加についてすべての作業を1つのチケットにまとめてしまうと、そのチケットの担当者がスプリント内で変わっていくことになります。特にテストをする人にとって、スプリント開始時点で「自分にアサインされる見込みのチケット」全体像が見えないのはものすごく不安です。
 よって、たとえば大まかに「設計・実装・ユニットテスト」と「それ以降のテスト」のようにチケットを切っておいて、チケットの担当者がなるべく変わらないようになっているのが好みです。

 ここでは簡単に、「開発チケット」「テストチケット」と呼ぶことにしましょう。

 開発チケットでは、自分たちの作ろうとしているフィーチャーの概要や受入れ基準を明確にしますよね。
 同じようにテストチケットでは、そのフィーチャーに対しどのようなリスクがあり、どのようなテストを重点的に行うかを表現して、スクラムチーム内で議論・合意をしておくのがよいと考えます。

 テストチケットに載せておきたい情報を、とりあえず3つ挙げてみました。

見積もり工数

 そのテストにかかる、またはかける工数です。

 実装する人は、作ったものの複雑さや難易度に応じて、テストにかかる工数のイメージを持っているかもしれません。しかし、開発の工数とテストの工数は、必ずしも比例するわけではないでしょう。
 実装する人とテストする人で、テストに要する工数の想定に大きな乖離があるとまずいので、スプリントプランニング、あるいはその後なるべく早く、想定工数について意識を合わせておくことが重要だと思います。

 工数の見積もりは、「これだけのテストを全部やると、これだけの時間がかかる」というボトムアップ型と、「今スプリントにおけるテスト工数のうち、このテストチケットにはこれだけの工数をかける」(よってカバレッジをここまでとする)というトップダウン型がありますね。
 後述のリスクに応じて、どこにどれだけの時間を投入するかを決めます。

リスク

 対象のフィーチャーに対し、設計・実装をする立場と、テストをする立場それぞれで、

  • やらかしていそうな欠陥
  • 起きてもらっては困る事象

の認識を合わせます。これはちょうど、「リスク発生確率・影響度マトリックス」の、発生確率と影響度に対応しています。
 テストをする人は、開発チケットから把握できる仕様だけでなく、設計・実装した人の直感や不安をテスト設計に反映できると、ベターなテストができると思います。

テスト観点

 リスクに基づいて、考えられるテスト観点を列挙します。具体的に適用できるテスト設計技法があれば、それも併記しておくとわかりやすいでしょう。
 より詳細なテスト設計やテストケース作成は、チケットの外で行ってもいいと思います。モデリングツールやスプレッドシートの活躍する領域なので。

 また観点を挙げる際、非機能要件への考慮が漏れないようにしたいものです。
 画面遷移などの性能、回線遅延発生時のリクエストのリトライ、ユーザに見せるメッセージのわかりやすさなど、メイン機能の外にあるふるまいの観点を忘れないようにしましょう。

スプリントプランニングにおけるQA

www.mindfulqa.com

 『スプリントプランニングにおけるQAの役割』(The Role of QA in Sprint Planning)という記事では、QA*2がスプリントプランニングに入るべき理由を5つ挙げています。

  1. 見積もり
  2. 受入れ条件
  3. テストケース
  4. デバイス/ブラウザのカバレッジ
  5. 優先度付け

 この5つは、上で述べた見積もり工数、リスク、テスト観点に対するインプットになりそうです。
 4.だけちょっとドメイン特有に思えますが、より一般的には「どの程度のテストカバレッジを狙うか」ということですね。

 なおこの記事の前提は、「QAは通常、スプリントプランニングに入らないけれど・・・」なんですよね。自分の周りを見ている限り、スプリントプランニングにQAが入るのがごく当たり前のことのように思えます。

Some tickets in the sprint will also require advanced planning from QA. For example, they may need to write test cases, review design files, or ask followup questions. QA will be more prepared if they know which tickets are in a sprint from the beginning – instead of near the end.
スプリントにおいて、チケットによってはQAが事前の計画しておかないといけないことがある。たとえば、テストケースを書き、設計ファイルをレビューし、フォローアップの質問をしたりといったことだ。スプリントの終わりに近づいてからでなく、始めからチケットの内容を知っていれば、QAはしっかり備えることができるだろう。

 some ticketというか、ほとんどの開発チケットについて、QAの計画って必要じゃないでしょうか・・・?

おわりに

 以上、とりあえず自分の思いで書き出してみました。テストの自動化についての情報は、また別のチケットになるのかな。

 すでに実績あるチケットテンプレなどあるかもしれないのですが、うまく検索できず。
 「ここ読んでから来いや!」という素敵な情報源があれば、教えてください。
 いやそもそも、テスト計画書の規格を読み直せって話かな・・・。

*1:この時点で怒られそうで怖い。

*2:この記事では、QAとテスターが使い分けられているのか同じ意味で使っているのか、よくわからない。

【翻訳】探索的テスト3.0 (再掲)

 ソフトウェアテスト界隈で探索的テストがビッグウェーブのようなので、便乗して過去の資産をリサイクルします!(ぬけぬけ)
 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は、手順化を一つの技法に格下げし、探索的テストをテストそのものであると格上げしたのである。

Macro Mondays | Queen