JaSST’10 東海 発表資料
2010/10/22

アジャイルテストとその活用方法
日本アイ・ビー・エム株式会社 グローバル・ビジネス・サービス AMS-SI ビジネス開発
日本アイ・ビー・エム株式会社 金融事業 金融クライアントIT推進 第一クライアントIT部

増田聡
瀧口健太郎

当資料および発表は、セッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。

Agenda

1. はじめに2. アジャイルとは
3. アジャイルテストとは
1. アジャイルテストの4象限
4. アジャイルテストのプラクティス
5. アジャイルテストにおける自動化
1. 自動化テストのカテゴリー
2. 第1象限おけるツール活用－xUnit
3. 第2象限おけるツール活用－Fit / FitNesse
4. 第3象限おけるツール活用－Data Generator
5. 第4象限おけるツール活用－自作負荷テストツール
6. 継続的インテグレーション－Rational Team Concert
7. 自動化ツール活用のポイント
8. アジャイルチーム全体のアプローチ
6. おわりに
2

JaSST'10 Tokai

１．はじめに『アジャイルテストとその活用方法』
 アジャイルテストとはアジャイルソフトウェア開発におけるテストの考え方、およびプラクティスのことです。
 私達は「実践アジャイルテスト」を翻訳する機会を得て、テストの視点からアジャイルソフトウェア開発を俯瞰する経験をしました。また、翻訳後、このアジャイルテストの考え方やプラクティスを実践するため、アジャイルテストをサポートするツール等を試行してみました。
 本講演では、アジャイルテストを実践的に活用することを目的に、アジャイルテストの考え方やプラクティスの概要、試行したツールなどをご紹介します。
3

JaSST'10 Tokai

要求(スコープ)

要求(スコープ)

２．アジャイルとは要求
設計分析・

 アジャイル開発プロセスの特徴

実装時間

プロセス時間ウォーターフォール開発プロセス

アジャイル
開発プロセス

成功の尺度

計画への適合することが成功。

変化へ対応すること。動くコードを開発すること。

マネジメントの方法

命令と制御を主とする。

リーダーシップ、協業を主とする。

要求と設計の関係あらかじめ全てを定義する。

継続的、ジャストインタイムで要求と設計を実施する。

コーディングと実装全機能を同時にコーディングし、後でテストする。

コーディングとユニットテストを繰り返す。できたものから、順番に納品する。

テストと品質保証

計画に基づき、後でテストをする。

継続的・同時発生的に早期にテストをする。

計画とスケジューリング

PERT・詳細・範囲固定である。
時間と工数を見積もる。

期日固定である。範囲を見積もる。

観点

4テスト

JaSST'10 Tokai

出展：「アジャイル開発の本質とスケールアップ」

３．アジャイルテストとは アジャイルテストとはアジャイルソフトウェア開発におけるテストの考え方、およびプラクティスのことである。
 アジャイルテストにはチーム全体アプローチ、自動化などのプラクティスがある。
※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用

アジャイルチーム

従来型機能別チーム
ビジネスアナリスト

プログラマ

プログラマ
機能別チームからアジャイルチームへテスター
門番

門番

ビジネス
アナリスト

テスター

チーム全体のアプローチ

チーム全体アプローチは日本で既に取り組まれているアプローチであり、日本はアジャイルテストのプラクティスを適用しやすい環境にあると考えられる。
5

JaSST'10 Tokai

３．アジャイルテストとは３－１.アジャイルテストの4象限
アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評する目的かの軸による４象限の分類で説明される。
ユーザー要求の観点
ビジネス面

手動

自動と手動探索的テスト
シナリオ
ユーザービリティテスト
ユーザー受入テスト
アルファ/ベータ
第3象限
第4象限

製品を批評するチームを支援するチームの作業効率、品質などを向上させるための助言、サポートをおこなう。

機能テスト
例
ストーリーテスト
プロトタイプ
シミュレーション
第2象限
第1象限

製品を批判的な視点で評価する。

パフォーマンス/負荷テスト
セキュリティテスト
「～性」テスト

単体テスト
コンポーネントテスト

ツール

自動
技術面

6

JaSST'10 Tokai

製品の構成要素、非機能要件などの面※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用

４．アジャイルテストのプラクティス (1/2)
1.
1. チーム全体のアプローチを取る
チーム全体のアプローチを取る プログラマと一緒に座り、自ら会議に参加する。
プログラマと一緒に座り、自ら会議に参加する。
 問題をチーム全体の問題としてとらえる。
問題をチーム全体の問題としてとらえる。

2.
2. アジャイルテストの考えを採用する
アジャイルテストの考えを採用する
 継続的により良い方法を探す。
継続的により良い方法を探す。
 良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。
良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。

3.
3. 自動リグレッションテストを適用する
自動リグレッションテストを適用する
 自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。
自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。
 シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。
シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。

4.
4. フィードバックを与え、受ける
フィードバックを与え、受ける フィードバックはアジャイルの中心的な価値である。
フィードバックはアジャイルの中心的な価値である。
 反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。
