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

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

【翻訳】探索的テスト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

GIHOZを使って、30分間探索的テストを試してみる

 あさって12/17(木)の19:00から、「人類よ!これが探索的テストだ!テスト実況生中継で学びを深めよう!」というイベントがあります。

mabl-japan.connpass.com

 Intended Audience、人類ですからね。

今回は、QAエンジニア福田里奈さま(@_rina_ )をゲストにお招きして「探索的テストのライブテスティング」を開催いたします。
アジャイル・DevOps時代のテストや品質保証として注目される「探索的テスト」。ただ、モンキーテストと誤解されてしまったり、そもそもやり方を説明できる人が少なかったりするのではないかと感じていました。
そこで、専門家に探索的テストを実況生中継(ライブテスティング)していただきながら、探索的テストがいったいどういうもので、なにができて、何ができないのかを参加者と一緒に考えていき、「探索的テスト完全に理解した」を目指したいと考えております。

 われらがリナさん*1です。ハードルを最高まで上げての煽り、最高です。

 さて近年、探索的テストについての「にし仮説」が発表されました。

 わたし自身は探索的テストマスターではないどころか、自分でしっかりと取り組んだ経験にも乏しいので、探索的テストについて一家言もないです。
 ただポエムとしては、先日の記事として以下のように詠じておきました。
 個人的には、この3つ目が重要なのかなと思っています。

  • テストの目的として、「バグを見つける」と「品質を把握する」がある。
  • 「バグを見つける」目的は、怪しい箇所を素早く狙っていく探索的テストが有効に働きやすい。
  • 「品質を把握する」目的に対して、探索的テストは特定のエリアのテスト観点の導出につなげることができる。
  • スクリプトテストにおいても観点の導出は行うので、本質的に違いがあるわけではない。

www.kzsuzuki.com

 前置きが長くなりましたが、人類の一員としてあさって探索的テストを学ぶにあたり、自分でも探索的テストをやってみようと思い当たりました。
 対象は・・・ベリサーブさんが先月リリースしたテスト設計モデリングサービス・GIHOZです。

 さすがに自分のものでもないプロダクションサービスを勝手にテストをしてブログに書くほど荒くれものではないのですが、中の人がいいと言ってくれたのでいいのです! ふところひろし氏かよ・・・?

 先に断っておくと、このトライでバグは見つけていませんし、そもそも模範的な探索的テストの流れを見せられるわけでもありません。
 むしろどちらかといえば「幼稚な」思考過程をあからさまにすることになりそうですが、それは許してください。

準備

大方針

 まず、大方針を以下としました。

  • 1ポモドーロ・25分の中でやる。
  • 「同値分割」を対象とする。

 本当にバグを探ることが目的ではなく、勉強のためなので、時間を短く区切ります。
 また同じ理由で、機能として一番シンプルに見える「同値分割」をテスト対象としました。

チャーター

 GIHOZの同値分割では、パラメターの最小・最大を指定すると数直線が描かれて、その数直線上でのクリックで境界を指定するという直観的な操作ができます。
 ちょっと面白いふるまいとして、たとえば「0」と「5」の間をクリックして境界に値「10」を指定するとエラーになるというものがあります。数直線上の位置を判断しているということですよね。
 そういった振る舞いもあることから、このお絵かき部分を掘り下げてみることにしました。

 『Explore it!』的フォーマットで書くと、

Explore the feature for drawing a number line with various data to discover how the feature behaves.

って感じでしょうか。適当英語です。

実行

 この節では以降、引用符部分はその時点で考えたことです。

まずは普通の数字を入れて、典型的な動作を確認しよう。

 ということで、「普通の」数字を入れてみます。

f:id:kz_suzuki:20201215194525p:plain f:id:kz_suzuki:20201215194610p:plain

 特に問題なし。

オーソドックスに、変数の大小を逆転させてみる。

f:id:kz_suzuki:20201215194711p:plain

 想定通りのエラーで、問題なし。
 なお最大値=最小値でも「逆転」となったけど、ヨシ。

大きな数字を試してみる。

f:id:kz_suzuki:20201215194729p:plain

 最大桁はここまでのようです。
 これでお絵かきすると、丸図形の中に数字が収まらなくなるけれど、マウスオーバーで値を表示してくれるので問題ありません。

