アジャイルとシステムテストの新たな関係（後編）：The Rational Edge（2/2 ページ）

[Mary Ellen（Kerr, System Test, IBM）, Curt J. Rousse,（System Test, IBM）, Donna P. Dynes,（Development Manager, IBM）, Dave Booz（Development Manager, IBM），＠IT]

アジャイルシステムテストのメリット

　アジャイルシステムテスト活動に関連して得られたメリットの中で、特に目立ったものを以下に挙げる。

■ システムテストアプリケーションの信頼性向上

　開発されたシステムテストアプリケーションは、複数のイテレーションにまたがって継続的に強化が行われたため、極めて高い品質を持っていた。これらに改良を加える際は、バリデーション、ロギング、そして例外処理など、アプリケーションのほかのさまざまな側面も改善された。従来のようにテスト準備フェイズに集中して開発するのではなく、何カ月もかけて開発されたテストアプリケーションは、一段と堅牢なものとなった。

■ フルシステムテストの立ち上げ準備時間短縮

　アジャイル環境において開発部門と密接に協力するコアシステムテストチームは、開発組織に大きな潜在的メリットをもたらす。このコアチームは、製品リリース前の最終システムテスト中に使えるシステムテストアプリケーション、シナリオ、そして自動化スクリプトの一部を用意することができる。開発部門と一緒にこれらの素材を製作および実行することは、システムテストチーム全体の生産性向上とスピードアップの促進に役立っていく。

　スキルトランスファーの観点から、システムテストのコアチームはシステムテストチーム全体に対し、適切なタイミングで新技術を導入し、コンテンツをリリースすることができる。コアチームは顧客志向のアプリケーションデザインを提示し、チーム全体に対してそのアプリケーションのデモを行うほか、開発資料の適切な箇所を提示したり、開発担当者の連絡先を用意して、フルシステムテスト・イテレーションの準備を早めることができる。

■ フルシステムテスト開始時の製品品質向上

　システムテストのコアチームは製品開発サイクルの早い段階でシステムテストの一部を実行しているため、コードの品質はフルシステムテスト開始時には一定の水準まで高まっており、これによりシステムテストチーム全体の生産性に確実にいい影響を与える。さらに、初期のシステムテスト作業をシステムテストコアチームが行い、続けて製品リリース前の集中フルシステムテストを行うというリリースサイクルは、従来の開発／テスト手法よりも高い品質を提供することができる。

　ただ、本稿執筆時点では最終システムテストのイテレーションにはまだ入っていないことに注意したい。この開発イテレーション中、ストレス関連やメモリリーク関連のバグの一部は、正式なシステムテスト開始前に排除できなかった。

アジャイルシステムテストの総括

　本稿で解説したプロジェクトは、小規模のものだ。参加したのはマネージャ、アーキテクト、開発者、そしてテスターを含めて約55人だ。チーム全体はさらに12の小チームに分かれており、これには今回の開発のベースとなった2つのオープンソース技術に取り組むチームも含まれていた。小チームはそれぞれ別の場所で作業をしていたが、各チームのサイズが小さいため、プロジェクト全体でアジャイル開発の手法を採用することはかなり容易だった。

　ウォーターフォール手法を使った前年のプロジェクトも、今回のプロジェクトで使われた技術の予備知識となった。アジャイルコンセプトへの移行は、この技術に関する予備知識によって容易になった。今回のプロジェクトでは、新技術の導入に伴う問題は発生しなかった。

　第1イテレーションは、すでに開発が進んでいた成果物を完成させ、アジャイルプロジェクトを開始する移行のためのイテレーションとして使われた。アジャイル開発への移行は控えめに始まり、最初の2つのイテレーションでは開発目標は控えめに抑えられた。チーム全体における個人間の文化の構築と、新しい環境におけるチーム成功のための初期システムテストアプリケーション並行開発・実行といったプロセスの確立に主眼が置かれた。本プロジェクトの結果から、ウォーターフォール開発からアジャイル開発への移行には十分な時間をかけた方がいいことが分かった。

　システムテストコアチームは、6回のイテレーションにわたって開発チームと共同で作業を行った。これにより、従来のシステムテストアプリケーション開発と実行の一部がイテレーションごとに実現した。この並列化は、以下のような成功へとつながった。

• 複数のイテレーションにわたり、より堅牢かつ現実的なシステムテストアプリケーションを徐々に構築できた。
• 開発、機能検証テスト、システムテスト間の密接なコミュニケーションにより、複数の観点からシステムテストの実行を具体化できるようになった。
• プロジェクトで使われる技術と環境に関するスキルが深まった。
• システムテストで発見された一部のバグを製品サイクルの初期段階で排除できた。
• イテレーションごとにプロセスやテストが改善していった。

筆者プロフィール

メアリー・エレン・カー（Mary Ellen Kerr）

WebSphere Application Serverのシステムテスター。IBMには25年間在籍している。

カート・J・ルーセ（Curt J. Rousse）

WebSphere Application Serverのシステムテスター。IBMには30年間在籍している。

ドナ・P・ダインズ（Donna P. Dynes）

WebSphere Application Serverの開発マネージャ。IBMには26年間在籍している。

デビッド・ブーズ（David Booz）

IBMのシニア・テクニカル・スタッフ・メンバー。IBMのOSおよびミドルウェア部門に19年間在籍している。

---

本記事は「The Rational Edge」に掲載された「An agile experience report: A model for system test」をアイティメディアが翻訳したものです。

---

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）