反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。

7

JaSST'10 Tokai

４．アジャイルテストのプラクティス (2/2)
5.
5. コアプラクティスの基礎を築く
コアプラクティスの基礎を築く
1.
1. 継続的インテグレーションをする。
継続的インテグレーションをする。
2.
2. テスト環境を管理する。
テスト環境を管理する。
3.
3. 技術的な負債(*1)を管理する。
技術的な負債(*1)を管理する。
4.
4. 段階的に作る。
段階的に作る。
5.
5. コーディングとテストはひとつのプロセスとする。
コーディングとテストはひとつのプロセスとする。
6.
6. 各プラクティスの相乗効果を図る。
各プラクティスの相乗効果を図る。

6.
6. 顧客と共同作業する
顧客と共同作業する テスターはまとめ役になる。
テスターはまとめ役になる。

7.
7. 広い視野を持つ
広い視野を持つ 現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする
現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする*1:技術的な負債(Technical Dept) ≒ 未解決の技術的な課題の累積
8

JaSST'10 Tokai5. アジャイルテストにおける自動化
5-1. 自動化テストのカテゴリー

プロトタイプ
シミュレーション
第2象限
第1象限
単体テスト
コンポーネントテスト

ユーザー受入テスト
アルファ/ベータ
第3象限
第4象限

製品を批評する

 何を自動化すべきでないのか– ユーザビリティテスト– 探索的テスト

チームを支援する

 何を自動化できるのか– 単体テスト– 機能テスト
ビジネス面– テストデータ生成
手動
自動と手動– 負荷テスト
機能テスト
探索的テスト例
シナリオ– 継続的インテグレーション
ストーリーテスト
ユーザービリティテスト

パフォーマンス/負荷テスト
セキュリティテスト
「～性」テスト
ツール

自動技術面
9

JaSST'10 Tokai

5. アジャイルテストにおける自動化
5-2.第1象限おけるツール活用－xUnit アジャイルテストの自動化は単体テストが基本
 一般的にxUnit系のツールを用いて、テスト対象のシステムと同じ言語で記述される 自動ビルドのプロセスで自動単体テストを実行させ、素早いフィードバックを実施することが必要
Eclipse + JUnit/djUnitの例

レポート
作成
1. IDE上でテストコード（Java）を記述
2. ビルドのプロセスでAnt, Mavenなどから自動単体テストを実行
10

JaSST'10 Tokai

3. Junitの結果やdjUnitのカバレッジ・レポートをフィードバック5. アジャイルテストにおける自動化
5-3.第2象限におけるツール活用－Fit/FitNesse チームを支援するビジネス面のテストにも、自動化ツール適用の効果がある
テスト記述ファイル(html)

Fixture入作成

力System / Program

ビジネスアナリスト

FitNesse:
Fitが組み込まれたWikiサーバー
FitNesseを使用すると、テストの記述、テストデータの投入、結果の表示をWiki（Webブラウザ）から行うことができる。

Fit Runner
確Test
実行

力認

確認

出プログラマー

テスト結果ファイル(html)

Maven, Antなどからビルド時に自動実行
開発

11

JaSST'10 Tokai

5. アジャイルテストにおける自動化
5-4.第3象限におけるツール活用－Data Generator
 第3象限のテストにおいても、テストデータの作成など自動化が可能
各項目を指定Result type： 出力形式を選択。SQLを選択するとMySQL、OracleのSQLを生成（Create Table、INSERT ）Contry-specific Data： 郵便番号などで選択した国の形式が利用可能
Number of results： データの生成件数を指定
各カラムのデータ情報を設定しGenerateをクリックするとデータをダウンロード

生成済みデータ例

12

JaSST'10 Tokai5. アジャイルテストにおける自動化
5-5.第4象限におけるツール活用－自作負荷テストツール
 現実には、申請・承認などを伴うワークフローアプリケーションが多い。
 パフォーマンステストは、ワークフローを始めから終わりまで全部実施しようとすると、大部分のアプリケーション開発が終了するのを待たなければならない。
 プロジェクトの早期にテストを実施する方法を見つける必要がある。
自作負荷テストツールの例
開発の背景– HTTPサーバーのコードが完成する前に業務アプリケーションのパフォーマンス・テストを行いたい– 業務アプリケーション単体のパフォーマンス・テストを行いたい– ハブサーバー経由のパフォーマンス・テストを行いたい⇒ MQ のプロトコルでXMLメッセージを送受信する負荷ツールが必要
既存の負荷ツールが使用可能
LoadRunner, RPT, Etc.

既存のものが無いのでMQ用の負荷テストツール
MQ用の負荷ツール新規開発が必要
オンライン
アプリケーションサーバー

HTTP/HTMLMQ/XMLMQ/XML
ユーザー
フロントハブ端末
サーバー
サーバー
HTML/XML変換
13

XMLフォーマット
変換

EJB
業務アプリ
ケーション

