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

10月19日(水)開催の「実践アジャイルテスト」の勉強会(第5回)に参加してきました。
本来は9月21日の予定だったのですが、この日は台風の影響で10月19日に延期となっていました。
前回の内容は「第4回」を参照のこと。
agile_test_.jpg
第9章 チームを支援するビジネス面のテストのためのツールキット
「アジャイルテストの4象限」の中の『第2象限』のテスト(図の左上に該当)において、チームの成功を助けるために用いるツールについて紹介されています。

matrix_06.png
第9章のマインドマップ
agile_test_05_09.jpg

■プログラマが要求を知るには?
まず、ビジネス面のテストを行うには顧客の要求を知ることから始めなければなりません。
プログラマが顧客の要求を知るためにどのようなアプローチをとるべきか、という考査から本章は始まります。
ここでは、顧客の頭の中にある要求を例として具体的に引き出すための具体的なツールが紹介されています。それらはどのようなものか?ちょっと見てみましょう。
●チェックリスト:
通常「チェックリスト」というと、確認すべき項目が基準を満たしているかチェック印を記入していくイメージですが、ここで紹介されているのは業務のストーリーを表現するための記入用フォームのようなものです。達成の条件や達成できない場合の影響点などを記入するようになっていて、ユースケースシナリオに近いかも知れません。
●マインドマップ:
思考の発散を促すのがマインドマップの特徴ですが、要求を引き出す際のアイデア出しにも役立ちます。
●スプレッドシート:
金額や利息の計算など、インプットの値から導き出される結果(アウトプット)をExcel等の表計算ソフトであらかじめ記述しておく手法です。複雑な計算やアルゴリズムを理解する助けになるだけでなく、FitNesse等のテストツールにも流用が可能です。
●モックアップ:
ユーザ・インタフェースのイメージを顧客に確認する際に、よくHTMLで作成したモックアップを作成することがありますが、ここで紹介されているのは「ペーパープロトタイプ」と呼ばれるもので、より前の段階で紙を使って画面遷移や帳票イメージを顧客と詰めるのに使用する手法です。
●ソフトウェアベースのツール:
顧客の要求を関係者間で共有するには、適切なコミュニケーションが不可欠です。ここでは、離れた場所にいる顧客やチームが分散しているプロジェクトにおいて、コミュニケーションの助けになるようなツールが紹介されています。
⇒VNC、Skype、WebEx、Mimeo、Wiki etc
■例に基づくテスト自動化ツール
上述のとおり、顧客の要求を理解するには具体的な「例」として表現するのが効果的です。顧客から引き出した「例」に基づいてテストを自動化するツールとしては、どんなものがあるでしょうか?
●GUIおよびAPIの下位レベルをテストするツール:
ここでは、GUIやAPIよりも下位のレベルのテストを可能とするツールが紹介されています。
単体レベルJUnitやNUnitのようなxUnitツールは、ビジネス面のテストでも有効とされています。また、振る舞い駆動開発(BDD: Behavior-Driven Development)ツールにも触れています。
その他、APIレイヤーやビジネスロジックの機能テストに適しているFit/FitNesse、WEBサービスのテストを支援する各種ツールが紹介されています。
●GUIテストのためのツール:
最近はGUIレイヤーのテストを自動化するツールも存在します。Watir、Selenium、Canoo WebTest などがそれに該当します。
GUIが複雑なアプリケーションの場合は、このようなGUIテスト自動化ツールを活用すると効果的ですね。
■テストを記述するための戦略
第2象限のテストを行う際に、最初は単純な基本パスを書いてテストを行います。これによって、開発者が顧客の要求を正しく理解しているかを確認することができます。その後段階的に、より詳細なテストに取り掛かるというアプローチが推奨されています。
テストの記述も反復ということですね。
途中コードを変更した場合、その変更を確実にテストにも反映して再テストを行うことが重要です。変更のテストを後回しにせずに、その場で品質を確保しておくべし、ということです。
第10章 製品を批評するビジネス面のテスト
「アジャイルテストの4象限」の中の『第3象限』のテスト(上図の右上に該当)のお話です。

第10章のマインドマップ
agile_test_05_10.jpg

■導入
第1~第2象限のテストが「開発者を支援する」のが目的であったのに対し、第3象限は、言ってみれば「製品がユーザの手元に届くに値するかどうかを検証する」のが目的ということになります。(言い換えると「外部品質」を確保するのが目的)
従来のウォーターフォール型開発であれば、「製品を批評するテスト」はソフトウェアが完成して初めて可能となります。ここで問題が発生した場合、非常に大きな手戻りとなりプロジェクトに重大な影響を与えます。
アジャイル開発では動くソフトウェアを早い段階で提供できるので、「製品を批評するテスト」も早いタイミングで継続的に行うことが可能です。反復の途中でこのテストに時間を割くのは現実的には難しそうな気もしますが、第1・第2象限のテストを自動化することでそれが可能になる、と筆者は主張しています。
それでは、第3象限のテストの手法を紹介していきます。
●デモ:
ここでは、開発中の動くソフトウェアをできるだけ早期に顧客に提示することを推奨しています。これは理屈の上ではその通りなのですが、開発者の中にはこれを嫌がる人が結構いそうですね。。。(開発中の製品を見た顧客に「ここを変えてくれ」と言われるのを嫌っているのだと思いますが・・・)
仮に変更の要望が出た場合でも、協議の上次の反復で取り込む、といったルールを明確にすることが重要でしょう!
●シナリオテスト:
実際に起こり得る「現実的な」データを用いてテストするのが「シナリオテスト」です。
それに対し、一見現実には起こり得ないと思われる「最悪の事態」を想定したテストを「ソープオペラ」というそうです。(原発事故が起きたのはソープオペラテストが不足していたのが原因?)
●探索的テスト:
探索的テストは、それ自体がテストのテクニックではありません。またキーボードを思うがままに打鍵するようなアドホックテストとも異なります。
このテストの目的は、既存のテストの矛盾や抜けを発見しフィードバックすることにあります。そうすることでテスト自体を継続的に改善していく効果が見込めます。
探索的テストを行うには、リスク、過去の経験、開発チームや顧客の言動など、あらゆるものを観察する必要があります。
●ユーザビリティテスト:
いわゆる「使い勝手」のテストです。使い勝手の感じ方は人それぞれなのでテストするのも難しそうですが、少なくとも当該アプリケーションを利用するのが特定の熟練ユーザなのか不特定多数のユーザなのかによって、ユーザインタフェースの考え方も違ってきます。
競合製品と比較して参考にする、というのも有効な手法として紹介されています。
●その他:
その他のトピックスとしては、GUIの裏側(APIやWEBサービス)を検証するテスト、ユーザマニュアルやオンラインヘルプといった文書を絡めたテストなどがありました。
(終)


** 参考図書 **