では、最大幅を確認する。

f:id:kz_suzuki:20201215194838p:plain

 入力OK。お絵かきも問題なし。

負の数としての最小じゃなくて、絶対値としての最小を後で、やろう。
先に増減幅の方が気になる。
まず、0.000...

f:id:kz_suzuki:20201215194901p:plain

 これ0と見なされ、正しく怒られます。

絶対値の最小を、増減幅で試そう。

f:id:kz_suzuki:20201215194919p:plain

 !?
 0.0000001と入力した瞬間、指数表記になる
 これはどういう動きなのでしょう。気になります。

これはいったんおいておいて、定義域最大、増減幅最小でお絵かきしてみる。

f:id:kz_suzuki:20201215194944p:plain

境界もキワキワにおいてみよう。

f:id:kz_suzuki:20201215194955p:plain

 これも通って正しくお絵かきできました。

ん? このように増減幅ギリギリに境界を設定すると、パーティションの上限下限が同じ値になって、図上で表現できなくなるのでは?*2
だけどこれは別に小数じゃなくても整数でも確認できるので、あとで。
上限側もやっておく。

f:id:kz_suzuki:20201215195011p:plain

 スクショはありませんが、これも正しく描画することができました。

この状態で、同値分割を出力してみよう。

 とっくにチャーターから外れてはいますが・・・。

f:id:kz_suzuki:20201215195021p:plain

 「値の範囲」を見て一瞬びくっとしましたけど、この「4」は、適当に付けたパラメター名でした。

この代表値はどうなってるんだ? これまでの感じだと、パーティションの上限と下限の真ん中に設定されていたと思うけど・・・。
負の数が入ると何か動きが変わるのか?
気になるけど、先にさっきの指数表記を触ろう。

 キャプチャはできませんが、「0.0000009」を「9e-7」にする(そして無効エラーが出る)だけでなく、「3e8」も「300000000」にされます

f:id:kz_suzuki:20201215195100p:plain

 途中まではこうなのですが、この次に「6」を入力すると急に受け入れてくれます。

f:id:kz_suzuki:20201215195110p:plain

 これは明示的に作り込んだ「機能」なのかはわかりません。
 実際にはプログラマーに質問して、意図しない挙動ならもう少し深掘りするのかなーと思いました。

 次に行きます。

ついでに、増減域広すぎパターンを見ておきたい。

f:id:kz_suzuki:20201215195123p:plain f:id:kz_suzuki:20201215195134p:plain

 何を入れても境界外になりますね。やってはみたものの、パラメターの仕様として通常ありえないはずなので、深掘りするところでもないでしょう。

刻みを中途半端にしても正しく計算できるかも確認しておく。

f:id:kz_suzuki:20201215195149p:plain f:id:kz_suzuki:20201215195201p:plain

 これも正しく計算できています。

ちょっと戻って、さっきの代表値算出を、負の数でやってみよう。

f:id:kz_suzuki:20201215195216p:plain

 特に問題なく、平均値になっている。

定義域がマイナス~プラスだとおかしくなったりする?

f:id:kz_suzuki:20201215195229p:plain f:id:kz_suzuki:20201215195240p:plain

やっぱり平均値になっているっぽいなー。・・・あれ!?

f:id:kz_suzuki:20201215195252p:plain

よく見たら、最大値と最小値が一桁違うじゃん・・・。

 そうなんです。正は、999,999,999。負は、-99,999,999。
 そりゃ平均値もプラス側にずれますよね。

 しかしやはり不思議な気もします。最大値と最小値の絶対値は、揃えるのが自然に思えるけど、何か意図があるのでしょうか。値そのものじゃなくて、マイナス記号含めて「文字列長」で値範囲が決まっているようにも見えます。
 これもプログラマーに聞いてみるやつでしょうかね。

 ここらでだいたい25分終了となりました。

