Tokyoへ行ってきました。開催されてから幾分日があいてしまいましたが、得たことや思考のために残しておきます。昨年も2日目だけ行きました。テスト設計コンテスト(テスコン)について肩すかしを受けたという旨の文章を書いたところ、関係者と思われる数名からTwitterでリプライを頂きまして、テスト実施とバグ検出に重きを置くテスティングライブからテスト設計に重きを置くコンテストに移ったという歴史がわかりました。テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。読んだりなどしてみたので、今回はもうちょっと理解が進むだろうと踏んだわけです。理解が進むだろうというのは、テスコンもそうですが、もっと言うと「テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか?」について理解が進むだろうということです。タイムテーブルを見るとわかりますが、今回はセッションのサブタイトルがずいぶんくだけた感じになっていましたね。同じ時期に開催されるデブサミはちょっとずつ固くなっていると感じるのに対してJaSSTはやわらかくしていく方針なのでしょうか。1日目の基調講演、「ウェブよウェブウェブ」、「今夜ビジネスで比べてみました」の3つは聞きたかったのですが、普通に仕事してました。テスト設計コンテスト(テスコン)2日目お目当てのテスコンです。テストベースは今回も自動販売機のようです。テスコンのセッションは9:00から始まるのですが寝坊してしまったので9:30ごろに到着。1年4組の4チームでした。一応真剣に聞いてメモをとったつもりですが、時間の割にスライドの内容が濃くて理解し切れませんでした。プレゼンの後に展示されている成果物も読みましたが、どのように工夫したり苦労したりしたのかが読み取れないところもありました。つたない理解の中での印象ですと、しなてすが手堅く、TEVASAKIplusがオリジナリティと説得力を兼ね備えていると思いました。テスコン参加の説明会ではTest.SSFのプロセスが紹介されるそうですが、TEVASAKIplusの説明にはそれらしい言葉が無く、テスト対象の設計・構造の理解を重視し、機能タイプの分類・脆弱性の発見・悪条件の導出をするという方法は理解しやすく、効果もありそうだと感じました。全ての思考の起点が機能なのは問題があるのではないかとも思いました。テストタイプによって思考の起点が機能かどうかって異なりません?まぁ、自動販売機の場合はそれで良いのかもしれませんが。あと、しなてすのプレゼンに対して「テストアーキテクチャが低凝集・高結合になっているのではないか?」という質問があったのが印象的でした。仮にテスト設計にアーキテクチャがあってクラス図のような箱と線で表せたとして、ソフトウェアの設計のように高凝集・低結合が良いのだろうか?と考えさせられました。そのような原則があるのであれば、テスト設計についても七つの設計原理(富士通)みたいなものがあるのかもしれませんね。*2テストに何が求められるのかをテストベースを分析して求めるプロセスと、テスト設計技法を使ってテストケースを求めるプロセスの間に、何か工夫をするプロセスがあった方が良く、それはテスターにとってのmaintainabilityとも言うべきテストの品質を確保するために行うプロセスだというのは直観的にはわかるのですが、それをテストアーキテクチャ設計と呼ぶのが良いのかはよくわからないんですよね。テスコンに出場してる方々は理解しているのでしょうか。*3おっと、話がそれてしまいました。結果、優勝はしなてす、次点はTEVASAKIplusでした。原則を覆えすことに挑む*6」とか、「レガシーコードを解析して期待値を自動的に生成する*7」といった一歩先を行っていると感じる内容でした。計算機にできることを増やして、人間しかできないことにフォーカスしようという思想が見えるようで好感度大です。プレゼンの中で「テストにおいて人間にしかできないことが減っていくと、テスト技法よりもテスト対象や欠陥の知識が要求されるようになる。」と言われていましたが、先進的な技術をさんざん述べた後でなぜわざわざ当たり前のことを言うのだろう?と疑問に思いました。して世のテスターの多くはテスト対象の理解や欠陥の知識が不十分でありながらテスト技法の知識だけはあってテスト活動を行っているのでしょうか。したら憂慮すべきことかと思います。言葉は非常にしっくりくるクロージングパネルではデベロッパーとテスターの関係についてパネルディスカッションが行われました。出した図を見て目が覚めました。直観的にしっくりくるものだったからです。上の図は私のメモから起こした図なので間違っている可能性があるのですが、こんなような図でした。時計回りに読めばわかるでしょう。弧を描く複数の矢印の半径の違いは、恐らくテストレベルが高いほどマインドセットを切り替えたりテストで得られたことを開発に活かすのが難しいことを表しているのでしょう。自分が書いたコードの間違いにユニットテストで気づいて直すことよりも、受け入れテストレベルにおけるユーザビリティテストで「これはイケてないな」ということがわかって、それを開発にどう活かすのかを見出すことの方が難しい、ということを表しているのだと思います。テスターとは何をする役目なのか、という話もありました。曰く、「テスターにはコードを書く権限も、予算を決める権限も、採用や解雇をする権限も、リリースの判断をする権限もない。テスターは何ができるのか。プロダクトのクオリティを明らかにすること、認識できるようにすることだ。