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

7月20日(水)に行われた「実践アジャイルテスト」の勉強会(第3回)に参加してきました。
「名古屋アジャイル勉強会」 の分科会として同名の書籍を対象とした読書会で、前回の内容は「第2回」に残しています。

第5章 典型的なプロセスの移行
この章では、非アジャイルな従来型プロジェクト固有のプロセスをいかに「アジャイルに」移行するかについて掘り下げています。

第5章のマインドマップ
agile_test_03_05.jpg

■指標
欠陥率やコードカバレージといったソフトウェア開発ではお馴染みの指標について、アジャイル開発の考え方ではどのように考えられているでしょうか?
指標といっても色々な種類のものがありますが、一つ言えるのは「個別の指標に注目することより、ゴールやゴールに向かおうとする姿勢」が重要ということです。このことは、顧客にできるだけ早く価値を提供するというアジャイルの本質の一つを表していますね。
指標について「やってはイケナイこと」として、個別の数字にいたずらに注目することや、指標を個人やチームの業績評価に使うことがあげられています。指標そのものが悪いということではなく、その使い方次第では無駄な行為となってしまうので注意が必要です。(アジャイルに限ったことではないですが)
■欠陥の追跡
欠陥(エラー)を記録し追跡するのは、ソフトウェアのテストでは当然のように行われる行為です。本書では、欠陥を追跡するためのツール(欠陥追跡ツール/DTS)についてメリットとデメリット(あるいは使う上での注意事項)をあげています。

メリット ────────────────────── バグの詳細情報を記録しておける 知識ベースになる 稀なバグに関する情報を残しておける 顧客との情報共有ができる テストケースとの紐付けができる デメリット ────────────────────── DTSに入力する時間が無駄 1つの欠陥報告に多くのコストがかかる プログラマとテスターの直接対話の機会を奪う

DTSをどのように使うかはプロジェクトによって事情が異なりますが、大事なのは「欠陥をできるだけ可視化すること」そして「ツールはあくまで手段であって目的ではない」ということだと思います。
■テスト計画書
従来型のウォーターフォール型開発は計画重視という側面があり、規模が大きくなればなるほど、このような「○○計画書」は重厚なものになりがちです。「小さな塊を提供する」ことを信条とするアジャイル開発では、この手の「○○計画書」が忌み嫌われるものかと思いきや、意外とそうではなさそうです。不必要に膨大なドキュメントは論外ですが、利害関係者に必要な情報は何かをよく考えた上で「○○計画書」を残すことは有効です。
これに関連して、本書では「テスト戦略」と「テスト計画」を明確に分けて定義しています。
●テスト戦略:プロジェクトに特化しない組織としてのテスト方針のようなもの。
●テスト計画:プロジェクトごとに策定し、固有のリスク・依存関係・将来像をまとめておくもの。
例えば、要求とテストケースを結びつけること(トレーサビリティ)は、従来型開発でもアジャイル開発でも欠かせない行為です。このようなトレーサビリティを担保する方針を検討することは、テスト計画と切っても切れない関係にあるものです。
■フレームワーク/モデル/標準
「継続的に成熟度を高めていく」という点において、CMMIのようなフレームワークはアジャイルとの共存が可能とされています。
第6章 テストの目的
この第6章から具体的な「アジャイルテスト」の手法について触れられていきます。まずはその入り口として、「アジャイルテストの4象限」という概念が紹介されています。

第6章のマインドマップ
agile_test_03_06.jpg

従来のウォーターフォール開発では、呼び方は色々あるにせよ、単体テスト→結合テスト→システムテスト→受入テスト・・・といったように、対象範囲をより詳細から全体に向けてシーケンシャルにテストを実施するのが特徴です。ここでは、例えば結合テストより先に受入テストを実施するといったことはあり得ません。
一方、アジャイルテストにおいては、
 「チームを支援する」←→「製品を批評する」
 「技術面」←→「ビジネス面」
といった2つの軸を立てて、以下のようなマトリクスで整理できます。

matrix_06.png

第1・第2象限は開発チーム側の視点でのテストですが、第3・第4は製品そのものを評価するためのテストと言えます。
一方、第2・第3象限はビジネスからの視点でのテストですが、第1・第4はシステム寄り/技術寄りの視点でのテストです。
「第○象限」のように名前に数字が付いてはいますが、テストを実施する順番はこの数字に依存しません。例えばパフォーマンス性を最重視されているシステム開発の場合、第2象限の機能テストよりも先に第4象限のパフォーマンステストを先に実施することで、可能な限り早く問題を解決するような柔軟性がアジャイルテストでは重要なのです。
以上です。
徐々にですが、観念的な話からより具体的なテスト手法へと内容がシフトしてきた気がします。
☆-ヽ(*´∀`)八(´∀`*)ノ
(終)


** 参考図書 **