やってみての感想

 探索的テストは、テスト対象を学習しながらテスト設計・実行していくものとされています。
 ですがこうやって過程を書き出してみると、(わたしの場合)思考が発散し、チャーターからも逸脱して、まったくシステマティックにならないことにあらためて気づきます。もちろん修練を積めばそんなことないのでしょうが。

 ただ今回のように、気になった点を都度メモっておくと、それをテスト観点として、いわゆるスクリプトテスト向けのテスト設計につなげられるのかなとも思います。
 今回でいうと、

  • 数字の桁数のコントロールってどうなってるのか。
  • 指数表記ってどういう期待動作になっているのか。

 あたりは、実装している人と話しながら、次のテストにつなげていくのかなーと。

 予習はこんな感じです。リナさんの探索を楽しみにしています!

Maze Wallpaper Green"Maze Wallpaper Green" by Tiger Pixel is licensed under CC BY-NC-ND 2.0

*1:なぜかアンダースコアが省略されていますが、ちゃんとTwitterアカウントにはリンクされています。

*2:実際にはこのように、同じ値を別の位置に描いています。特に問題ありませんでした。f:id:kz_suzuki:20201215195900p:plain

テスト設計モデリングツール・GIHOZと、テストプロセスのつながり方について

Circle of Life

 Veriserveさんからリリースされた、テスト設計モデリングツール「GIHOZ」のおためしを、2回の記事で紹介しました。

www.kzsuzuki.com www.kzsuzuki.com

 今回は、GIHOZへの期待と、テストプロセスのツールってこうなるのかなーという想像について書きます。

GIHOZ、こうなったらいいな!

 所詮は無課金ユーザの勝手な要求ではありますが、軽く触ってみての感想です。
 状態遷移テストにおけるイベント・トリガー以外の要素だとか、ペアワイズにおけるエイリアス・重みづけなど、個々の機能の「あったらいいな」もあるのですが、もう少し全体について、三つほど。

1. 「意図」を残したい

 ソースコードに、コードそのものだけでなく、人類向けのコメントを含めるように、テスト設計モデルにも設計意図を明示するためのコメントを残しておきたいです。

 たとえば同値分割で、同値パーティションで特定の値を「ひいきして」選んだ意図は何なのか。デフォルト値なのか、平均値なのか、ランダムなのか。
 あるいはペアワイズにおける制約について、対応する仕様は何を意味しているのか。
 テストとしての意図だったり、仕様についてのメモだったりを残せたらいいなと思います。

2. 「あともどり」をもう少し許容してほしい

 これは単にわたしがウカツなだけかもしれませんが、同値分割の境界設定や、ペアワイズにおける制約式/制約表の選択が、一度やってしまうと戻れないのが、せっかくのサクサク感をやや損ねていると感じます。修正させてほしい!

3. ヘルプが充実するとさらに嬉しい

 もちろん、GIHOZを動かすうえでの必要な情報は、今のヘルプでも整っています。
 そのうえでゼイタクをいえば・・・、
 今の内容はあくまでもGUIの操作方法。テスト設計技法はある程度理解している前提で、具体例+考え方+モデリング方法くらいまであると、とても有益だと思います。

ツールってこういう風につながっていくの?

 ツールチェーンとかいうとカッコいいのですが、また、適当なパワポお絵かきです。
 GIHOZのようなツールって、こんな風に位置づけるとかっこいいでしょうか?

f:id:kz_suzuki:20201129130730p:plain
※四角が成果物、丸がプロセスの、なんちゃってPFDです。

黄色枠: テスト設計モジュール

 GIHOZは、テストアーキテクチャ(というものがあるとして)に記述された観点に基づいて、テスト設計を行うのがこのモジュールです。GIHOZはここにあたりますね。モデルを描いて、そこからテストケースを導出するところまでを担当しています。

 なおVeriserveさんの場合、「TESTRUCTURE」というツールも提供しています(すみません、使ったことありません)。

www.veriserve.co.jp

  • STEP1: テストベースの理解・分析
  • STEP2: 階層的整理
  • STEP3: 詳細化対象の決定
  • STEP4: テストケースの作成

 以上のような機能をサポートしているということで、上の絵でいうと緑の部分までカバーしているのかも。またGIHOZは、TESTRUCTREの補助ツールという位置づけなのかもしれませんね。

