JaSST関西’18に行ってきた話（スポンサーセッション編）
基調講演編に続いてはテスト管理セッションとテスト設計セッションになります。
これらのセッションは2トラック×３コマになっていまして、計６コマのうち３コマを選択して聴講となります。
私の選択は以下でした。
- セッション 3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」
- セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」
- セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」
とその前に基調講演のあとにあったスポンサーセッションの話を少し。
基調講演後のスポンサーセッションは富士通さん、ベリサーブさん、JSTQBさんの３社でした。まず富士通さんですがINSTANTCOPYというスクリーンショット取得用のツールの紹介でした。
なんというか、ツールとしての需要は当然それなりにあるし、（賛否はともかくとして）テスト方面でいかにも使いそうではあるのですが、いかんせん基調講演の超洗練されたTDDのライブコーディングから「スクリーンショットを簡単に取得できてExcelテンプレートにはめこめますー」、という話が落差ありすぎて、「お、おぅ・・」という感じになりました。とはいうものの、スポンサー様のおかげで比較的リーズナブルな金額でありがたい講演が聴けるわけですし、スクショツールもある意味ソフトウェアテストの”リアル”なので（良いかどうかはもちろん別の話）そういうのを目の当たりにできるのもJaSSTのいいところかなぁ、と思います。ただこの順番はコントラストがキツすぎてちょっと残酷な感じでしたね・・・。
続きましてベリサーブさんのTESTRUCTUREなるテスト設計支援ツールの紹介でした。ツールの特徴はいくつかあるのですが、今回のセッションではトレーサビリティの確保が容易、という点を押しておられました。特にテスト設計の際に仕様書記載の要件を網羅するように設計しているのだが、時に抜けが発生してしまいヒヤリとするというエピソードを紹介されていました。このツールを使えばビジュアルに仕様書上にタグ付けして要件などを表示し、さらにそれに紐づけてテスト観点やテストケースをたどって行けるような雰囲気の紹介でした。さらにテストケースを自動生成（All-Pair法などを利用）する機能もあるそうです。観点や因子を指定すると組み合わせテストケースを生成する感じですかね？（さすがに手順などまで記載されたものを自動生成するわけではないですよね）ベリサーブさんのようないろんな会社からテストを受託してきてそれぞれのところの流儀があるようなところではこういうのに蓄積するのがいいのかもしれませんね。ウチはそこまでスケールしてない感じですね（設計者が少ない・・・）特許も取得しているということだそうです。（特許第6148362号、http://www.conceptsengine.com/patent/grant/0006148362 ）ちょっと読んでみましたが、仕様と観点を格納していてテスト生成機能があってそれらの関連がわかるように表示する、みたいな感じだったので、この手のツールだと何しても該当しちゃいそうな印象ですが、特許的にはどういう感じなのでしょうか・・・。
最後はJSTQBさんでした。いつものような感じで資格制度の説明と直近の話題としてシラバス（FL Agiletester、AL TechnicalTestAnalyst）の紹介でした。シラバスが世に放たれたとなると近日これらの資格認定試験もはじまるのでしょうか・・・。AL-TTAとったらAL完全有資格者になれるらしいのですが、ノンプログラマな私になんとかなるんやろか・・・。（まぁ職場じゃ ALとTMの区別を人事に説明するのが面倒すぎて人事データベースに登録することに挫折してしまいましたが。）ぼつぼつシラバス読んでいかないといかんですね。
スポンサーセッションだけでちょっとした長さになったのでこのへんにしておきます。
しかしまぁスポンサー様のおかげさまで比較的お安くありがたい話が聞けて感謝感謝ですね。
（一昔前は五千円でお弁当ついた上に日経コンピュータ1年購読がおまけとかものすごいお得イベントだったのですが、今でも1日5千円でたっぷりテスト話が聴けるイベントなんてなかなか無いのです。特に関西方面では）
JaSST関西’18に行ってきた話（基調講演編）
毎年のことなのですが、JaSST（ソフトウェアテストシンポジウム）関西’18に行ってきました。過去のプログラムを見ると2010年あたりから見覚えのある内容になっているのでかれこれ7-8年は通っていることになります。
なんでまた急にブログるのと言われると、電子化された予稿集を参照するために今年からノートPCを投入するようになったのと、その勢いではてなブログの開設手続きをやっちゃったからだったりします。正直なところ、ほぼ講演と同時進行で実況
はされてるし、多分すごい詳しいエントリとかも投稿されるんだとは思いますが、自分の感想の整理を兼ねてやってみようかなと。（多分小学生の作文みたいに、あとに行くほどしぼんでしまう感じになりそうだけど）
ということで早速基調講演の内容です。TDD（テスト駆動開発）で有名なt_wadaこと和田卓人さんの講演です。（後日資料公開あると言われていたのでそちらも参照ください）
ネットではライオンのAAが有名だそうで、実際”t_wada”でグーグル画像検索したら上位５位までライオンAAがでてきました。一種のなまはげみたいなもんとご本人もおっしゃっていました。「テスト書いてないとライオン来るよ」みたいな感じでしょうか。もちろんご本人の人格とは異なりますとのこと（そりゃそうですね）
あ、あと、今どきのモダンな開発では「テストコードを書いていない」ことはレビューをリジェクトする立派な理由になるんだそうです。「テストコード書いてきてから出直してね」というわけです。ウチの勤務先でもテストしてない、ってことはないにしてもテストコードを全部書いてるかというと多分そうじゃないと予想するので、世の中もうそこまで進んでるんだなーと思いました。
また、書籍「プログラマが知るべき97のこと」（監修）、「SQLアンチパターン」（監訳）、「テスト駆動開発」（翻訳）、そしてpower-assertというテストフレームワークなどを手がけられているそうです。（すいません開発しないのであまりよくわかっていません）
そして本題ですが、今回の基調講演ではTDDやってるところを聴衆に見せて、その上でソフトウェアテストとの接点を探りたい、ということでした。和田さんはJaSSTで講演されるのは2回め（以前にJaSST北海道で講演されたことがある）なんだそうですが、過去の講演で多かった質問が「TDDがなんなのかわからない」「やりかたがわからない」というものだったそうです。それに対する答えが「これからあなた方が目撃するものがTDDです」。うーん、カッコ良すぎですね。（より詳しくは書籍「テスト駆動開発」参照ということだそうです）私もたまーに社内で研修の講師やれよと言われますが「これからあなた方が目撃するものが○○です」とかよう言わん。講師自身がよくわかってないこともあるし（汗）
ということで、実際に講演でTDDがはじまります。ライブコーディングです。目の前でガリガリとコードとテストが書かれていきます。このあたり、自分が開発経験ないので、うまく表現できませんが、ガサゴソとネット検索してみたら、以下が見つかりました。
23:00付近からのデモを見れば講演時のライブコーディングがどんな様子だったのかを感じていただけると思います。
細かい話は私にはわからないところもあるので、概念としてこれはと感じたあたりを以下列挙です。
- 要求を箇条書きにし、さらに表現をそろえつつ「一撃」（ひとくちサイズ）できる粒度に調整していくところ
これは開発に限った話ではなく、色んな所で重要だと思います。特に言い換えたりして表現を揃えていく、というのは大事だなと思いました。グーグル翻訳とかで入力の日本語をコネコネするような感じでしょうか。調整せずにそのままやりきってしまおうとすると無理が生じる、というのはどんなことでもよくあるな、と。
問題を小さく分割して各個撃破するのと、最適な順番を考えるというのはTDDに重要なスキルなんだ、と説明されていました。 - タスクは重要なものからやるか、簡単なものからやるか、だがオススメは後者
これも序盤に勢いつけたいとか、準備が重いのでタスク自体は軽めのものから入るほうがいい、とかプログラミングにかかわらず有用なノウハウだなぁと。 - 「ただし」は要注意ワード
これはテストするときでもあるあるですね。正常系以外の内容や例外条件とかが出てくる予兆ですね - TDDではテストコードのそのまた下に当たる部分（＝検証部分）を先にかく。目的をブレさせないため。
考えながら走っていると目的地を見失う、というのはよくあるので先にゴールを設定しておくというわけですね。これもいろんなことに共通で使える考え方ですね - 作る前に使う側に回って考える
作ってしまうと「こうこう使ってほしい」というバイアスが発生するので作る前に使う側に回って考えて検証部分を先に書いてしまうと。余計な束縛を受けないための知恵ですね。テストでも事前に中身を知りすぎると無意識に遠慮したりするという心理はありそうなので、そういったところをカバーするのにいい考え方ですね。
さて一通りライブコーディングが一巡したところで、話はテストへと向かっていきます。次の疑問はこれです。
「TDDになって開発者がテストするようになったらテストエンジニアはもう不要なの？」
TDDのTは当然テストですが、このテストについて和田さんはこう言います。TDDのテストは動作するきれいなコードに到達するための手段だと。これはJ. マイヤーズのいうところのソフトウェアテストの定義「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」とは違ってますよね、と和田さんは続けます。TDDのテストはプログラミングテクニックであってソフトウェアテストではないと。TDDのテストは
で言われているところの“Checking”だとあっさり認めてしまいます。実際チェッキングだよねと。なんでTDDはCDD（Checking Driven Development）にならないんだろう、という点については書籍「テスト駆動開発」の付録C参照、だそうです(笑)
アジャイルテストの4象限だとビジネス面/技術面、チーム支援/製品批評の2軸があるのだそうですが、TDDのテストはそのうちのチーム支援が主眼なので製品批評的なテスト、探索的なテストやセキュリティテストはTDDではカバーできないので引き続き必要になるはずだ、ということでした。
では両者は独立した別々のものなのでしょうか？和田さんはテスティングフレームワークを用いている以上、両者をなだらかにつなぐことができるのではないかといいます。TDDに必要なスキルにテストの構造化とリファクタリングがあり、そこにテストエンジニアの貢献を期待しているというのです。どういうことかというと、TDDで作成したテストコードのメンテナンスコストを抑えるために、保守性を確保する必要があるが開発者は実装を進めていく以外の動機が弱いのでいろいろと困ることが出てくるのだそうです。
例えば先程のFizzBuzz問題のライブコーディングに戻ってみると、○○を渡したら文字列××を返す、みたいな具体的な振る舞いだけが記載されたテストコードが多数並んでいます。だけど、一口サイズに分割した結果、もともとこれらのテストケースを作成しなければならなかった理由、つまりFizzBuzzの仕様はテストケースからはよくわからない状態になっています。この状態で担当者が代わったりしてしまうと、テストケースの重要度や階層構造が全くないので全部のテストを丸呑みしてしまわざるを得なく、それがメンテナンスコストを押し上げているというわけです。
これを解決するにはテストコードを構造化したり、それぞれのテストケースに根拠を与える必要がありますが、そういったことに長けているのがテストエンジニアで、値の選び方とかツリー化やテストケースの増減に対する根拠付けなどの面で開発への貢献が可能なんだ、という話をされていました。書くだけがテストなんじゃなくて、考えて分類して、というのが大事なんだけど、そのへんが開発者には足りないことが多いのでテストエンジニアと協業できるんではないか、という話でした。
質疑ですが、「テストコードがないコードを抱えている状態である場合、どうすれば良いですか？」という質問が出ていました。これはもっともよく現場で要望されることらしく、詳しくは「レガシーコード改善ガイド」という書籍を参照のこと、ということでしたが、こういう状況の場合無理やり大外（WEB系ならばEnd to Endとか）からテストを書いていくか、もしくはテストが書けそうになるまで慎重にリファクタを続けていく、の2択だそうで、ご紹介の書籍には後者のノウハウが豊富（stack overflowでの被引用数No.1）なんだそうです。
たぶんこのエントリもリファクタしないといけないのだろうなー、と思いはするのですが、とりあえずGreenになったということで乱文ご容赦いただければ。
しかし講演内容をまとめるのは大変だな・・・・。速報的に投稿してる人たちはすごいなぁ・・・。基調講演以外をエントリできるのはいつのことやら・・・。
