JaSST'15 Tokyo 感想 - 昨年よりは理解が進んだと思いたい
JaSSTソフトウェアテストシンポジウム-JaSST'15 Tokyo
へ行ってきました。2日目だけです。開催されてから幾分日があいてしまいましたが、得たことや思考のために残しておきます。
昨年も2日目だけ行きました。テスト設計コンテスト(テスコン)について肩すかしを受けたという旨の文章を書いたところ、関係者と思われる数名からTwitterでリプライを頂きまして、テスト実施とバグ検出に重きを置くテスティングライブからテスト設計に重きを置くコンテストに移ったという歴史がわかりました。
JaSST '14 Tokyo 感想 - テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。 - MassKaneko.Out
前回から1年経ったわけですが、その間に私はJSTQB FLの勉強をしてみたり*1、SQiPやJaSSTの論文を読んでみたり、昔の雑誌 を読んだりなどしてみたので、今回はもうちょっと理解が進むだろうと踏んだわけです。理解が進むだろうというのは、テスコンもそうですが、もっと言うと「テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか？」について理解が進むだろうということです。
タイムテーブルを見るとわかりますが、今回はセッションのサブタイトルがずいぶんくだけた感じになっていましたね。同じ時期に開催されるデブサミはちょっとずつ固くなっていると感じるのに対してJaSSTはやわらかくしていく方針なのでしょうか。1日目の基調講演、「ウェブよウェブウェブ」、「今夜ビジネスで比べてみました」の3つは聞きたかったのですが、普通に仕事してました。無念。
テスト設計コンテスト(テスコン)
2日目お目当てのテスコンです。テストベースは今回も自動販売機のようです。テスコンのセッションは9:00から始まるのですが寝坊してしまったので9:30ごろに到着。見ることができたのはT研, しなてす, TEVASAKIplus, 1年4組の4チームでした。
一応真剣に聞いてメモをとったつもりですが、時間の割にスライドの内容が濃くて理解し切れませんでした。プレゼンの後に展示されている成果物も読みましたが、どのように工夫したり苦労したりしたのかが読み取れないところもありました。
つたない理解の中での印象ですと、しなてすが手堅く、TEVASAKIplusがオリジナリティと説得力を兼ね備えていると思いました。テスコン参加の説明会ではTest.SSFのプロセスが紹介されるそうですが、TEVASAKIplusの説明にはそれらしい言葉が無く、テスト対象の設計・構造の理解を重視し、機能タイプの分類・脆弱性の発見・悪条件の導出をするという方法は理解しやすく、効果もありそうだと感じました。ただ、全ての思考の起点が機能なのは問題があるのではないかとも思いました。テストタイプによって思考の起点が機能かどうかって異なりません？まぁ、自動販売機の場合はそれで良いのかもしれませんが。
あと、しなてすのプレゼンに対して「テストアーキテクチャが低凝集・高結合になっているのではないか？」という質問があったのが印象的でした。仮にテスト設計にアーキテクチャがあってクラス図のような箱と線で表せたとして、ソフトウェアの設計のように高凝集・低結合が良いのだろうか？と考えさせられました。もしそのような原則があるのであれば、テスト設計についても七つの設計原理(富士通)みたいなものがあるのかもしれませんね。*2
テストに何が求められるのかをテストベースを分析して求めるプロセスと、テスト設計技法を使ってテストケースを求めるプロセスの間に、何か工夫をするプロセスがあった方が良く、それはテスターにとってのmaintainabilityとも言うべきテストの品質を確保するために行うプロセスだというのは直観的にはわかるのですが、それをテストアーキテクチャ設計と呼ぶのが良いのかはよくわからないんですよね。テスコンに出場してる方々は理解しているのでしょうか。*3
おっと、話がそれてしまいました。結果、優勝はしなてす、次点はTEVASAKIplusでした。おお、私の目に狂いは無かった！*4
テクノロジーセッション：ソフトウェアテストの新潮流
「自然言語解析・人工知能・機械学習といった技術を用いたシステムの補助により、従来はベテランの経験が無いと勘付けなかったようなテストを、初級・中級者でも行えるようになる*5」とか、「昨今の計算機性能の発達により、"全数テストは不可能" の原則を覆えすことに挑む*6」とか、「レガシーコードを解析して期待値を自動的に生成する*7」といった一歩先を行っていると感じる内容でした。計算機にできることを増やして、人間しかできないことにフォーカスしようという思想が見えるようで好感度大です。
プレゼンの中で「テストにおいて人間にしかできないことが減っていくと、テスト技法よりもテスト対象や欠陥の知識が要求されるようになる。」と言われていましたが、先進的な技術をさんざん述べた後でなぜわざわざ当たり前のことを言うのだろう？と疑問に思いました。もしかして世のテスターの多くはテスト対象の理解や欠陥の知識が不十分でありながらテスト技法の知識だけはあってテスト活動を行っているのでしょうか。そうだとしたら憂慮すべきことかと思います。
クロージングパネル：Michael Bolton の言葉は非常にしっくりくる
クロージングパネルではデベロッパーとテスターの関係についてパネルディスカッションが行われました。エモい話とか組織論とかテスターを持ち上げる話なのかとボーっと聞いていましたが、Michael Bolton が出した図を見て目が覚めました。直観的にしっくりくるものだったからです。開発をするときのマインドセットとテストをするときのマインドセットの変化らしく、Critical Distance と題されていました。上の図は私のメモから起こした図なので間違っている可能性があるのですが、こんなような図でした。上下左右4つの文は、何かしら開発やテストをしたことがある人であれば、右の build some of it から時計回りに読めばわかるでしょう。そして、弧を描く複数の矢印の半径の違いは、恐らくテストレベルが高いほどマインドセットを切り替えたりテストで得られたことを開発に活かすのが難しいことを表しているのでしょう。例えば、自分が書いたコードの間違いにユニットテストで気づいて直すことよりも、受け入れテストレベルにおけるユーザビリティテストで「これはイケてないな」ということがわかって、それを開発にどう活かすのかを見出すことの方が難しい、ということを表しているのだと思います。
テスターとは何をする役目なのか、という話もありました。Michael Bolton 曰く、「テスターにはコードを書く権限も、予算を決める権限も、採用や解雇をする権限も、リリースの判断をする権限もない。ではテスターは何ができるのか。プロダクトのクオリティを明らかにすること、認識できるようにすることだ。」とのことです*8。これも納得です。うなずきながら聞いていました。決して期待値と出力を人力でベリファイするロールではないんですね。また、クオリティはどのロールが責任を持つのかという話もあり、デベロッパーだけでもテスターだけでもないという意見がありました。これも同意です。日本では「テスト・品質系」というくくりで職種や技術が語られることがありますが、あれには非常に違和感があります。だからSQiP2014のデベロッパー参加比率が低いのではないかと考えてしまいます。*9
あと、ささいなことかもしれませんが、ゲーム業界のパネリストの方がテストのことを「デバッグ」と呼んでいたのは非常に気になりました。JaSSTとは全く別の機会で他のゲーム業界の方も同じように「デバッグ」「デバッガー」という言葉を使っているのを聞いたことがあるので、ゲーム業界の習慣なのかもしれませんね。
Tester と テスター
先の話でテスターという言葉を使いました。もちろん Michael Bolton はカタカナではなく Tester という言葉を使っています。両方同じ意味と捉える方もいれば、違うでしょ？と思う方もいると思います。私は、日本と海外(どこの国々なのかはわからないが)の違いとして
- Tester：プロフェッショナル、エキスパートのニュアンス。
- テスター：システムテスト実行の人海戦術要員のニュアンス。
というニュアンスの違いを感じています。昨年のデブサミでDeNAの方が「テスターじゃない、テストエンジニアだ。」と語っていましたのを思い出します。*10
日本のソフトウェア開発現場で全体的にこのような認識がなされているのかはわかりませんが、もしそうだとすればテスト技術やテスターは(Tester であったとしても！)軽視されてしまうでしょう。
テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか？
実際に東洋大学の講堂を埋め尽くす人が集まっているのに何を言っているのかと思われるかもしれませんが、1年前の自分はそう思っていました。また、テスト専門の会社があることを初めて知ったときは非常に驚いた覚えがあります。テスト技術を多少勉強したり、WACATEに2回参加した後の今でも「なんだか不思議だなぁ」と思うところがあります。これについて少し考えてみます。考えるというか、深層心理を吐き出しているだけで整理ができておらず、専門家やテストが好きな方から見ると気分を害すかもしれません。
- QAとかテスターとかその辺の人々による内輪感がある。品質を確認する側、管理する側の立場の人、SEPG、コンサルタント、研究者に偏っている気がする。
- QAとかテスターとかその辺の人々が単にテストと言うとき、暗黙的にシステムテスト以上のテストレベルを指していると感じる。
- 「どのようなプロダクトを作りたいのか？」という前提を全く共有しないままテストの話で盛り上がっているのを見ると空論に聞こえることがある。モデリングが好きなだけで何を作るかあんま興味無いんじゃないか、だとか。
- バグを見つけるのが楽しいという感覚が全く理解できない。
- 社会科学や心理学的な側面の話が多く、計算機やプログラミングっぽい匂いがしないと感じることがある。
これらは私の勉強不足による誤解かもしれませんし、単に趣向の違いかもしれませんし、もしかするとJaSSTなどの世界にとってまずいことかもしれません。1番目は結構まずいんじゃないかなと勝手に思っています。
とりあえず最近の自分にできそうなこととしては、次回のWACATEにデベロッパーを呼ぶことや、「テスターは刺身タンポポ業じゃないんだよプロなんだよ」と説くことですかね。
以上、JaSST'15 Tokyo の感想でした。昨年よりは理解が進んだと思いたいものです。
*1:合格しました
*2:しなてすには「テスト設計に凝集度や結合度なんてありませんよ」と真正面から跳ね返すロックな返答をして欲しかったのだが、そうはならなかった。
*3:もちろん決勝出場メンバーは理解して論を打ち立てているのだと思いますが、各チームがそれぞれテストアーキテクチャとは何なのか、どう表現できるのかを説明したときに、果たしてそれは同じ概念を指しているのだろうかと疑問に思ったりするわけです。
*4:前回もこんなことを書いたような…
*5:単に仕様書を食わせてあいまいな箇所を見つけるだけのツールなら以前からあった気がするので、これはもっと進んだことをやっているのだと思う。
*6:英語で Exaustive Testing と言うらしい
*7:本来ブラックボックステストで扱われるような期待値の推定のように聞こえたが自信なし
*8:通訳された発言を解釈して書いているので正確ではないかもしれません。