オレンジ枠: テスト管理モジュール

 テストケースそのものや、その実行を管理するモジュールです。
 有名どころだと、Test Rail、PractiTest、Test Pad、TestLinkなどがあります。

www.guru99.com

 Veriserveさんでいうと、Quality Forwardが対応するでしょうか(これも使ったことがなくてすみません・・)

www.veriserve.co.jp

 テスト設計モジュールから、テストケース*1を受け取り、テスト手順と組み合わせることで、手動で(も)行えるテストケースになります。
 ここで、テスト手順はデータ駆動テストの考え方に基づき、パラメタライズされている*2ことが期待です。上位からパラメタを受け取ることで、一つ以上の具体的なテストケースとして実体化されます。

 このようにできたテストケースの実行状況・実行結果までを管理することになります。
 なお、テストケースは、GIHOZでサポートしているようなテスト設計技法から導出されるものばかりではないことには留意が必要です。

青枠: テスト自動化モジュール

 テスト手順が標準化された記述になっていれば、キーワード駆動テストにつなげることができるでしょう。
 自然言語に近い形で記述されたテスト手順の各ステップをスクリプトに対応付けておくことで、テスト手順+スクリプト→実行可能な自動テストケースとなります。
 これによって、モデルの作成/変更→テストケースの実装→自動テストの生成→自動テストの実行 とつながるようになって幸せそうですよね。

 自動テストの生成と、その自動テストを何らかのトリガー*3で自動実行するところまでが、テスト自動化モジュールのお仕事ですかね。
 実行結果の管理もここで行うかもしれないし、テスト管理モジュールに統合するかもしれない。

ピンク枠: イシュー管理モジュール

 テスト実行の結果から、テストアーキテクチャを洗練させていくことになります。
 たとえば、テストケースの目的とは違うところで欠陥が発見されたなら、それを新たなテスト観点として還元し、反映するでしょう。あるいはプロダクト要因でなくテストの誤りでテストがコケた場合は、その誤りをモデルから修正する必要があります。

 まあ、こんな感じでぐるぐる回るとかっこいいよね!というお話です。
 絵のキレイさを優先しているので、細かいことは気にしないでいただきたい!

連携のための標準化

 さらに妄想です。
 ツール間の情報のやりとりのために、二つの標準化を行う必要があります。ここでは、TDMP と、MTCP と呼んでおきます。言いたいだけです。

TDMP(Test Design Modeling Protocol)

 TDMPは、テスト設計モデルの記法に基づいて作成されたモデルの情報を、ツール間・プロセス間で受け渡しするための標準形式です。
 入口は二つ考えられます。

 一つ目は、仕様・設計からのインプットです。上の絵でいうと、「Spec Model」がテスト設計モジュールに入ってくるところですね。
 設計段階で作られたモデルをテストの入力情報として受け取り、テスト側でそれをテスト設計モデルとして拡張して、テストの生成につなげていく。あるいはその過程で得られた知見を設計側にフィードバックします。

 二つ目は、他のモデリングツールからの/へのインプットです。
 テスト設計モデリングをするためのツールはGIHOZに限らず登場すると思いますが、あるツールで作成したモデルがそのツールでしか使えないというのは辛過ぎます。データ形式を標準化し、ツール・サービスの乗り換えが容易にできると幸せそうです。

MTCP(Model-based Test Case Protocol)

 MTCPは、テスト設計モデルから生成されたテストケースの情報を、ツール間で受け渡しするための標準形式です。
 生成されるテストケースの形式は、テスト設計技法ごとに異なります。状態遷移テストであれば、最低限「前状態」「トリガー」「後状態」がセットになりますし、デシジョンテーブルテストであれば条件部のパラメタ値の組み合わせと、動作部のパラメタ値の組み合わせというセットになります。これを明示し、受け取り側が理解できるようにする必要があります。

 MTCPによるデータの受け取り手は、テスト管理ツールです。上の絵でいうと、「Test Cases」がテスト管理モジュールに入ってくるところです。上位からのインプットは、前回差分の情報を持ってくれていると嬉しい。あるいはそれはテスト管理モジュールのお仕事なのかな?

 ええ、なんか、プロトコルって書くとカッコいい気がしてそういう名前にしましたが、別に通信規約ってわけでもないので、変ですね。まあいいか・・・。

