読書メモ『実践アジャイルテスト』

書籍「実践アジャイルテスト」について、実際に読んだのはだいぶ前で、今年(2010年)3月下旬から5月にかけて、読書会に参加してたのですが、まとめを何も書いてなかったので今更ながら僕なりの読書メモを公開します。

本の概要

いわゆるアジャイル開発プロセスの中で、テスト担当者・QAエンジニアの役割や、テストがどう設計され、実施されるべきかを網羅的に説明した内容です。アジャイル関連の本はいくつも出ていますが、その中でテストをメインテーマに据えたものは和訳本ではこれがはじめてなのではないかと思います。

前半はアジャイルプロセスやテストの概要など大枠の話が多いですが、後半にはいろんなレベル(単体、APIGUI)での自動テストや、反復の各フェーズで実施する作業内容など、だいぶ具体的なプラクティスまで説明されています。

ちなみに読書会は、自分含め 9 名の参加者で、(当然ながら)テストが主な仕事の方が多かったですが、開発寄りの方もいらっしゃいました。各章ごとに担当者が割り当てられ、自分の担当分の簡単なまとめを発表してその後その内容についてディスカッションする、というスタイルで、計5回ほどで1冊分を終えました。

個人的に学んだこと

僕が個人的にこの本で得たポイントは主に以下の3点です。

  • テストの4象限という分類の仕方
  • 自動テストのピラミッド
  • GUIレベルのテストはキーワード駆動&データ駆動で
アジャイルテストの4象限

開発プロセスの中では、様々な目的に応じていろんな種類のテストを実施する必要があります。ともすればその多さに圧倒されてしまいそうになりますが、この本で紹介されていた「4象限」による分類は各種テストをうまくカテゴライズしていました。

「技術面」と「ビジネス面」という視点の違いと、「チームを支援する」ことと「製品を批評する」ことという目的の違いによる2軸で4つの象限に分類されています。4隅の雲は、それぞれのテストが主にどういう手段によって行われるべきものであるかを示しています。

第1象限は「技術を用いたチームを支援するテスト」となり、ユニットテストによるテスト駆動開発(TDD)が中心となります。主に内部品質に関わるものであり、ソースコードのバージョン管理や開発環境(IDE)やビルド自動化ツールなどもこの範疇で取り上げられています。

ちなみに読書会では、「テスターが単体テストを書くことを避けるべきです」(p119)とある点が議論になりました。TDDは設計活動だからコードを書く開発者が行うべきであるというのが本にある理由ですが、いかなる場合もそうなのかというのがいまいち釈然としない雰囲気でした。おそらく、TDDという観点からは本書の主張が正当なのでしょうが、コードが作成されてしまった後で、カバー率の足りてない部分を強化するためにテストを追加することなどは間違っていないように思います。

第2象限は、第1象限が技術寄りだったのに対し、もっとビジネス寄りの視点に立ったものを含みます。機能テストなどのほか、プロトタイプやシミュレーション、例など、仕様や画面設計など開発を進めるための活動も一種のテストとしてここで扱うようです。また、ここでのテストは、ビジネス担当者が理解できる言語や様式で記述され、その多くは自動化されるべきであるとされています。

Fit、 SeleniumWatir や Canoo WebTest などによる自動化テストはこの領域に含まれます。読書会のメンバーからは Cucumber というものも挙げられていました。また、ウェブサービスのテストのためのツールとして、CrossCheck、Ruby Test::Unit、soapUI が紹介されています。(pp167 - pp175)

第3象限は、引き続きビジネス視点に立ったものでありつつ、製品を批評(critique)するためという目的に転じます。このセクションの説明の最初にデモを行うことの重要性について触れられていること(p191)からも、ここでは基本的にできたものに対して行うテストが中心であると読めます。第1、第2象限で自動化の側面が強かったのに対し、ここでは手動での、人間にしかできないテストが強調されています。

探索的テストやユーザビリティテストが特に話題の中心にあり、探索的テストの具体的な実践手法として「セッションベーステスト」が紹介されています。探索的テストが捉えようによってはただの闇雲なテストになりがちなのに対し、限られた時間枠内で実施する、統一されたフォーマットで結果を残すなどの枠に沿って実施することで、直感を活かしつつテスト対象についての不具合情報を効率的に収集するための手法のようです。*1

第4象限は、パフォーマンステストやセキュリティテストなど、基本的に技術を用いなければ実施が難しい製品に対するテストです。パフォーマンス、スタビリティ、拡張性、信頼性テストをまとめてPSRテスト(performance, stability, scalability, reliability)と言ったりするそうです(p221)。

ちなみにこれらの第1〜第4の象限は必ずしも実施の順番を示しているわけではなく、この第4象限にあたるパフォーマンステストなども単体レベルのテストや開発初期から考慮するべきであるとも言われています(p223 など)。

本書ではこの4象限のマトリクスを、「地図」として用いることを勧めています。テストおよび開発の中で各種テストがどれだけ適切に行われているかといったプロファイリングや、これから取り組むプロジェクトやスプリントの中で、どこに注力していくか、あるいはどこを省いてよいのかといった戦略を立てるためのチェックリストとして使うのがよさそうです。また、実施している、あるいは実施しようとしているテストが、何のためのテストなのか?ということを確認するためにもこれを参照すれば、チームや組織内での共通認識がとりやすいのではないかと思います。

テスト自動化のピラミッド

これはテストの自動化戦略の中で示されていた図です。基礎に単体テストが最も大きな割合を持つ土台としてあり、より大きな機能の集合を対象とするテストがその上に乗るかたちになっています。つまり、自動テストを支えるのはまず単体テストであるということです。これは僕にとっても少し意外で、実際に本書でも、いわゆる「V字モデル」とは反対であるため、「多くのチームがこの考え方と格闘することになる」と述べています。(p274)

