こんにちは、圏論こと天丼丸（てんどん）です。
アジャイル系のセミナーや勉強会が会社で流行っていたので、個人でも参加すべくアジャイル系の勉強会を探していたところ、「Nagoya.Testing in Tokyo 3 -アジャイルなテストの見積りと計画づくり」(Zusaar 詳細)というイベントを見かけました。アジャイルとは銘打ってありますが「テスト」に主軸があるイベントで、これも良い機会だと思ってイベントに参加しました。
主催者の kyon_mm さん（きょんさん）がテストにおいて大切だと考えていること、実際にテストプロセスを体験する演習、そしてビアバッシュ＆野良 LT など内容盛りだくさんでした。イベント概要も含め、内容をかいつまんでお伝えします。
イベント概要
[caption id="attachment_2556" align="alignright" width="400"]
イベント風景です。11:00～18:00の長丁場だったため、メンバーとも次第に打ち解けることができました。[/caption]
イベントは、お昼をまたいで以下の3部構成でした：
- kyon_mm さんによるテスト全般に関するお話
- テスト計画書を作成し、実際にテストを行う演習
- ビアバッシュ & 野良LT
kyon_mm さん流のアジャイルなテスト手法の話を聞いた後に、仮想プロダクトに対してテスト計画書を作成し、実際に Heroku 上で動いているプロダクトのテストを実施します。
アジャイルなテスト手法はまだ確立されておらず、kyon_mm さんも模索中であるということでした。一般的なテスト（レガシーテスト）だと、全ての機能要件を確認するなど、完璧を求めてしまうがゆえに要件の変更に弱いという弱点があります。アジャイル開発手法を取り入れてもテストが従来通りだとテスト工数が増えてしまうため、テストもアジャイルにするために変更可能性を残したテスト設計を心がける必要があります。
ビアバッシュでは「テストは完璧でなくていい、葉を削いで幹だけ残したテスト計画を」と、kyon_mm さん自身の本心を聞くことができました。私はテストにアジャイルの考え方を入れること自体が驚きだったので、この考え方を聞いてとてもエレガントだと感じました。僕の勤めている会社だと専属のテスターは業務委託の方に来てもらっているので、ここまでテストについて熱い話を聞いたのは初めてで、とても刺激的なイベントでした。
しかし言うは易し、行うは難し…ということで、kyon_mm さん流のアジャイルなテスト手法の話を聞いた直後だったにも関わらず、演習では私を含めて多くの班が「完璧」を求めるテスト計画になってしまいました。私自身がテストやアジャイルに精通していないのが原因の1つだと思うので、アジャイルの考え方に少しずつ慣れていきたいです。
イベント詳細
kyon_mm さんによるテスト全般に関するお話
[slideshare id=17083019&doc=agiletestplan20130309-130310110127-phpapp02]
イベントの最初に、お昼を挟んで kyon_mm さんがテスト全般に関する話をされました。一般的なテスト開発手法や、アジャイルにテストを行うために kyon_mm さんが考えて実践していることなどを聞くことができました。
話が盛りだくさんで全てをお伝えできないため、詳細は上記スライドをご覧くださいここでは私が特に面白いな、と思った点だけかいつまんでご紹介します（誤りがあれば突っ込んでください）。
ソフトウェアの品質について
日本のソフトウェアは品質が良いとされているようで、これは品質の基準や考え方が浸透しているためではないかということです。例えば SQuBOK という BOK があったり、最近では ISO 9126 を現代的に修正した ISO 25010 が登場しました。これらの基準を用いることで、ソフトウェアの品質について考える足がかりができます。
この品質には依存関係があります。インセプションデッキなどでテストの優先順位を付けても、「テストAで証明したい機能は、テストBが成り立っていないとダメだ」というように、優先順位と合わせて依存関係を考える必要があります。
テスト観点と目的について
[caption width="114" align="alignright"]
テストとは「根拠をもってリリース出来ること」がゴールであり、何より大切なのがテストの「目的」です。何のためにテストをしているのか？そのテストがパスすれば、何が言えたことになるのか？など、テストを行う目的を意識し、計画書にも記載することが大切です。
アジャイルなテストについて
「アジャイルはスタイルであってプロセスではない。アジャイル宣言とアジャイルの12の原則がすべて」と語る kyon_mm さんは、チームの特性もあって独自のテスト手法を考えて実践しています。アジャイルなテスト手法が確立されていないこともありますが、開発側でもアジャイルは実践しているものの、Scrum も XP も実践はしていないのだとか。ここでも「目的」と「手段」をきっちり分けて考えています。
テストにおいては TDD がよく、一般的な開発のようにテストをやっておしまいではなく、テストからのフィードバックのサイクルがきちんと回るので、テスト結果を柔軟に反映させることが可能です。
演習：テスト計画書を作成し、実際にテストを行う
テスト計画書の作成
演習では、社内で使うタスク管理の Web アプリの仕様書と画面キャプチャを与えられ、これをもとにテスト計画書を作成しました。利用するツールなどは一切指定されなかったため、各班がそれぞれの色をもった計画書が出来あがりました。
[caption id="attachment_2547" align="aligncenter" width="400"]
ISO 9126 によるソフトウェア品質の定義です。やや古い基準ですが、テストを考えるとっかかりには良い、とのこと。[/caption]
[caption id="attachment_2550" align="aligncenter" width="400"]
ISO 9126 のソフトウェア品質に習い、それぞれの項目で必要なテスト観点をかきだしました。[/caption]
[caption id="attachment_2551" align="aligncenter" width="400"]
「機能要件の確認」「ユーザシナリオ」「非機能要件の確認」の3つに分け、計画書を作成しました。後から聞いたのですが、kyon_mm さん曰く、「ユーザシナリオ」は顧客とのコミュニケーションツールであり、実際にテスト計画書に盛り込むことはないそうです。[/caption]
[caption id="attachment_2552" align="aligncenter" width="400"]
演習風景です。付箋やら紙やらお菓子やらで雑然としていますが、メンバー同士であれこれ話しながら演習を進めました。[/caption]
テストの実施
テスト計画書を作成した後は、実際に kyon_mm さんが用意した擬似的なタスク管理ツールを動かしてテストを実施しました。
実際にテストを行うと、その場で試したい事がどんどん浮かんでくるので、テスト目的を定めて、行うテスト/行わないテストを決めるのが大切とのこと。一方で必要だと感じたテストはその場で追加するなど、テストを柔軟に行うことも必要だそうです。バランスが難しいですね。
[caption id="attachment_2554" align="aligncenter" width="400"]
kyon_mm さんが作成した、擬似的なタスク管理ツールを実際にブラウザ上で動かしてテストを実施しました。[/caption]
ビアバッシュ ＆ 野良LT
セミナーの後は懇親会として、ビアバッシュ＆野良LTが行われました。アジャイルにテストを行う難しさを語る方や、あれも話してほしかった！と kyon_mm さんに伝える方など、今回で3回目となる Nagoya Testing in Tokyo は次第にコミュニティが広がっているようです。
長丁場のセミナーは懇親会でも参加者同士でもコミュニケーションが取りやすいと参加者が言っていて、私もそう感じました。テスト自体も詳しく知らないのに、ましてやアジャイルなんて…と思っていましたが、テスト自体に少し詳しくなれたし、参加して多くの人と一緒に演習を体験することで、テストの難しさを知ることができました。「テストなんか無い方がいい」と語る kyon_mm さんの、テストに対する熱い思いを聞くことができて、とても有意義なセミナーでした。
kyon_mm さんはじめ、運営のみなさま、ありがとうございました！
