迅速かつ柔軟な開発を目指したアジャイル開発手法を採用する企業が増えている。この連載では、アジャイル開発を主導する「賢者」に開発の極意を聞く。今回は、アジャイル品質プロセスのコンサルティングや研修サービスを提供するカナダのドラゴンファイアーの創立者であるジャネット・グレゴリー氏に、アジャイル開発におけるテストの勘所を聞く。

 グレゴリー氏のインタビューに入る前に、アジャイル開発のテストについて簡単に説明しておこう。アジャイル開発におけるテストは、従来型開発のテストと意味合いが異なる。従来型開発のテストは通常、要求・要件に適合しているかどうかを検証することを目的とする。これに対し、アジャイルのテストは「ビジネス価値を最大化しているか」を検証することを最大の目的としている。

 アジャイルというと、開発スピードの速さに焦点が当たりがちである。しかし、根幹をなすのはビジネス価値の提供である点を忘れてはならない。どれだけ速くソフトを提供できたとしても、ユーザーが使ってくれなければ何の意味もない。仕様ありきではなく、あくまで顧客ありきなのだ。

「テストありき」の開発手法であるTDDとATDD

 アジャイルの世界では、TDD(Test Driven Development=テスト駆動開発)と呼ぶ手法がよく知られている。TDDとは、プログラムコードを書き始める前にまずテスト用コードや手順を作成し、そのテストをパスできるように実装するというものである。

 TDDでは、開発終了後に分離された作業としてテストを実施するのではなく、開発プロセスそのものにテストを組み込む。そうすることで不具合を早期に発見し、結果的に工数の増大を防止できるという利点がある。アジャイルで強く推奨しているプラクティスの一つだ。ちなみにTDDはテスト手法ではなく、開発手法である。

 TDDの発展形として近年提唱されているのが、ATDD(Acceptance Test Driven Development=受け入れテスト駆動開発)だ。TDDは、開発者がソフトウエアの品質を技術的な観点から保証することを狙いとする。これに対し、ユーザー(顧客)が実施する受け入れテストを対象とするATDDは、顧客がソフトウエアの品質をユーザーの観点から保証するのが狙いである。

 TDDとATDDを比べると、テスト用コードや手順を作成してからコードを書くという流れは共通している。違うのは、テストの粒度だ。TDDではテストの粒度が小さく、フィードバックを早いサイクルで進める。一方、ATDDではテストの粒度が大きく、フィードバックのサイクルはTDDほど早くない。

 アジャイルのテスト担当者(テスター)は、多くの関係者と協力しながらテスト用コードや手順を作り、テストを実施する。アジャイルのテストはチームワークが大切なのだ。とりわけ、ユーザー側を代表する「プロダクトオーナー」との緊密なコミュニケーションが欠かせない。

 テスターは技術的な観点から、積極的にプロダクトオーナーへ質問を投げかけることで、開発の対象であるプロダクトを十分理解する必要がある。その際、プロダクトオーナーには具体例を交えて説明してもらうようにすると、作業効率が上がる。

 グレゴリー氏は、プロダクトオーナーからのヒアリングを含めたテスト作業を、開発者とペアになって進めることを推奨している。プロダクトに対する深い理解を開発者と共有すれば、ユーザーのニーズからずれてしまうリスクの軽減につながる一方、品質の観点からプロダクトを捉えるテスターの思考を開発者が学べるという利点があるからだ。

 アジャイル開発に興味はあるが、「品質を保証できるのか」が不安で二の足を踏む人も多い。どうすればユーザーの求めるプロダクトを開発し、品質を保証できるのか。自動テストを導入すべきか。どう実践すべきか。ここまで分かったところで、初来日したグレゴリー氏に話を聞くことにしよう。(聞き手は河村 博文=シーアイアンドティー・パシフィック ソリューションマネージャー)

ウォーターフォールには戻らない

ご自身の仕事について、簡単に説明してください。

ジャネット・グレゴリー氏
ジャネット・グレゴリー氏

 アジャイルを実践しているチームや、アジャイルへの移行を検討しているチームと共に仕事をしています。テスターの役割は何か、開発者とどう関わるのか、イテレーション(繰り返し)中に、両者が協力してテストを実施するにはどうすればよいか、といったことを教えます。コンサルティングや研修も担当しています。

どのような経緯でアジャイルのテストに携わるようになったのですか。

 それが面白い話なんです。以前はウォーターフォール型開発のプロジェクトに参加していたのですが、あまりうまく進んでいませんでした。そこでカナダのカルガリーにある別の企業に移り、アジャイル開発手法の一つであるエクストリーム・プログラミングについて少し学んだり、実際に試したりしていました。

 ところが、その企業がリストラを始めたんです。幸い、アジャイルを少し実践していた経験を買われて、私はテスターの職を得ることができました。

 当時、アジャイルチームのテスターについて書かれた本は全くありませんでした。出版されていた本のほとんどは「開発者(プログラマー)と顧客」について書いたものでした。つまり、開発者が行うテストと顧客が行うテストを扱っていたわけです。そのため、アジャイルにおけるテスターとして何をすればいいのかは、すべて自分で学ぶ必要がありました。

 やがてリサ・クリスピンがエクストリーム・プログラミングのテストについて、本を執筆していることを知りました(「Testing Extreme Programming」)。私たちは互いにメールを送り合い、私はリサにたくさんの質問をしました。二人で一緒に多くのことを学びましたね。もう10年以上前、2000年か2001年のことです。リサは「実践アジャイルテスト」(翔泳社)の共著者となりました。

 最初のアジャイルチームに参加して、いかにアジャイルが楽しいか、いかにプロジェクトがうまくいくかを体験してから、ウォーターフォールに戻ることはありませんでした。例外は、ウォーターフォールからアジャイルに移行するお手伝いをするときだけです。