九州ソフトウェアテスト勉強会の勉強会　Vol.20　～TDD/BDD実践者のテストアーキテクトに聞け～　kyon_mm氏に聞くQ&A

かなり久しぶりの投稿です。

2016/03/25（金）に行われた九州ソフトウェアテスト勉強会の勉強会　Vol.20　～TDD/BDD実践者のテストアーキテクトに聞け～にて@kyon_mmへの質問コーナーを設けました。

最初に講演頂いたスライドはコチラから確認することができます。テストとリファクタリンク?に関する深い方法論※レガシーコード改善勉強会の再演となっています。

参加者に事前アンケートを取って@kyon_mm氏に回答いただきました。当日はその回答にさらに質問をしたり、助言をいただいたりと非常に濃い時間を過ごすことができました。

質問の内容と@kyon_mm氏の回答を記載します。

Q01: エンジニアがテストコードを書く文化を根付かせることや、テスターがレビュアーとしてテストコードをレビューする文化を根付かせるにはどうすればよいでしょうか？

プレッシャーによってやらせたくする

プレッシャーによってやらせたくするなら、見本を見せたり、バグをたくさん見つけたりして、振り返りとかをうまくつかう。例えばテストコードをガンガン書いて、それでバグを大量に出すことでエンジニアにプレッシャーをかける。

自律的にやらせたくする

自律的にやらせたくするなら、その人達がどういうものごとを楽しいと思うか観察して、やってほしいことをうまくそれに似せる。

Q02:テストレベルに対するBDDをどのようにおこなうのが良いかがわかりません

A: 各テストレベルつまりあるプロダクトの塊を使いたいユーザーを洗い出して、どのように使いたいかを書く、どんなことにも転用できるかを書く、細かいけど気になりそうなところを書く。それがテストコード（Specification by Example）になっているという感じです。　ここでのユーザーとはエンジニアやテスターや受け入れるお客さまのこと。　例えば、Unitであれば、関数を使うユーザーはエンジニアで、エンジニアはその関数をどのように使いたいか、気になることなどを書いていきます。

それでも考えられない時は、WhyやWhatやGoalを考えるのが苦手なのかもしれません。Impact Mappingとか要求分析とか設計について勉強したらいいかもしれません。

Q03: ソフトウェアメンテナンスを交代した場合のコスト増にテストを活用できる可能性を知りたいので、経験をお聞かせいただければと思っています。

ガイドを作る

ユーザーガイドや開発者ガイドをテストコード付きで記述していくことで、動作させながらどのようなプロダクトなのかを把握できると思います。ユーザーガイドと開発者ガイドはそれぞれ作るとよいです。ガイドは、例えばユーザーガイドであれば動画で作るなど、ユーザーにあわせて最適なものを選ぶとよいです。

よく困る仕様をスクリプテッドする

他にも、よく困る仕様などもスクリプテッドしておくとよいです。パッと答えられるので。大体、聞かれるところは仕様が複雑であったりするので、確認するにも明確になるのでおすすめします。

Q04: TDDやBDD をやっていくためにまず、組織（チーム）として何から手をつけたほうがいいですか。

kyon_mmのような識者にTDDBCを開催してもらう。

何となくやっている人だと、誤解したまま進むことが多いと感じている。きちんと最初は識者に教えてもらう方がよいです。呼んでください！

Clean Coderに書いてあることを実践することにみんなで挑戦する。

自分たちで出来ることとしては、Clean Coderを挑戦するとよいです。

Q05: VisualStudioのGUIテストをやりたいです。何か参考になる本や方法をご紹介願えないでしょうか？

A:VisualStudio自身のテストでは、前にFriendlyを利用した経験があります。今だと少しは楽になっているはずです。（基本的にはEnvDTEの中身をどうやって読みとくかです。）

Q06: 設計段階からテストを念頭に効率よく仕様に落としていくにはどうすればいいでしょうか？もしくはテストを意識し始めるのはどの段階から意識するのがいいでしょうか？

A: 自分たちが今までやってきた中で「全く一緒の部分」「ちょっと違う部分」「初めての部分」を洗い出して、それぞれどう今までと違うのかを書いてみる。　今までやってきたプロダクトと「全く一緒の部分」が多いと思っていても、実際に書いてみると殆どが「ちょっと違う部分」であることに気づくと思います。

精度ではなく、確度をあげる

それらがたいていはリスクなので、それらの見積もり確度をどうやったら早くあげられるか？どうやったらうまくいっているかうまくいっていないかを知れるか？を考える。と、それがだいたいテスト戦略っぽいものになります。

あとは具体化して進めていく感じです。もちろん、「いつもうまくいっていないこと」とか「今回特に不安なこと」とかがあるなら、それらもあげてください（当り前だと思うんですが）

翌日も、同じく kyon_mm氏に講師をしていただき、日本初のふりかえりのワークショップをおこないました。(何が日本初かは、別途ブログでご紹介・・・できるといいなぁ) 二日間様々な内容の講演やワークショップ、夜もお酒とともに色んな話をしていただきありがとうございました！

次回予告

次回は試される北の大地より @nemorineがいらっしゃいます。テーマは『探索的テスト』探索的テストは文献も少なく、勉強もしづらいのですが、圧倒的なスピードでバグを見つける為にはかかせないテストです。ワークショップを交えての会となりますので、ぜひご参加ください。 https://atnd.org/events/76020