「通常は前のプロジェクトから引き継がれたことによって逆さまになります」(p276)とあるのを読んで、実際自分のチームも最も上位のGUIレベルの自動テストが肥大化した状態だったため、やはり現実はそうである場合が多いようです。しかし、「3匹の子豚」の比喩で、ピラミッドの下から「レンガ」「枝」「藁」と例えられているように、最上位のGUIレベルのテストはちょっとした画面変更などによって容易に崩れる上、実行にも時間がかかるため高速なフィードバックを提供することができません。藁や枝は比較的積みやすいですが、レンガを積み上げるのは学習コストも高いので初期コストがかかりますが、スキルがつけば最も高速で大量に実行できるため、なるべく多くのテストをこのレベルに積み込むべきであるとされています。

ただし、すべてが単体レベルの自動テストで済むわけではなく、上位レベルのテストや、さらに上の手動テストももちろん必要です。このあたりは、上の4象限での話と同様で、目的が異なるものについては相互補完的にそれぞれ実施されるべきであると解釈できます。

キーワード駆動テスト、データ駆動テスト

もうひとつはちょっと細かい点ですが、ちょうど個人的に抱えていた問題とはまったことで、先の第2象限での自動テストの中で述べられていたキーワード駆動テストおよびデータ駆動テストというものについてです。(p182)

データ駆動については単体テストの文脈で聞いたことはありました。投入するテストデータのバリエーションを増やすだけでケースが増やせるよう、ロジック(主にループ処理を行う)とデータを分離するものであると理解しています。
キーワード駆動という単語はこの本ではじめて知りました。キーワード、あるいはアクションワードを決め、それに対応する処理を定義するスタイルのようです。たとえば、Signup や Signoff というキーワードを決め、引数としてログインIDなどを渡せるようにしておくことで、自然言語に近いスタイルでテストが記述されるようになります。

個人的にはこれらの手法はテストの再利用性のために重要だと感じました。これまで Selenium で自社製品のテストを作ってきましたが、それらの大部分はただ録画したものを順番に実行するだけです。当初は、学習コストが少ないため、たとえばアルバイトたちにも同じスタイルでテストを追加してもらえたし、逆にプログラムを書いて複雑化するとメンテや作成が余計大変になってしまうと思っていました。

しかしテストが増えていくにつれて、メンテナンスやテストの可読性がかえって膨大になっていくのを実感しました。
GUIレベルのテストでは画面仕様が変わると大きな影響を受けてしまいます。そのたびに、その画面が出てくる個所をすべて置換してまわらなければならないのはかなりのコストです。単純な文字の置換であれば一斉置換で済みますが、変更内容によっては手作業でやらざるを得ない場合もあります。また、テストの記述が冗長なため、テストケースを見て内容を追うのが大変で、自分が作ったテスト以外は読む労力が半端ではありません。新しくメンバーが入った場合などは特にそうです。

キーワードによって処理が一段抽象化されていれば、キーワードとデータを並べていくだけでテストが作成できるようになるため、可読性もメンテナンス性も向上します。このあたりについては、現在取り組み中のところもあるので、別の場で詳しく書いてみたいと思います。

読書会で出た話題

以上、3点だけピックアップしましたが、他にもこの本ではアジャイル開発やその中でのテストの実践方法について、多くの示唆が得られます。少なくとも自分にとっては、仕事で行っているWEBアプリケーションのテストとリンクする部分が多く、極めて実際的であると思いました。

以下ではおまけで、読書会の中ででたいくつかの話題について、自分のメモからログを残しておきます。雰囲気だけでも伝わればと。

顧客って?
  • 顧客とのコミュニケーションや協業が強調されている
  • しかし(いわゆる)ウェブサービスや B2C なサービスの場合、顧客って?
    • 顧客と作業する、といわれても。。
  • 顧客が明確な場合でも、参加したがらない?労力が増えるのをいやがる
  • 「顧客チーム」って何?そんなの皆さんの会社にありますか?
    • 企画部門が近いかも
どこまでテストするか
  • 即座にリリースすることが重要な場合ある
    • 海外とか、バグがあってもどんどん出してくる。初期のFacebookとか
    • 品質基準が違う?
    • セキュリティバグはそれでいいのか?
アジャイルテスター としての能力

この本にある「アジャイルテスター」のスペックって高過ぎ? (たとえば p68 の職募集案内の内容など)

  • テストができて、コミュニケーション力・交渉力があって、プログラムを理解していて、自動テストができて、、、
  • 日本だとテストの専門家がいるのはSIでは
    • けど流動しない
  • プログラマにおされることがある?
    • 品質/テストが犠牲になる
バーンダウンチャートを前にして進捗はなす
  • プロダクトオーナー/顧客/管理者に話すときにもそれを前提に
  • 手書きがおすすめ。積み上げなきゃいけないときのプレッシャーがハンパない
バグトラッキングツール何使ってる?
テストケースレビューってしてる?どうやるのがいい?
  • レビューチェックシート(日立の例)。超ヘビー。ウォーターフォール向け?
  • 人ごとに、レビュー観点の担当を決めてやる(顧客視点担当とか)
  • テストケースは企画陣営にチェックしてもらうために作る。分担できるように
  • テストリーダーが全部レビュー
  • やり方は明確でなくとも、レビュアーの暗黙知が引き出される
個人的な感想

アジャイル開発って良いけど実際ムズカシイよね?といった感を皆さん持ってるよう。
自分の会社は1年前にScrumをベースにしたアジャイルプロセスに移行して、試行錯誤しつつも意外と本書にあるような、理想とされるプロセスに近いかたちで運用できてるのかもしれない。

*1:http://www.satisfice.com/sbtm/index.shtml に情報あり