おわりに

 GIHOZを触ったおかげで、たくさんの妄想を膨らませることができました。本当にありがとうございます。
 こういうことをいい加減に書いたり描いたりするのは簡単ですが、実現はすごく難しそうで、でも楽しそうですよね。
 効果的・効率的で、同時にワクワクするテストをしたいので、それを支援してくれるVeriserveさんを応援しています!

*1:最終的に実行可能なレベルまで具体化するのを、どのタイミングで行うべきかは議論したい。

*2:たとえばログイン画面における「ユーザ名」「パスワード」が変数になっているイメージです。

*3:プロダクトやテスト設計モデルの更新などを想定しています。

Veriserveのテスト設計サポートサービス、GIHOZを触ってみる - その2

The Model.

 Veriserveさんがリリースしたテスト設計モデリングツール*1「GIHOZ」について、前回記事の続きです。

www.kzsuzuki.com

 残り3つの機能も触ってみましょう。

gihoz.com

今回は「デシジョンテーブルテスト」「状態遷移テスト」「ペアワイズテスト」の3つが、どんな感じで動くのかを紹介します。
 全体の所感と、わたしが勝手に期待していることは、次の記事に書きます。

デシジョンテーブルテスト

 今回も、『練習帳』の問題を使ってみます。ブログ記事はこちらです。

www.kzsuzuki.com

 仕様の概要は以下の通り。

  • 通常、1杯490円で提供されます。
  • 16:00から17:59まではハッピーアワーのため、1杯290円で提供されます。
  • クーポンを使うと、利用時間にかかわらずはじめの1杯のみ100円で提供されます。
  • ハッピーアワーでもクーポンは利用できます。
  • その時点で最も安い価格で提供されます。 1杯目のビールの価格を表すデシジョンテーブルを作成してください。

 「条件」にあたるパラメターは、「利用時間」「クーポン有無」になりそうですね。
 「動作」は、「金額」でいいでしょう。

 GIHOZでの初期画面はこれです。

f:id:kz_suzuki:20201128120528p:plain

  各セルは直接入力が可能です。

f:id:kz_suzuki:20201128120559p:plain

 条件を入力し、それに対する値を入力。また次の条件を入力、・・・と進めていきます。
 動作も同じですね。

f:id:kz_suzuki:20201128120617p:plain

 また他人とお作法が違うかもしれないので書いておきますが、わたしはテストケースを横に展開する前に、条件と値を書き出します。みんなそうだよね!?

 さて、ここから各値のY/Nを入力して、テストケースにしていきます。

f:id:kz_suzuki:20201128120635p:plain

 ハイフンが入っているセルで、「Y」「N」「-」のいずれかを選んでいきます。
 条件と値を決めたらY/Nの全組み合わせが自動生成され、ユーザはそれを剪定していくのかな?と想像していましたが、そうではないですね。

f:id:kz_suzuki:20201128120652p:plain

 Y/Nを入力したのが、1~4です*2

 テストケース#5は、「1つの条件で2つ以上の値がYになったらどうなる?」という観点。
 テストケース#6は、「Y/Nの割り当てが同一のテストケースがあったらどうなる?」という観点。
 後者については、期待通り、テストケース重複の警告が出ています。

f:id:kz_suzuki:20201128120704p:plain

 挿入や削除は、セル上の右クリックから。
 テストケースの上にある「有効/無効」は、同値クラスの有効無効とは関係なくて、以下の2つの目的で利用すると想定します。

1. 実施しない組み合わせを落とす。

 たとえば、そもそもありえない組み合わせを対象外にする。
 ヘルプで言及されているのも、この使い方です。

2. デシジョンテーブルの「簡単化」を表現する。

 これはわたしの勝手な使い方かも。
 たとえば仕様として、利用時間が「16:00から17:59の場合は一律100円」とするのであれば、Y/Nと有効/無効を以下のように修正することになります。
 また、ハイフンを「N/A」(どちらでもよい)の意味で使っています

