特に研究者に多いが、ソフトウェアテストと聞くとプログラムのホワイトボックステストを思い浮かべる人が多い。もちろん1970年代前半はそうだったのかもしれないが、現在は違う。
テストと似たような活動に、レビューやインスペクションがある。バグを見つけるという意味では、形式検証もあるだろう。この際、メトリクスを測定する活動も含めてしまおう。これらは、プロジェクトの様々なフェーズにおいて、様々な手段で、様々なソフトウェアの特性を調べる活動と考えることができる。これをここでは、評価と呼ぶことにしよう。
そう、テストとは、ソフトウェア評価のうち、ソースコードの出現後に実施される動的検証という、一つの手段を意味する。でもまぁ、この分類にはあまり意味はない。
意味があるのは、こうした評価の活動には全て分析・設計が必要だという点である。言い替えると、評価開発になるかな。プログラムを開発することと同じくらい、評価項目や評価手段の設計というのは難しいのだ。だから、頭を使って方法論を構築し“開発”すべきである。
仲でも、評価戦略の策定は重要だ。開発しようとしているソフトウェアにおいて評価すべき特性にはどのようなものがあり、どのような手段、どのような単位で測定できるのか。各評価手段は、どのように棲み分けて、補完しあうのか。それらが製品価値にどのようにつながっていくのか。こうした評価戦略を決めないといけないのだ。しかも上流でね。
ソフトウェア開発の現場では、評価活動全体を俯瞰的に捉えている場合はあまりないだろう。しかし開発項数の5割以上を評価に割いており、評価工数が足りない足りないと騒ぐのであれば、評価を俯瞰的に捉えて“開発”すべきである。そうしないから、評価工数が爆発したり、評価漏れで不具合が市場に流出するのだ。
テストの方法論は、最終的に評価開発の方法論に昇華すべきだし、しなくてはならないだろう。その第一歩として、テスト戦略を立ててテストレベルやテストカテゴリに分割してみるとよい。慣れてきたらレビューの観点を加え、形式検証、メトリクスと増やしていけばよい。
我々メソドロジストも、評価全体を視野に入れて方法論を構築しないとね。これはなかなかチャレンジングだが、楽しい作業だと思う。
2007-09-05
Tech-On!:「あなたの行っているテストに戦略はあるか」
Tech-On!の記事で取り上げられました。僕はアロハで写ってますね。大森さん、ありがとうございます。
いろいろと改善点はありましたけど、このテスト戦略ワークショップを発展させて、全国行脚するつもりです。参加者の皆さんに当日書いていただいたテスト戦略は、ヒマを見て電子化してアップロードします。少々お待ち下さい。
ところで、テスト戦略をシーケンス図で描くなんて言ったかなぁ．．．。逆に考えれば、描けちゃうのかなぁ。少し考えてみようかしら。
いろいろと改善点はありましたけど、このテスト戦略ワークショップを発展させて、全国行脚するつもりです。参加者の皆さんに当日書いていただいたテスト戦略は、ヒマを見て電子化してアップロードします。少々お待ち下さい。
ところで、テスト戦略をシーケンス図で描くなんて言ったかなぁ．．．。逆に考えれば、描けちゃうのかなぁ。少し考えてみようかしら。
2007-07-28
マインドマップから始めるソフトウェアテスト勉強会のマインドマップ
先日技術評論社さんのテストプレスVol.5の企画で、池田さんと鈴木さんの書いた「マインドマップから始めるソフトウェアテスト」の勉強会に顔を出した。帯を書いた手前もあり冷やかしのつもりだったのだが、せっかくだからとマインドマップを書いてみた。ちなみに、生まれて初めてのマインドマップ。
このマインドマップは、勉強会の講評のために作ったものである。テストにマインドマップを使うことの利点を、マインドマップでまとめている。皆が勉強会をしている裏で、せこせこホワイトボードに描いてたのよね。でも、楽しかったなぁ。
mixiでは、秋山さんに「マインドマップじゃなくて連関図だよね」と言われたが、生まれて初めてなので仕方がない。この後マインドマップに目覚め、アイデア出しと一次整理はマインドマップを使うようになった。MindManagerも買ったしね。
内容については、他のエントリでまったり解説する予定。期待はしないこと。
2007-07-25
European Test Centre
福井さんから"European Test Centre"というWebサイトを紹介される。厳密にはAQCtion!という一風変わったカンファレンスを紹介してもらったのだが、ともあれ面白そうなドキュメントが掲載されているのでメモ。Bogdan Bereza-Jarocińskiという人がやっているみたい。
2007-07-16
探索型テストを紹介する理由
ちょっと探索型テストを日本に紹介してみようと思う。まぁLessons Learned in Software Testing（邦訳：ソフトウェアテスト293の鉄則）に紹介されているが、例えば次回のJaSST'08東京で改めて紹介してみてもよいかな、と思っている。というわけで、関連するWebの翻訳や要約でもしてみるか、と思う次第。とりあえずWikipediaのエントリを翻訳。
訳してみて思うが、とても誤解を導きそうな技法であることは間違いない。この技法（というか思想）は、James BackやDanny Faughtのようなスゴ腕のテスト技術者だからこそ成功するものであり、テストの基礎すらも分かっていないテスト作業者では単なるアドホックテスト、もしくはモンキーテスト以下のものにしかならない、という点をしっかり理解しておく必要がある。Wikipediaにも書かれているが、記述型テストでガッチリ設計し、さらに突っ込みたい部分を探索型テストで補うという使い方以外はあり得ない。全て探索型テストで済ませるというのは、自殺行為である。各レベルのテスト工数のせいぜい20%以下に留めておかないと、品質の保証からはほど遠い結果になるだろう。
そんなリスキーな技法であるにも関わらず紹介したいと思っているのは、テスト技術者に職人的なキャリアパス、もしくは憧れがあってもいいのではないか、と思うからである。記述的なテスト設計をきっちりできる一級建築士もクールだが、探索型で短時間に重大なバグをバンバン見つける腕の良い棟梁もカッコイイではないか。そんなイメージで読んで欲しい。
訳してみて思うが、とても誤解を導きそうな技法であることは間違いない。この技法（というか思想）は、James BackやDanny Faughtのようなスゴ腕のテスト技術者だからこそ成功するものであり、テストの基礎すらも分かっていないテスト作業者では単なるアドホックテスト、もしくはモンキーテスト以下のものにしかならない、という点をしっかり理解しておく必要がある。Wikipediaにも書かれているが、記述型テストでガッチリ設計し、さらに突っ込みたい部分を探索型テストで補うという使い方以外はあり得ない。全て探索型テストで済ませるというのは、自殺行為である。各レベルのテスト工数のせいぜい20%以下に留めておかないと、品質の保証からはほど遠い結果になるだろう。
そんなリスキーな技法であるにも関わらず紹介したいと思っているのは、テスト技術者に職人的なキャリアパス、もしくは憧れがあってもいいのではないか、と思うからである。記述的なテスト設計をきっちりできる一級建築士もクールだが、探索型で短時間に重大なバグをバンバン見つける腕の良い棟梁もカッコイイではないか。そんなイメージで読んで欲しい。
2007-07-15
Exploratory testing: Wikipedia
適当訳シリーズ。WikipediaのExploratory testing。
Exploratory testing is an approach in software testing with simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.
探索型テスト（Exploratory testing）は、ソフトウェアテストの設計と実施、そして学習を同時に行うアプローチである。テスト技術者は、テストを実施しながら、経験や創造性と共に新たに良いテストを思いつける能力を身につけていく。
History: 歴史
Exploratory testing has been performed for a long time, and has similarities to ad hoc testing. In the early 1990s, ad hoc was too often synonymous with sloppy and careless work. As a result, a group of test methodologists (now calling themselves the Context-Driven School) began using the term "exploratory" seeking to emphasize the dominant thought process involved in unscripted testing, and to begin to develop the practice into a teachable discipline. This new terminology was first published by Cem Kaner in his book Testing Computer Software. Exploratory testing can be as disciplined as any other intellectual activity. thats it
探索型テストは、昔から行われてきた。アドホックテスト（ad hoc testing）に似ている。1990年代前半、アドホックテストはいい加減で注意の足りない作業のことだと考えられることが非常に多かった。それに対し、"Context-Driven School"と称するテストメソドロジストのグループが「探索型」という用語を用いるようになった。あらかじめテスト項目を決めておかないからこそ必要となる思考プロセスを強調し、かつ勘や経験から伝承可能な技術にするのが目的である。この新しい用語はCem Kanerの"Testing Computer Software"（邦訳：基本から学ぶソフトウェアテスト）が初出である。探索型テストは、他の取り組みや技法と同じように、いい加減なものではない。
Description: 内容
Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The testing is dependent on the testers skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.
探索型テストは、ソフトウェアが実際のところどのように振る舞うのか、ソフトウェアが複雑なテストケースや単純なテストケースをどのように扱うのかを調べるために実施する。探索型テストの良し悪しは、テストケースを作り不具合を見つけるテストエンジニアのスキルに依存する。テストエンジニアがテスト対象について知っており、また様々なテスト技法を使うほど、探索型テストは良いものとなる。
To further explain, comparison can be made to the antithesis scripted testing, which basically means that test cases are designed in advance, including steps to reproduce and expected results. These tests are later performed by a tester who compares the actual result with the expected.
もっと説明するのであれば、探索型テストと対照的な存在となる記述型テストと比較するとよい。記述型テストは、基本的には、再現するために必要な操作手順と期待結果をテストケースとし、事前に設計しておくテストを意味している。設計と同時に実施されるのではなく、設計した後に実施され、期待結果と実際の動作結果が比較される。
When performing exploratory testing, there are no exact expected results; it is the tester that decides what will be verified, critically investigating the correctness of the result.
探索型テストを実施する際には、きちんとした期待結果は必要ない。実施しているテストエンジニアが、実際の動作結果のどこを検証すべきなのかを判断し、特に重要だと思われるところは不具合が無いかどうか、しっかり調査する。
In reality, testing almost always is a combination of exploratory and scripted testing, but with a tendency towards either one, depending on context.
実際のところ、テストというものは、ほとんど必ず探索型テストと記述型テストの組み合わせとなる。しかしどちらに重きを置くかは状況によって異なる。
The documentation of exploratory testing ranges from documenting all tests performed to just documenting the bugs. During pair testing, two persons create test cases together; one performs them, and the other documents. Session-based testing is a method specifically designed to make exploratory testing auditable and measurable on a wider scale.
探索型テストのドキュメントは、実施したテストを全て記録するような場合から、見つけたバグだけを記録する場合まで様々である。ペアテスト（pair testing）を実施する場合、テストの設計は2人で行い、片方が実施しつつもう片方がドキュメントを作成する。セッションベースドテスト（Session-based testing）は、探索型テストできちんと測定し監査するためのテストプロセスである。
Benefits and drawbacks: メリットとデメリット
The main advantage of exploratory testing is that less preparation is needed, important bugs are found fast, and is more intellectually stimulating than scripted testing.
探索型テストの主なメリットは、記述型テストに比べ、準備が少なく済み、重要なバグが早く見つかり、かつ知的な刺激が得られることである。
Disadvantages are that the tests can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.
デメリットは、事前にテストケースのレビューができないこと（およびソースコードやテストケースの誤りが予防できないこと）と、どんなテストケースが実施されたのかを正確に表すのが難しくなりうることである。
When repeating exploratory tests, they will not be performed in the exact same manner, which can be an advantage if it is important to find new errors; or a disadvantage if it is more important to know that exact things are functional.
逆に正確に同じ方法で探索型テストを繰り返せないということは、新しいバグを見つけることが重要な場面ではメリットになりうるし、機能的に正確な記述がより重要な時はデメリットになる。
Usage: 使い方
Exploratory testing is extra suitable if requirements and specifications are incomplete, or if there is lack of time. The method can also be used to verify that previous testing has found the most important defects. It is common to perform a combination of exploratory and scripted testing where the choice is based on risk.
探索型テストは、要求や仕様が不完全だったり、時間が無い時には極めて有用である。また、それまでのテストで検出しておくべき重大なバグを見つけられているかどうかをチェックしたい場合にも用いられる。探索型テストと記述型テストの組み合わせは、品質リスクを基にして判断するのが普通である。
An example of exploratory testing in practice is Microsofts verification of Windows compatibility.
探索型テストは、MicrosoftがWindowsの互換性テストに使ったという実例がある。
Exploratory testing is an approach in software testing with simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.
探索型テスト（Exploratory testing）は、ソフトウェアテストの設計と実施、そして学習を同時に行うアプローチである。テスト技術者は、テストを実施しながら、経験や創造性と共に新たに良いテストを思いつける能力を身につけていく。
History: 歴史
Exploratory testing has been performed for a long time, and has similarities to ad hoc testing. In the early 1990s, ad hoc was too often synonymous with sloppy and careless work. As a result, a group of test methodologists (now calling themselves the Context-Driven School) began using the term "exploratory" seeking to emphasize the dominant thought process involved in unscripted testing, and to begin to develop the practice into a teachable discipline. This new terminology was first published by Cem Kaner in his book Testing Computer Software. Exploratory testing can be as disciplined as any other intellectual activity. thats it
探索型テストは、昔から行われてきた。アドホックテスト（ad hoc testing）に似ている。1990年代前半、アドホックテストはいい加減で注意の足りない作業のことだと考えられることが非常に多かった。それに対し、"Context-Driven School"と称するテストメソドロジストのグループが「探索型」という用語を用いるようになった。あらかじめテスト項目を決めておかないからこそ必要となる思考プロセスを強調し、かつ勘や経験から伝承可能な技術にするのが目的である。この新しい用語はCem Kanerの"Testing Computer Software"（邦訳：基本から学ぶソフトウェアテスト）が初出である。探索型テストは、他の取り組みや技法と同じように、いい加減なものではない。
Description: 内容
Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The testing is dependent on the testers skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.
探索型テストは、ソフトウェアが実際のところどのように振る舞うのか、ソフトウェアが複雑なテストケースや単純なテストケースをどのように扱うのかを調べるために実施する。探索型テストの良し悪しは、テストケースを作り不具合を見つけるテストエンジニアのスキルに依存する。テストエンジニアがテスト対象について知っており、また様々なテスト技法を使うほど、探索型テストは良いものとなる。
To further explain, comparison can be made to the antithesis scripted testing, which basically means that test cases are designed in advance, including steps to reproduce and expected results. These tests are later performed by a tester who compares the actual result with the expected.
もっと説明するのであれば、探索型テストと対照的な存在となる記述型テストと比較するとよい。記述型テストは、基本的には、再現するために必要な操作手順と期待結果をテストケースとし、事前に設計しておくテストを意味している。設計と同時に実施されるのではなく、設計した後に実施され、期待結果と実際の動作結果が比較される。
When performing exploratory testing, there are no exact expected results; it is the tester that decides what will be verified, critically investigating the correctness of the result.
探索型テストを実施する際には、きちんとした期待結果は必要ない。実施しているテストエンジニアが、実際の動作結果のどこを検証すべきなのかを判断し、特に重要だと思われるところは不具合が無いかどうか、しっかり調査する。
In reality, testing almost always is a combination of exploratory and scripted testing, but with a tendency towards either one, depending on context.
実際のところ、テストというものは、ほとんど必ず探索型テストと記述型テストの組み合わせとなる。しかしどちらに重きを置くかは状況によって異なる。
The documentation of exploratory testing ranges from documenting all tests performed to just documenting the bugs. During pair testing, two persons create test cases together; one performs them, and the other documents. Session-based testing is a method specifically designed to make exploratory testing auditable and measurable on a wider scale.
探索型テストのドキュメントは、実施したテストを全て記録するような場合から、見つけたバグだけを記録する場合まで様々である。ペアテスト（pair testing）を実施する場合、テストの設計は2人で行い、片方が実施しつつもう片方がドキュメントを作成する。セッションベースドテスト（Session-based testing）は、探索型テストできちんと測定し監査するためのテストプロセスである。
Benefits and drawbacks: メリットとデメリット
The main advantage of exploratory testing is that less preparation is needed, important bugs are found fast, and is more intellectually stimulating than scripted testing.
探索型テストの主なメリットは、記述型テストに比べ、準備が少なく済み、重要なバグが早く見つかり、かつ知的な刺激が得られることである。
Disadvantages are that the tests can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.
デメリットは、事前にテストケースのレビューができないこと（およびソースコードやテストケースの誤りが予防できないこと）と、どんなテストケースが実施されたのかを正確に表すのが難しくなりうることである。
When repeating exploratory tests, they will not be performed in the exact same manner, which can be an advantage if it is important to find new errors; or a disadvantage if it is more important to know that exact things are functional.
逆に正確に同じ方法で探索型テストを繰り返せないということは、新しいバグを見つけることが重要な場面ではメリットになりうるし、機能的に正確な記述がより重要な時はデメリットになる。
Usage: 使い方
Exploratory testing is extra suitable if requirements and specifications are incomplete, or if there is lack of time. The method can also be used to verify that previous testing has found the most important defects. It is common to perform a combination of exploratory and scripted testing where the choice is based on risk.
探索型テストは、要求や仕様が不完全だったり、時間が無い時には極めて有用である。また、それまでのテストで検出しておくべき重大なバグを見つけられているかどうかをチェックしたい場合にも用いられる。探索型テストと記述型テストの組み合わせは、品質リスクを基にして判断するのが普通である。
An example of exploratory testing in practice is Microsofts verification of Windows compatibility.
探索型テストは、MicrosoftがWindowsの互換性テストに使ったという実例がある。
The Seven Basic Principles of the Context-Driven School
The Seven Basic Principles of the Context-Driven Schoolのサイト。テストに限った話ではないが、背景や流れをきちんと考えないと色んな取り組みや技法は意味無いよ、という宣言。Cem Kaner周りの活動ですね。これが発展してASTになるという感じかしら。ついでに、意訳してみました。ご参考まで。
- The value of any practice depends on its context.
背景や流れによって、取り組みや技法の価値は変化する。 - There are good practices in context, but there are no best practices.
背景や流れが同じであれば、取り組みや技法の間に良し悪しはある。しかしどんな背景や流れでも最適な取り組みや技法（ベストプラクティス）はありえない。 - People, working together, are the most important part of any project's context.
どんなプロジェクトでも、プロジェクトを一緒に進めている技術者の人間的側面こそが、最も重要である。 - Projects unfold over time in ways that are often not predictable.
プロジェクトはというのは、予測できない様々な理由で延びてしまうものだ。 - The product is a solution. If the problem isn't solved, the product doesn't work.
プロダクトというのはソリューション、すなわち問題解決の表現である。問題を解決せずにプロダクトを作ってしまっても、動くわけがない。 - Good software testing is a challenging intellectual process.
よいソフトウェアテストは、知的で挑戦的なプロセスである。 - Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
判断力や技術力が備わっていなければ、プロジェクト全体が調和するように気を配りつつ、効果的にテストできる時期や方法を適切に選ぶことはできない。
2007-07-14
2007-07-12
テストと心もしくは脳
僕にとって、なぜテストは魅力的なのか。もともとプログラムを書くのが3度のメシより隙だったし、プラモデルのようなモノづくりも大好きだった。今でも、ちょっとしたツールをperlで書くときは、妙にワクワクする。そんな僕が、なぜテストを生業にしているのだろう。
もちろん競走戦略的には、僕の持っているリソースと世の中の状況を考えると、テストを生業にするのが一番理にかなった戦略である。しかし、それ以外にテストは僕の心を引きつけてやまないものがあるのだ。
テストを上手に設計するには、2つの意味で人間の心もしくは脳を深く理解しなければならない。それは、人間が何かを良いと感じるのはどういうことなのか、という点と、人間が間違いを犯すのはどういうことなのか、という点である。
テストは最終的に、ステークホルダーが全て満足するかどうかを評価しなくてはならない。もちろんその一部はビジネス上の明確な数値で表せるだろうが、テストで一番大事な部分は、ユーザがテスト対象を「よい」と感じることである。であるならば、テスト設計で考えなくてはならないのは、ユーザはどんな人なのか、ユーザはどんな使い方をするのか、そしてユーザはどんな時にどんなことを「よい」と思うのか、である。そういったことを当のユーザ以上に理解していないと、質の高いテスト設計はできない。
その中で最も難しいのは、ユーザはどんなことを「よい」と思うのか、を理解することであろう。そもそも人間は、何を「よい」と思うのだろうか。物理的な特性で記述できることも多いだろうが、大事なのはそこではない。コカコーラは嫌いでペプシは好き、レクサスは嫌いでベンツは好き、それは多分、物理特性の違いではない。そのユーザが生きてきた文脈において、様々な明示的関連を持たない特性が主観的に認知されることによって、よいとかよくないとか判断されるわけだ。テストを極めるのであれば、そこまで到達すべきだと思う。それは心理学、社会学、認知科学、脳科学など、もっと人間をダイレクトに研究対象とする分野とのコラボレーションが必要である。
同様に難しいのは、ユーザはなぜ「間違う」のか、を理解することである。そもそも人間は、何を正しいと認識するのだろう。もちろんヒューマンエラーの研究などはあるが、もっと踏み込んだ何かが必要だと直感している。人間が（多くは物理的な）何かを操作する時に間違うという狭いものではなく、人間が何かを考えるときに間違うとはどういうことなのか、を研究する必要があるのだ。
だから我々の研究室では、最初の一歩として、頭の中の論理的構造物に対するアフォーダンス、名付けてロジカル・アフォーダンス（以前はプロダクト・アフォーダンスと呼んでいたが、この方がよいと思う）を研究している。ソフトウェア開発者は、それが機械語であろうがCであろうがUMLであろうが、プログラムもしくはソフトウェアを頭の中に3次元/多次元の構造物として認識しているはずである。その論理的構造物に対するアフォーダンス把握や応力計算ができれば、ある種の間違いは指摘可能になる。
梅田望夫さんとの対談をきっかけに、最近茂木健一郎さんの本を読み始めたが、彼の言うクオリアのようなものだろうか。1行1行は単なる命令に過ぎないソフトウェアが、様々な脈絡（茂木さんは偶有性と呼んでいる）を持つことによって、頭の中でありありと多次元の構造物となって立体的に存在するのである。開発者はその構造物に触ったり、グルグル回したり、いろんなところから眺めてみたり、中に入ってみたり、柱を叩いてみたりしながら、ソフトウェアを分析・設計・実装し、レビューしていくのだ。
もっと言うと、テスト設計も同じである。僕にとって、テストケースの集合体であるテストスイートは、頭の中で多次元の構造物になっている。それを2次元の平面に記述するツールがNGTであるし、その構造物には何らかの品質特性もあるだろう。我々の研究室では、そんなことも研究している。我々にとってテストとは、頭の中の構造物を評価するための観点の集合だが、その観点そのものも頭の中で構造物になっているのだ。
つまりテストとは、人間を理解することそのものに他ならない。人間であるユーザが何を「よい」と感じ、人間である開発者が何を「間違う」のか。その2つを理解するからこそ、本当に素晴らしいテストが可能になる。頭の中をこじ開けて、人間がものを捉える時にどのような構造物を頭の中に構築しているのか、を把握しないといけない。そのためには、テスト設計の時にもっと人間について深く考察することが必要だし、もっと心や脳の分野と一緒に研究していかねばらならないだろう。
人間だもの。だからこんなに面白いことは無いのだ。
もちろん競走戦略的には、僕の持っているリソースと世の中の状況を考えると、テストを生業にするのが一番理にかなった戦略である。しかし、それ以外にテストは僕の心を引きつけてやまないものがあるのだ。
テストを上手に設計するには、2つの意味で人間の心もしくは脳を深く理解しなければならない。それは、人間が何かを良いと感じるのはどういうことなのか、という点と、人間が間違いを犯すのはどういうことなのか、という点である。
テストは最終的に、ステークホルダーが全て満足するかどうかを評価しなくてはならない。もちろんその一部はビジネス上の明確な数値で表せるだろうが、テストで一番大事な部分は、ユーザがテスト対象を「よい」と感じることである。であるならば、テスト設計で考えなくてはならないのは、ユーザはどんな人なのか、ユーザはどんな使い方をするのか、そしてユーザはどんな時にどんなことを「よい」と思うのか、である。そういったことを当のユーザ以上に理解していないと、質の高いテスト設計はできない。
その中で最も難しいのは、ユーザはどんなことを「よい」と思うのか、を理解することであろう。そもそも人間は、何を「よい」と思うのだろうか。物理的な特性で記述できることも多いだろうが、大事なのはそこではない。コカコーラは嫌いでペプシは好き、レクサスは嫌いでベンツは好き、それは多分、物理特性の違いではない。そのユーザが生きてきた文脈において、様々な明示的関連を持たない特性が主観的に認知されることによって、よいとかよくないとか判断されるわけだ。テストを極めるのであれば、そこまで到達すべきだと思う。それは心理学、社会学、認知科学、脳科学など、もっと人間をダイレクトに研究対象とする分野とのコラボレーションが必要である。
同様に難しいのは、ユーザはなぜ「間違う」のか、を理解することである。そもそも人間は、何を正しいと認識するのだろう。もちろんヒューマンエラーの研究などはあるが、もっと踏み込んだ何かが必要だと直感している。人間が（多くは物理的な）何かを操作する時に間違うという狭いものではなく、人間が何かを考えるときに間違うとはどういうことなのか、を研究する必要があるのだ。
だから我々の研究室では、最初の一歩として、頭の中の論理的構造物に対するアフォーダンス、名付けてロジカル・アフォーダンス（以前はプロダクト・アフォーダンスと呼んでいたが、この方がよいと思う）を研究している。ソフトウェア開発者は、それが機械語であろうがCであろうがUMLであろうが、プログラムもしくはソフトウェアを頭の中に3次元/多次元の構造物として認識しているはずである。その論理的構造物に対するアフォーダンス把握や応力計算ができれば、ある種の間違いは指摘可能になる。
梅田望夫さんとの対談をきっかけに、最近茂木健一郎さんの本を読み始めたが、彼の言うクオリアのようなものだろうか。1行1行は単なる命令に過ぎないソフトウェアが、様々な脈絡（茂木さんは偶有性と呼んでいる）を持つことによって、頭の中でありありと多次元の構造物となって立体的に存在するのである。開発者はその構造物に触ったり、グルグル回したり、いろんなところから眺めてみたり、中に入ってみたり、柱を叩いてみたりしながら、ソフトウェアを分析・設計・実装し、レビューしていくのだ。
もっと言うと、テスト設計も同じである。僕にとって、テストケースの集合体であるテストスイートは、頭の中で多次元の構造物になっている。それを2次元の平面に記述するツールがNGTであるし、その構造物には何らかの品質特性もあるだろう。我々の研究室では、そんなことも研究している。我々にとってテストとは、頭の中の構造物を評価するための観点の集合だが、その観点そのものも頭の中で構造物になっているのだ。
つまりテストとは、人間を理解することそのものに他ならない。人間であるユーザが何を「よい」と感じ、人間である開発者が何を「間違う」のか。その2つを理解するからこそ、本当に素晴らしいテストが可能になる。頭の中をこじ開けて、人間がものを捉える時にどのような構造物を頭の中に構築しているのか、を把握しないといけない。そのためには、テスト設計の時にもっと人間について深く考察することが必要だし、もっと心や脳の分野と一緒に研究していかねばらならないだろう。
人間だもの。だからこんなに面白いことは無いのだ。
2007-07-11
Googleのテストエンジニアにならないか
Googleがテストエンジニアを募集してるのは知っているだろうか？アメリカのテストのカンファレンスにはGoogleがスポンサーしているし、CASTに来ていたHarry RobinsonやLydia Ashは、2人ともMicrosoftからの転職組のようだが、スゴ腕である。
彼ら（彼女ら）が、Google mapsやGoogle talkをテストしているわけだ。何となくGoogleのコードにはバグなんて無いだろう、テストなんて不要だろう、という思いこみがあったが、凄まじい量のテストをしているはずである。結構可愛いバグがあるのを紹介してもらった。経路探索のバグとかね。
例えばGoogle talkのテストというのは、開放型で漸化型の状態遷移テストに帰着できる。では、その状態モデルを書けるテストエンジニアが何人いるだろうか。いや、Google talkのテスト設計をこなせる（テスト以外の）エンジニアが日本には何人いるだろうか。
2人のチャットのテストなら書けるかもしれない。片方が待機中、呼び出し中、通話中、切断中の4状態くらいかな。もう片方も、状態としては同じ。イベントとしては、呼び出し、切断、ブラウザ終了だとしよう。さて、テストケースは何件になるでしょう。
マルチユーザチャットなので、これがどんどん増えていくわけだ。2人の場合はできましたか？これは頑張ればできるでしょう。3人の場合は？これも何とかできるでしょう。では4人は？5人は？100人は？
このテスト設計は、手動で行うと死ぬ。だからテスト設計をモデル化して自動生成しないとやってられない。だからHarry Robinsonの出番になるわけだが。CATSのツールでできるのかなぁ。今度穴田さんに聞いてみよう。
さて日本では、モバイル系のQAエンジニアというタイトルで、テストエンジニアを募集している。腕に覚えのある方はいかが。知り合いがGoogleでエンジニアやってるなんて、格好いいなぁ。
彼ら（彼女ら）が、Google mapsやGoogle talkをテストしているわけだ。何となくGoogleのコードにはバグなんて無いだろう、テストなんて不要だろう、という思いこみがあったが、凄まじい量のテストをしているはずである。結構可愛いバグがあるのを紹介してもらった。経路探索のバグとかね。
例えばGoogle talkのテストというのは、開放型で漸化型の状態遷移テストに帰着できる。では、その状態モデルを書けるテストエンジニアが何人いるだろうか。いや、Google talkのテスト設計をこなせる（テスト以外の）エンジニアが日本には何人いるだろうか。
2人のチャットのテストなら書けるかもしれない。片方が待機中、呼び出し中、通話中、切断中の4状態くらいかな。もう片方も、状態としては同じ。イベントとしては、呼び出し、切断、ブラウザ終了だとしよう。さて、テストケースは何件になるでしょう。
マルチユーザチャットなので、これがどんどん増えていくわけだ。2人の場合はできましたか？これは頑張ればできるでしょう。3人の場合は？これも何とかできるでしょう。では4人は？5人は？100人は？
このテスト設計は、手動で行うと死ぬ。だからテスト設計をモデル化して自動生成しないとやってられない。だからHarry Robinsonの出番になるわけだが。CATSのツールでできるのかなぁ。今度穴田さんに聞いてみよう。
さて日本では、モバイル系のQAエンジニアというタイトルで、テストエンジニアを募集している。腕に覚えのある方はいかが。知り合いがGoogleでエンジニアやってるなんて、格好いいなぁ。
CAST: Exploratory testing
出張に来たのはCAST（Conference of the Association for Software Testing）の出席が目的だ。今年も色々海外に行くが、一番楽しみにしているカンファレンスである。AST（Association for Software Testing）のカンファレンスだが、いわゆる学術系の学会ではないので、非常にプラクティカルである。
ASTは日本でも有名なCem Kanerが創立したもので、アメリカの有名なコンサルタントが多数参加している。ただしSQEとはつかず離れずといった感じのようで、Rex BlackやRick Craigはいない。まぁRexがいないのは資格制度に関するCemとの抗争のせいで、今頃イスラエルにいるからなのだが。CASTをISSTAやISTQBミーティングとぶつける（ISTQBが後に決まったのだが）あたり、欧米は欧米で色々大変なのね、という感じである。一応Lee Copelandが基調講演なのだが、そそくさと帰ってしまった模様だ。
CASTはJames BachやHarry Robinson、Danny Faught、Doug Hoffman、Robert Sabourin、Michael Boltonなど、スゴイ顔ぶれが揃っている。カンファレンスチェアのJon Bachは、James Bachの弟のようでビックリ。でも性格はあまり似ておらず、兄はラジカル、弟はジェントルで面白い。まぁチェアだから神経を使っていたのかな。見た目はブルーザー・ブロディみたいだけど。
どうもこの辺の人達の好みは、Exploratory testingとAutomationのようだ。テストエンジニアとしてプライドがあるので、Prescriptedな人手のテストをバカにする傾向がある。まぁ言われてみればそうだが。でも我が日本には、そんな偽装派遣のテストオペレータが多いのも事実であり、とても悲しむべき状況である。
Exploratory testingとは、テストエンジニアの高度な「鼻」を駆使して、テストを実施しながらバグの出そうな方向へどんどんシフトするというものだ。Ad hoc testingと混同しないように。ランダムではなく、あくまで高度な「鼻」を駆使する点が特徴的だ。あくまで雰囲気のことだが、アジャイルっぽい。
というわけで、日本のテストエンジニアを元気づけるべく、次回のJaSST東京ではExploratory testingの紹介でもしてみようかしら。Exploratory testingをマネジメントするために、Session-based testingというのもあるようだし。といっても、単に2時間くらいで区切るだけです。はい。
細かい定義ややり方については調べていくので、随時blogにアップします。するつもり。あくまで、つもり。
個人的には、Systematic testingとExploratory testingをどう融合してマネジメントするか、がポイントだと思う。Harry Robinsonに質問した時には、「Model-based testingのモデルをExploratoryに改善するんだよ」と言っていたが、単にExploratory testingをするだけでは品質保証はできない。Systematic testingでは、最高速かつ最高精度でバグ出しはできない。そのバランスが必要で、それが難しいのだ。
去年のJaSST東京ではModel-based testingの紹介をしたので、同じようにやればよいかな。でも、もう一人の事例発表はどうしよう。日本一のテストエンジニアって誰だろう．．．。多分、アジャイル風な雰囲気（決してアジャイル方面という意味ではない）がいいんじゃないかな。
そういう人、いませんか。心当たりがあったら、紹介してくださいまし。
ASTは日本でも有名なCem Kanerが創立したもので、アメリカの有名なコンサルタントが多数参加している。ただしSQEとはつかず離れずといった感じのようで、Rex BlackやRick Craigはいない。まぁRexがいないのは資格制度に関するCemとの抗争のせいで、今頃イスラエルにいるからなのだが。CASTをISSTAやISTQBミーティングとぶつける（ISTQBが後に決まったのだが）あたり、欧米は欧米で色々大変なのね、という感じである。一応Lee Copelandが基調講演なのだが、そそくさと帰ってしまった模様だ。
CASTはJames BachやHarry Robinson、Danny Faught、Doug Hoffman、Robert Sabourin、Michael Boltonなど、スゴイ顔ぶれが揃っている。カンファレンスチェアのJon Bachは、James Bachの弟のようでビックリ。でも性格はあまり似ておらず、兄はラジカル、弟はジェントルで面白い。まぁチェアだから神経を使っていたのかな。見た目はブルーザー・ブロディみたいだけど。
どうもこの辺の人達の好みは、Exploratory testingとAutomationのようだ。テストエンジニアとしてプライドがあるので、Prescriptedな人手のテストをバカにする傾向がある。まぁ言われてみればそうだが。でも我が日本には、そんな偽装派遣のテストオペレータが多いのも事実であり、とても悲しむべき状況である。
Exploratory testingとは、テストエンジニアの高度な「鼻」を駆使して、テストを実施しながらバグの出そうな方向へどんどんシフトするというものだ。Ad hoc testingと混同しないように。ランダムではなく、あくまで高度な「鼻」を駆使する点が特徴的だ。あくまで雰囲気のことだが、アジャイルっぽい。
というわけで、日本のテストエンジニアを元気づけるべく、次回のJaSST東京ではExploratory testingの紹介でもしてみようかしら。Exploratory testingをマネジメントするために、Session-based testingというのもあるようだし。といっても、単に2時間くらいで区切るだけです。はい。
細かい定義ややり方については調べていくので、随時blogにアップします。するつもり。あくまで、つもり。
個人的には、Systematic testingとExploratory testingをどう融合してマネジメントするか、がポイントだと思う。Harry Robinsonに質問した時には、「Model-based testingのモデルをExploratoryに改善するんだよ」と言っていたが、単にExploratory testingをするだけでは品質保証はできない。Systematic testingでは、最高速かつ最高精度でバグ出しはできない。そのバランスが必要で、それが難しいのだ。
去年のJaSST東京ではModel-based testingの紹介をしたので、同じようにやればよいかな。でも、もう一人の事例発表はどうしよう。日本一のテストエンジニアって誰だろう．．．。多分、アジャイル風な雰囲気（決してアジャイル方面という意味ではない）がいいんじゃないかな。
そういう人、いませんか。心当たりがあったら、紹介してくださいまし。
登録:
投稿 (Atom)