第4回 実践アジャイルテスト勉強会

8月24日(水)に行われた「実践アジャイルテスト」の勉強会(第4回)に参加してきました。
「名古屋アジャイル勉強会」 の分科会として同名の書籍を対象とした読書会で、前回の内容は「第3回」に残しています。
agile_test_.jpg
第7章 チームを支援する技術面のテスト
第5章で出てきた「アジャイルテストの4象限」の中の『第1象限』について述べています。(図の左下に該当)

matrix_06.png
第7章のマインドマップ
agile_test_03_07.jpg

■目的
第1象限の目的は、「内部品質」を確保することです。
内部品質とは作り手から見た品質、つまり「いかに正しい作り方」で作られているか、を表します。
一方「外部品質」は使う側から見た品質を表します。「いかに欲しいものが実現できているか」ということですね。
ここでは、テスト駆動開発(TDD)の手法を用いることで開発チームへの素早いフィードバックを実現し、以後に発見されるバグの数を抑えることができると説いています。
アジャイル開発に限らず、テストを書くことで仕様の矛盾や漏れを発見することが良くあります。TDDを実施するということは、それを早い段階でやってしまおうということだと思われます。
■インフラによる支援
ここでいう「インフラ」は、テストの自動化、自動ビルド、継続的インテグレーションといったプラクティスを実現するためのツールを指します。
このようなプラクティスを欠いた状態でアジャイルをやろうとすると、アジャイルとは似て非なる「ミニウォータフォール」のプロジェクトに陥ってしまうことが多いそうです。
■「テストファースト開発」と「テスト駆動開発」
本書では「テストファースト開発」と「テスト駆動開発(TDD)」を明確に区別して書かれています。
●テストファースト開発:
 コーディング前にテストを書くこと。
 全てのテストにおいて適用できる。
 
●テスト駆動開発:
 テストを最初に書くだけでなく自動化することも含まれる。
 主に単体テストで適用可能。
■テストを考慮した設計
TDDによる開発を進めるメリットの1つが、「テストの容易なコードが書かれる」ことがあげられます。
設計が次のように考慮されていれば、「テストが容易」であると言えます。
・各オブジェクトが単独の機能を持つ
・オブジェクト間の依存関係が「疎」である(独立している)
具体的なテクニックについて触れると長くなるので、ここでは省略します。
個人的に重要だと感じたのは、こうした「テスト容易性」を意識した設計はプロジェクトチーム全体に浸透していないと意味が無い、ということです。誰か1人でもこの方針を無視した設計をしていた途端に、テスト容易性や保守性が崩れてしまいます。
チーム全体へのコミットメントがいかに大事か、ということですね。
■テスターは何ができるか?
通常「テスター」というと、テスト・オペレーターのことをイメージすると思いますが、本書全般を通じて「チームのテスト全般を主導する」重要な役割のことを指します。(「テスト・エンジニア」とでも言えば良いでしょうか・・・)
第1章象限のテストにおいても、テスターはアジャイル・プラクティスを導入するための「変化の推進者」としての働きが期待されます。
余談ですが、本来TDDで言うところの「ユニット・テスト」が本書では「単体テスト」と訳されていて紛らわしい、ということで議論になりました。確かに、日本の開発現場で言う「単体テスト」は意味があいまい(何が「単体」なのか?)で混乱を招きがちですよね。(´д`)
■テストマネージャーは何ができるか?
一方、テストを統括するテストマネージャーに求められる言動は何でしょうか。
それは「プロダクトオーナーと一緒に品質目標を定めること」と「品質を優先することがビジネス価値を高めることをビジネスマネージャーに説明すること」とされています。特に後者は同感です。
■ツールキット
ここでは、ソースコード管理(CVS、Subversion等)、IDE(Eclipse、VisualStudio等)、ビルドツール(Ant、Maven等)、ビルド自動化ツール(CruiseControl等)、単体テストツール(xUnit等)が紹介されています。ここでは詳しく触れませんので、興味のある方は色々調べてみると良いでしょう。
第8章 チームを支援するビジネス面のテスト
本章で扱う「第2象限」は、上図の左上のエリアに相当します。

第8章のマインドマップ
agile_test_03_08.jpg

■ビジネス面のテストにより開発を推進
第1象限のテストが内部品質を保証する目的があったのに対し、第2象限のテストは「外部品質」を検証することを重要視します。一方、いずれも開発チームへの素早いフィードバックを提供することで開発作業を支援する、という共通した特色を持っています。
■要求について
従来のウォーターフォール型プロジェクトにおいては、最初の要求定義に時間がかかるだけでなく、最後のテストフェーズまで要求の変更が受け入れられない(逆に言うと変更を受け入れるとプロジェクトは混乱する)という問題点があります。
アジャイル開発では、各反復ごとに小さな要求(ストーリー)を積み重ねていくスタイルなので、どこかで要求の変更を受け入れる余地が生まれるワケです。
第2象限で行うビジネス面のテストにより、こうしたストーリーを作成することを支援することができます。
顧客のストーリー(実例)に基づいたテストをできるだけ早い段階で書くことによって、スコープが明確になります。例えばストーリーテストを書くことによって例外的なケースが見つかることが良くあります。開発の早い段階で見つかれば、「機能として含める/含めない」で揉めることが少なくなりますよね。
■達成の条件
各ストーリーが「何を持って終了したと言えるか」を事前に明確にしておくことは重要です。新たなリスクを識別するだけでなく必要なタスクを漏れなく洗い出すことにも繋がるので、ゴールまでの予測が立てやすくなります。
注意点として挙げられているのが、「反復の最中でも全体像を見失うな」ということです。
ごく小さなストーリーであってもシステム全体に影響を及ぼす可能性があり、何気ない変更が大トラブルに発展することがあり得ます。そのためにも、システム全体を俯瞰できるようなドキュメントを作成しておくことが推奨されます。
■テストはリスクを軽減する
早期にストーリーテストを書くことはリスクが抽出できるという効果も得られます。起こり得る脅威の発生率/影響度を検討し、最終的にテストの優先度を決定することが可能となります。
ストーリーテストを書く際に顧客に参画してもらうことで、その効果は膨らみます。できるだけ現実味のあるテストデータや条件でテストするためにも、顧客の協力は不可欠ですね!
(終)


** 参考図書 **