f:id:kz_suzuki:20201128120718p:plain

 さて、ここまで作って気づいたのですが、「条件」部と違って、「動作」部は階層構造化できません。
 動作の方も、複数のパラメタを指定したいことありそうだけどなー。たとえば「金額」と、「お通し有無」とか。

 とりあえずは、金額を入力していきます。

f:id:kz_suzuki:20201128120728p:plain

 完成しました。
 同値分割/境界値分析と違って、ここから、各条件の値を指定した具体的テストケースへ落とし込むわけではないですね。

 ともあれ、直観的にテーブルを作っていけるツールに仕上がっています!

状態遷移テスト

 状態遷移テストについては、白紙からのスタートは厳しいということか、

f:id:kz_suzuki:20201128120736p:plain

 みんな大好きストップウォッチの状態遷移図がすでに描かれています。

f:id:kz_suzuki:20201128120744p:plain

 で、描いた状態遷移図に基づいて、スイッチカバレッジを指定してテストケースを自動生成します。  0スイッチと1スイッチを選択して生成してみましたが、とても速いです。

 まず状態遷移表。
 状態×イベントの形式と、状態×状態の形式、両方が生成されます。

f:id:kz_suzuki:20201128120754p:plain

 生成した状態遷移表の空きセルには、ignorecan't happen が選択できます。astah*と同じですね。
 この2つの値の意味については、この記事にメモしています。

www.kzsuzuki.com

  • ignore: 当該イベントが発生しても、発生しなかったように扱う。
  • cannot happen: 当該イベントは発生しえない。

似ているように見えますが、前者は「イベントが発生しうる」、後者は「イベントが発生しえない」ので、根本的に違いますね。

 なお、遷移すべき「状態」を入力して、状態遷移図に反映させるということはできません。図から表への一方通行です。

 ちょっと操作方法が直観的でないのが2つあったので、メモしておきます*3

1. 遷移図上のオブジェクトの削除は、[Delete] ボタンで。

 右クリックしてもメニューは出ません。

2. 自己遷移は、状態オブジェクトの端っこをドラッグアンドドロップ。

 「+」ボタンだと、自動的に別の「状態」も描かれてしまうので、「自己遷移はサポートしていない!?」と思いましたが、そんなはずありませんでしたね。ただちょっと操作は慣れが必要そう。

 まだおぼつかないですが、

f:id:kz_suzuki:20201128120803p:plain

 以下の記事で書いた例で、遷移図を描いてみました。

www.kzsuzuki.com

 1スイッチカバレッジのテストケースを生成!

f:id:kz_suzuki:20201128120813p:plain

 きれいに生成されました。

 表じゃなく図なので操作には慣れが必要ですが、すんなり描けますね。
 現時点で描けるのは状態と遷移のみなので、アクションなどの要素もサポートされるとさらに夢が広がる。

ペアワイズテスト

 こちらも初期画面で、サンプルが表示されます。

f:id:kz_suzuki:20201128120831p:plain

 ・・・が、なんかよくわからん!? ディスクフォーマットのテストでしょうか。
 「因子」「水準」という独特の用語は使わず、「パラメタ」「値」としています。

 『練習帳』の問題4.5.2のの仕様。

  • メタボ検診と婦人科検診は、年齢が35歳以上の人のみ選択できる
  • 脳検診は、年齢が45歳以上の人のみ選択できる
  • 婦人科検診は女性のみ選択できる

 これを適用していくと、

f:id:kz_suzuki:20201128120840p:plain

 このようになります。これもやはり、Excelのようにサクサク入力できます!

 なおここでやらかしたのですが、「保存」しないで「←一覧」を押すと、警告なしで一覧画面に戻ってしまいます・・・。

 次に、パラメタ間の「制約」を定義していきましょう。

f:id:kz_suzuki:20201128120853p:plain

 ここからパラメタ間の制約を追加していくのですが、ここで注意!

f:id:kz_suzuki:20201128120901p:plain

 ここで「制約表」「制約式」のどちらかを選ぶと、その後に選択し直す方法がありません*4
 今回はPictMasterでもおなじみの、表形式での制約入力をしてみます。

f:id:kz_suzuki:20201128120910p:plain

 PictMasterでは、IF にあたるパラメターのセルを色塗りするのですが、GIHOZではパラメタごとに制約を書く仕組みですね。
 年齢が20、34の場合は、任意追加項目で「メタボ検診」「婦人科検診」を選択できないという制約を、