MQI

XML/Javaオブジェクト
変換

JaSST'10 Tokai

5. アジャイルテストにおける自動化
5-6. 継続的インテグレーション－Rational Team Concert (RTC)
 正常に動くビルドを少なくとも1 日1 回作り出す。
 毎日統合ビルドを実施することで、プログラム間の不整合を早期に発見可能である。
 実現にはソース統合、ビルド自動化、テスト自動化が必要である。
既存ツール

Jazz
Rational Team Concert (RTC)

要件担当

要求管理

ビルド自動化

設計担当
変更管理
実装担当
構成管理
テスト担当
14

14

テスト管理
JaSST'10 Tokai

ソース統合

ビルド管理

構成管理

プロセス管理障害管理

Jazz Team Server
テスト
自動化

アジャイル
チーム#1

アジャイル
チーム#2

14

5. アジャイルテストにおける自動化
5-7.自動化ツール活用のポイント
 アジャイルテストの4象限およびテスト自動化のピラミッドを用いてどこでテスト自動化が必要かを判断しツールを活用する
低

ビジネス面

手動

自動と手動

第3象限
第4象限

GUI
テスト
受入テスト
（APIレイヤー）

パフォーマンス/負荷テスト
セキュリティテスト
「～性」テスト

単体テスト
コンポーネントテスト

単体テスト／コンポーネントテスト

ツール

自動

投資対効果

探索的テスト
シナリオ
ユーザービリティテスト
ユーザー受入テスト
アルファ/ベータ

製品を批評するチームを支援する

機能テスト
例
ストーリーテスト
プロトタイプ
シミュレーション
第2象限
第1象限

手動テスト

技術面

高

アジャイルテストにおいて自動化の効果が最もあるのは単体テスト。
ピラミッドの頂点から自動化を始めるのではなく、基礎がきちんとしていることを確かめながら底辺から始めるべき。
15

JaSST'10 Tokai※「実践アジャイルテスト」(翔泳社)274ページ図14-2より引用

5. アジャイルテストにおける自動化
5-8. アジャイルチーム全体のアプローチ
 テスターや品質保証の人たちだけが、品質に責任をもっているわけではない。
アジャイルチームはすべてのテスト作業に責任をもつ。
– FitNesseなどのツールを使用することにより、ビジネスアナリスト、プログラマ、テスターがひとつのフレームワーク上でテストケース作成からプロダクト開発まで作業ができる。

プログラマ(3)プロダクトを開発

ビジネスアナリスト(1)Wikiにテストケース作成(2)Fixtureを開発
テスター
16

JaSST'10 Tokai6．おわりに本日のまとめ
1. アジャイルテストとはアジャイルソフトウェア開発におけるテストの考え方、およびプラクティスのことである。
2. チーム全体アプローチは日本で既に取り組まれているアプローチであり、日本はアジャイルテストのプラクティスを適用しやすい環境にあると考えられる。
3. アジャイルテストの自動化においてはアジャイルテストの4象限およびテスト自動化のピラミッドを用いてどこでテスト自動化が必要かを判断しツールを活用する。
4. テスターや品質保証の人たちだけが、品質に責任をもっているわ
けではない。アジャイルチームはすべてのテスト作業に責任をもつ。

17

JaSST'10 Tokai

18

JaSST'10 Tokaiワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。本プレゼンテーションに含まれている情報については、完全性と正確性を帰するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保証も伴わないものとします。本プレゼンテーションまたはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、IBMは責任を負わないものとします。 本プレゼンテーションに含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結果を生むものでもありません。
本プレゼンテーションでIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありません。本プレゼンテーションで言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。
パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。

19

JaSST'10 Tokai

記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。
IBM、IBM ロゴ、ibm.com、AppScan、Build Forge、DOORS、Policy Tester、PurifyPlus、Rational、Rational Team Concert、Rhapsody、System i、System zは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。
他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。
現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。
Adobe, Adobeロゴ, PostScript, PostScriptロゴは、Adobe Systems Incorporatedの米国およびその他の国における登録商標または商標です。
IT Infrastructure Libraryは英国Office of Government Commerceの一部であるthe Central Computer andTelecommunications Agencyの登録商標です。
Intel, Intelロゴ, Intel Inside, Intel Insideロゴ, Intel Centrino, Intel Centrinoロゴ, Celeron, Intel Xeon, Intel SpeedStep, Itanium,
Pentium は Intel Corporationまたは子会社の米国およびその他の国における商標または登録商標です。
Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。
Microsoft, Windows, Windows NT および Windowsロゴは Microsoft Corporationの米国およびその他の国における商標です。
ITILは英国Office of Government Commerceの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。
UNIXはThe Open Groupの米国およびその他の国における登録商標です。
Cell Broadband Engineは、米国およびその他の国におけるSony Computer Entertainment, Inc.の商標であり、同社の許諾を受けて使用しています。
JavaおよびすべてのJava関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標。

20

JaSST'10 Tokai