この記事は、日本中のテストエンジニアが集う冬のイベント、JaSST⁠’15 Tokyo（ソフトウェアテストシンポジウム 2015 東京）のレポートです。マイケル・ボルトン氏の基調講演を中心に報告します。13回めとなるJaSST Tokyoは2月20、21日に東洋大学白山キャンパスで開催されました。

私はJaSSTには2004年から不定期にスピーカーとして参加していますが、今年は聴講者として参加しました。私が参加したJaSSTの中でも一、二を争う楽しいイベントとなりました。

ASTERと学びの機会

JaSSTはASTER（ソフトウェアテスト技術振興協会）が主催しています。ASTERはテストに関わる人々の地位の向上、学習の機会の提供を目的にさまざまな活動をしています。ASTERの主な活動は、JSTQBの運営、各地方での教育の支援、シンポジウムの開催、テスト開発方法論などの先端技術の研究開発、IEEEシンポジウムの誘致などなどです。

国際的なテストの知識体系と認定資格にISTQBがあります。この日本版がJSTQBです。JSTQBの運営の大きな目的は、ISTQBのシラバスを日本語に訳し無料で配布すること。そしてこれを使って、テストエンジニアが（職場で、あるいは個人で）勉強できるようにすること、次に認定資格を取ることによってテストエンジニアのキャリアアップの助けになることです。

資格取得よりも資料を提供するのが目的というのは素敵ですね。JSTQBは私の周りの人たちも受験／取得しており馴染みがありました。しかし、ASTERにこのような意図があったことは知りませんでした。JSTQBシラバスを使ってみなさんも学習を始めてはいかがでしょうか。なお、日本ではアドバンスドレベルの合格率が低いそうです。これは問題が難しく設定されているため、とのことでした。

基調講演 ─“How To Get What You Want From Testing”

JaSST Tokyoの基調講演は毎年外国人スピーカーを招待しています。ソフトウェアテスト界隈にはいろいろな派閥（スタイル？）がありますが、その中から毎年バランスが取れるようにスピーカーを選んでいます。毎年参加されている常連の方には、開催のたび「色」が違うことに気づくかもしれません。今年はマイケル・ボルトンさん。とても熱い基調講演でした。

「How To Get What You Want From Testing (for Testers, Developers, and Managers) あなたの欲しいものはどうやってテストから手に入れるか? ～テストエンジニア、開発者、マネージャのために～」この長いタイトルがマイケル・ボルトンさんの基調講演です。

講演は「私はシンガーではありません」という、おそらく定番の導入からはじまりました。テストエンジニア、開発者、マネージャのために、テストについてなにを知っておくべきか、彼の提唱したRapid Software Testingなどからのアイデアを説明しました。本レポートでは、たくさんのアイデアの中から、主だったいくつかを報告したいと思います。

おかしなソフトウェアとFeeling

彼の見つけた「おかしなソフトウェア」が紹介されました。

aircanada.comの例（This flight inclues a stop in null.）はいわゆるバグかもしれません。nullが含まれていると表示されていますがこれをユーザに見せてどうするのでしょう。

またHywatt Regencyの例ではWiFi利用料金が1日ずつより2日間の方が割高になっています。仕様通りかもしれませんが、利用者は混乱します。ほかにもたくさんの「おかしなソフトウェア」を見せてもらいました。

これらのおかしなソフトウェアにもテストが行われていたはずです。テスターはどうしてこれでいいと思ったのでしょうか。マネージャはどうでしょう。これでいいと思ったのはなぜでしょう。これらのソフトウェアには共通点があります。ソフトウェアは秩序立てて作られたのに、大切なものが欠けているのです。

「あれ？この製品、どこかが悪い気がする…」テスターは直感で気づくことができます。このソフトウェアは退屈だな、不親切だな、どこか使いにくいな…そういったフィーリングが大切です。それはなにか悪いものがあることを示しています。

これはソフトウェア製品に対してだけでなく、プロセスなど、あちこちで使えます。ボルトンさんは聴衆に問います。

「テストが退屈と感じるときがある人は？」

退屈と感じる… それはなにか悪いことが起きているのです。たとえばテストを重要じゃないと思っている、そう感じるなにかがある、といった具合です。

フィーリングは、製品のみならず、自分たちの開発そのもの（もちろんテストも含みます）のやり方についても、問題のシグナルとなるのです。

ダッシュボードの問題

メトリクスに固執してしまう問題があります。ダッシュボードの計器ばかり見て外を見ないような状況です。自動車を運転している時、窓が見えないのと、ダッシュボードが見えないのならどっちがましでしょう。数字は重要ですが、数字で表せることばかりではありません。窓の外を見て運転しましょう。

残念ですが、数えやすいものに魅力に感じ、惹かれてしまうことはありませんか。たとえば、テストケース数や合格数の多さに固執してしまうなど。しかし、数字はいくらでもごまかせてしまいますし、実態を反映しないこともあります。