f:id:kz_suzuki:20201128120917p:plain

 適当に書いてみました。

f:id:kz_suzuki:20201128120928p:plain

 適当に書いたらエラーになりました。

 このエラー内容を見ると、IF の部分は「20, 34」という1つの値として解釈されているのと、THEN の方も「メタボ検診か婦人科検診のどちらかと異なる」と解釈されていることがわかるので、修正します。

f:id:kz_suzuki:20201128120938p:plain

 おそらくですが、制約の表現の仕様として

  • IF に当たる部分は、値を1つだけ書ける。
  • THEN にあたる項目に複数の値を書くと OR で結ばれる。

となっているので、条件をばらして書いてあげる必要がありそうです。意図した通りの制約になっているかを確認したいので、できればこの制約表に対応する制約式が、エラーじゃないときも見えるようになれば・・・!

f:id:kz_suzuki:20201128120947p:plain

 制約を一通り埋めてみました*5

 さて、これでもエラーが出ます。

f:id:kz_suzuki:20201128120955p:plain

 よく見たら、「婦人科検診」を「婦人科」と書いていました。警告の意味は今回の場合、「任意追加項目が『婦人科』となる組み合わせが1つもない」ということです。定義されていない値が制約に入っているために起きるエラーです。
 これを修正して再度、組み合わせを生成すると、

f:id:kz_suzuki:20201128121003p:plain

 エラーなしできんと生成されました!

 GIHOZのせいではないですが、制約の書き方とそのエラーに慣れる必要がありそうですね。

*1:とわたしは呼んでいる。

*2:ヘルプを見ると、Yだけを入力し、それ以外はハイフンという使い方になっている。Nの使い道がわからない。

*3:両方ともヘルプに描かれている。ちゃんと読もう。

*4:正確には、わたしには見つけられませんでした。

*5:年齢に関する制約の可読性が悪いので、# で排除するのではなく、選択できるものを列挙することで制約をシンプルにできるかも。でもそれだと、今度は仕様との比較で面倒になる。

Veriserveのテスト設計サポートサービス、GIHOZを触ってみる - その1

 Veriserveさんが、テスト設計技法を使うためのWebサービスをリリースしたと聞いて!
 GIHOZ(ギホーズ)というそうです。

www.veriserve.co.jp

 さっそく触ってみましょう。
 推奨ブラウザがわからないので Edge 87.0.664.41 で試してみます*1

GIHOZを動かしてみる

 初期画面です。
 真っ白だと不安になりますが、そこに「+」ボタンがあると急に安心しますね。これを押せば何か始まるだろうという。

f:id:kz_suzuki:20201121201331p:plain

 「+」ボタンを押すと、現時点でサポートされている4つのテスト設計技法の選択画面に移ります。
 現時点では、以下の4つのテスト技法がサポートされているようです。

  • ペアワイズテスト
  • デシジョンテーブルテスト
  • 状態遷移テスト
  • 境界値分析

f:id:kz_suzuki:20201121201229p:plain

 今回は、境界値分析から行ってみましょう。
 題材として、ブログでも扱った『ソフトウェアテスト技法練習帳』の「1.12 配達便の料金体系」で適用してみることにします。

 問題の概要はこちらもご覧ください。

www.kzsuzuki.com

テスト設計モデルの作成

 境界値分析の初期画面はコチラ。

f:id:kz_suzuki:20201121201235p:plain

 まずテスト設計モデル*2の名前を入力します。
 「数直線」はプレースホルダーっぽく見えますが、キャプションです。

 一瞬、何から始めればいいか迷いますが、「変数の追加」でしょう。
 問題に合わせて、荷物の「大きさ」から入力していきます。

f:id:kz_suzuki:20201121201240p:plain

 「値の増減幅」で、立ち止まってしまうかもしれませんね。
 この問題では、大きさと重さという連続的な値を扱っており、精度を考える必要がありそう*3ですが、ひとまず「1」としています。