なぜテスターはテストケース数ばかり気にしてしまうのでしょうか。マネージャーが尋ねるからでしょうか？マネージャはなぜ尋ねるのでしょう？テスターが答えるから？聞きやすいから、答えやすいから、そうなってしまうのでしょう。ここには無限ループがあるようです。たしかに、いろいろなメトリクスが形骸化するのはこういった状況、心理からくるのかもしれません。

こういう場面にも「おかしいな」と感じたいですね。

CheckingとTesting、もう一度Feeling

CheckingとTestingの違いは、ここ数年、よく耳にするテーマです。ボルトンさんもこの違いに触れていました。Checkingは、その名の通りチェックです。動かしてみて本当にそうなるかどうかを確認します。Checkingに必要なのは観察と判断の規則です。いわゆるテストケースを使って正解と比較するのはこのCheckingです。Checkingはどちらかというと機械的な作業で、コンピュータができるものもあります。もしかすると、プログラマがやるべき領域かもしれません。

Checkingに全て合格しても、それで本当に大丈夫でしょうか。ボルトンさんはこんなたとえを話していました。

機械的な確認、判断の規則では、社会的コンテキストまでは理解できないのです。

先の「おかしなソフトウェア」もCheckingは合格していたかもしれませんが、ユーザを混乱させる、不安にさせる、こういった問題を見逃しています。マネージャもテスターも、社会的なコンテキストへの配慮が足りなかったのではないでしょうか。Checkingに合格するだけではダメなのです。

一方、Testingとは社会的な目的・コンテキストを理解し、問題を見つける行為です。コンピュータサイエンスだけでなく、社会学、人類学も含みます。Testingは人間にしかできません。Testingは探索、発見、調査、学習のプロセスであり、フィードバックと適応の繰り返しです。

ヘッドライトのメタファもありました。

製品の状態についてわかっていることと、知らなければならないことの間にはギャップがあります。Testingの目的は、この「わかっていない領域」を狭めることです。Checkingはおそらくわかっていることの領域の確認ですね。

基調講演での発見

2011年のJaSSTの基調講演でもCheckingとTestingの違いについての言及がありました。

私はこのアイデアが大好きで、自身の講演で何度も引用しました。Checkingは既知の問題を確認すること、Testingは新しい問題を見つけ出すこと、と表現されていました。前者は機械的な作業でちょっと退屈です。人間でもできますが自動化向きでコンピュータが代わりにできるものもあるでしょう。これに対し、後者は創発的で人間にしかできません。

テストは単に信頼性を確かめるためものではありません。信頼性はプログラマが作るのです。テスターはプログラマの作った信頼性を疑い、問題や過信を見つけるのです。

では、Testingを実際にどうやるのか。私にはうまく説明できませんでした。そこで探索型テストなどちょっと高度そうなものを例としてあげていましたが、ボルトンさんの「フィーリングを大切にする」という説明は素敵でわかりやすく、次の機会では真似しようと思いました。

たしかに私たちのチームでも「ちょっと変かも？」という感覚を大切にしています。テスターが「なにかおかしいかも」と投げかければ、みんなが集まってどうおかしいのか考えはじめます。探索する、というより、たしかにフィーリングに導かれてる感じがします。「⁠ちょっと変かも？」は製品がおかしいこともありますが、テスターが間違っていることもあります。その場合はテスターが学ぶ機会になります。いずれにしてもフィーリングを大切にすることはお得なのです。

そうそう。フィーリングを大切にするということはテスターの役割というより、テスター（に限りませんが）からの問いかけを受け止めるチーム全体の態度です。

さいごに ─今年のJaSST

今年のJaSSTで変化を感じたのは「テスター」という言葉の扱いです。

以前は「テスター」を「テストエンジニア」と言い換えていた記憶があります。「⁠テスター」という言葉のもつ語感が、どこか機械的な作業をする人のような印象を与えていたからなのでしょうか。

今年は基調講演でも「テスター」のまま訳されていました。ようやく日本でもボルトンさんの言うテスターのような役割が認知されてきたからかもしれませんね。

クロージングで明らかにされた今年のJaSSTのテーマは「百貨店のようなJaSST⁠」⁠。多くの人に来て欲しい、常に上質で新しいものを創造し、さまざまなシーンで役に立つ、そんなテーマです。その狙い通り、定番のセッションから、自動テスト、アジャイル、いろいろなパネル、テスターとデベロッパの関係まで、さまざまなプログラムがあったと思います。

4月にはJaSST'15 Niigata、5月にはJaSST'15 Tohokuが開催されます。どちらも興味深いテーマが用意されており、JaSST Tokyoとはまた違う発見があるでしょう。

あー、楽しかった。