f:id:kz_suzuki:20201121201244p:plain

 いや、まだ入力途中だから怒らないでくれw

 「確定」すると、数直線が描かれます。
 この薄青の帯の上にカーソルを当てると、そこに境界値を打てる。

f:id:kz_suzuki:20201121200221p:plain

 なるほど、まず最小と最大を指定して*4範囲の全体を描いたうえで、その範囲内に境界値を刻んでいくという手順なのですね。
 わたし自身は、下から順に範囲を考えていくという手順をとっていることに気づきました。そうか、こういう手順もあるのか。

 仕様に沿って、「境界を追加」*5しています。

f:id:kz_suzuki:20201121213427p:plain f:id:kz_suzuki:20201121201256p:plain

 なお、帯の0と60の間を選択して、「80」を入れようとすると、エラーになります。

 どこをクリックしても、入力に合わせて適切な位置に絵を描くという仕様がいいか、あくまでも選択した領域に対応した値のみを受け付けるという仕様がいいか。
 前者の方が便利そうですが、入力ミスを防ぐという意味では後者の方がいいのかも。何せ境界値分析は、「境界でバグりやすい」という傾向を前提にした技法なのですから、入力ミスによる誤った設計も予防できるとよさげです。

 荷物の「重さ」の方も入力して、パーティションの名前も編集すると、以下のようになります。
 パーティションの有効無効も切り替えられます。グレーの帯部分が、無効パーティションです。

f:id:kz_suzuki:20201121201300p:plain

 なお、境界を修正する方法がわかりません。

f:id:kz_suzuki:20201121201328p:plain

 「境界を削除」したうえで、再度追加する仕様でしょうか。
 最小値と最大値は削除もできなさそうなので、変数追加の最初の時点で注意しておく必要があるかも。

テストケースの導出

 ともあれ、これでテスト設計モデルができました。
 「同値パーティション一覧を表示」ボタンで、各パーティションと代表値が表形式で導出されます。

f:id:kz_suzuki:20201121201305p:plain

 さらに「テストケースを生成」ボタンで、同値分割と境界値分析のテストケースが生成されます。

f:id:kz_suzuki:20201121201309p:plain f:id:kz_suzuki:20201121201313p:plain

 一見編集不可のテーブルに見えますが・・・、

f:id:kz_suzuki:20201121201318p:plain

 編集できます*6
 モデルから導出できない部分は手動で埋めて、テストケースとする *7わけですね。

 なお、導出&編集したこのテーブルは、CSVで出力することができます。

f:id:kz_suzuki:20201121201323p:plain

所感

 GIHOZの「境界値分析」機能を使ってみました。

 テスト設計モデルからテストケースを導出するこのようなツールを使うことで、テスト設計のモデルとテストケースを常に同期させることができます。そこから得られるメリットは、たとえば以下です。

  1. プロダクトの仕様変更を、モデルを通してテストケースに反映することができる
  2. テストの十分性を、個々のテストケースではなく、モデルから検証することができる

 状態遷移表、ペアワイズ法、原因結果グラフなど、各技法に特化したツールもありますが、GIHOZのように複数のテスト設計技法を扱えれば、テスト設計モデルを1つのツールで管理することができます。  モデルのバージョン管理他システムとの連携など、期待が広がるサービスですね!

 他の3つの技法についても、触ってみたいと思います。

*1:Firefox 82.0.3でアクセスすると、

ご使用のブラウザでは正常に動作しない可能性がございます。推奨ブラウザは こちら

となりました。

*2:GIHOZでは「テスト設計モデル」という言葉は出てこないのですが、わかりやすさのために以降、テストケースを導出するためのモデルのことをこう呼びます。

*3:『ソフトウェアテスト技法ドリル』ではこのような場合、幅を仮に「d」(differenceのことでしょう)と置いて、具体的な値は別途記述する、という方法を紹介しています。

*4:最大と最小は未入力にすることも可能です。

*5:「境界値」ではないところに、コダワリがありそう・・。

*6:モデルから導出した情報と、ユーザが補完した情報は、色分けした方がわかりやすい気がします。

*7:『練習帳』のこの問題では、大きさと重さを合わせて「サイズ」を判定しているので、テストケースと同値分割・境界値分析結果をマージしていくことになります。