アジャイルとシステムテストの新たな関係(前編):The Rational Edge(3/3 ページ)
The Rational Edgeより: 自社製品の品質改善とタイムリーなリリースを行う手段の1つとして、多くの企業がアジャイル開発手法の採用を進めている。どの会社やチームも、アジャイル開発環境においてシステムテスト戦略を最良の形で実行に移す方法を見つけたいと考えている。
■ 製品サイクルの初期に排除されるバグ
イテレーション期間中にリグレッション、負荷、およびデータ持続性のテストを実行するため、バグはそれが作り込まれてからすぐに排除された。製品コードが開発者の頭の中で新鮮に記憶されているため、システムテストチームは開発部隊からすぐに修正コードを受け取ることができた。バグ修正のターンアラウンド・タイムが早く、正確なテスト環境が残っているため、アジャイル環境の方がシステムテストによる修正の検証が簡単だった。同じユースケースに同じスケジュールで取り組んでおり、いずれも同じ優先事項を持つことから、開発者とシステムテスターとの間のコラボレーションも良かった。これにより、バグの特定、修正、検証が従来より円滑かつ迅速になった。
初期のイテレーションでは、基本的な製品機能のテストが行われた。この間はシステムテストアプリケーションも基本的でもっとシンプルだったが、バグを見つけ出すために特定の負荷や時間をかけて実行することができた。この後のイテレーションでは、製品の機能が増えて、構成も複雑になった。また、システムテストアプリケーションも機能が高まり、複雑になった。さらにその後のイテレーションでは、負荷のレベルが高まり、テスト時間も延びた。これらのイテレーションではもっと複雑なバグが見つかったが、それでも製品にそのバグが混入してから早期に発見された。
アジャイル開発サイクルの最中、おおむね開発作業の重点はシステムテストで発見されたバグの修正に重点が置かれた。その結果、バグは早く検知され、短時間で修正された。
■ プロセスの進化
アジャイル環境自体は、継続的にプロセスを強化することを可能にする。イテレーション期間の最後には、すべての関係者が問題点を特定し、全体的な改善と効率を示唆できるようにする「教訓」セッションがあった。
アジャイルモデルの重要な特性の1つが、開発プロセスに進化が期待できることだ。これはシステムテストをはじめ、製品に関係するチームメンバー全員に当てはまった。生産性の改善方法に関する洞察は、イテレーションごとに実行された。学んだことや、改善できる点に関する考えを明らかにすることが各チームに求められた。悩むところや成功するところがあれば、チーム全体が一堂に会して議論した。この話し合いの中では、新たな改善点が特定され、オンラインのリポジトリに置かれ、次のイテレーションに反映された。
システムテスト関連のプロセス進化の具体例の1つは、システムテストチームがテストトラッキングプロセスを正式に定めた最初のイテレーション期間中にあった。これまで、テストトラッキングツールはシステムテストのシナリオやドキュメントテストの実行結果を定義するために使われていた。1回目のイテレーションでは、システムテストチームがこれらのテストシナリオ用にテンプレートを定義し、共通のコンフィギュレーションドキュメントを作成した。
これらのコンフィギュレーションドキュメントにより、システムテストチームはセットアップに必要な手順を詳述し、共通の資料から共通のシステムテスト手順を実行できるようになった。この1つの定義があることで、個々のテスターは重複したドキュメントの作成や保守を回避できるようになった。関連するすべてのテストシナリオがこの共通のドキュメントを参照した。
システムテストチームが自らのプロセスを徐々に改善していったもう1つの例は、最後のシステムテスト限定のイテレーションまで待たずに、3回目のイテレーションにメモリリーク分析が投入されたときだった。この変化は、前述のように実現されたコードの安定性によって可能になった。必要なツールやセットアップの指示は共通のコンフィギュレーションドキュメントに追加され、これが各テストシナリオから参照された。また、テスト完了時の詳細報告には各実行時のメモリリーク分析の結果も含まれていた。
システムテストチームは、再現可能で整合性のあるテストの実現を助けるため、詳細に文書化されたプロセスと規定を定義した。これらの多くは、このプロジェクトに向けたわれわれのテスト作業が開始される以前は分からない、もしくは定義できないものだった。これらのアイデアの幾つかは「発見」に基づいており、そのほかのものはその後のイテレーションにおける生産性改善への純粋な願望に基づいている。それまでの作業で得た「教訓」を生かし、モデルの柔軟性を重視する方針により、チーム全体で当初の問題点の回避や効率性の向上、そしてソリューションの試行が可能になった。
■ 重要機能の識別
システムテストチームは、3回目のイテレーションから重要機能シナリオの識別を進めた。4回目のイテレーションの確認ミーティングからは、システムテストチームのシナリオが重要機能かそれ以外かに分類された。イテレーションを完了するために、重要機能のシナリオではバグもパッチの適用もなく、すべてがうまく実行できる必要があった。重要機能テストのシナリオは、大体が前回のイテレーションで実行され、リグレッション・テストのシナリオとして繰り越されたテストケースだった。これらのテストシナリオは複数が組み合わされ、同時に実行される一連のテストを形成することもあった。大体の場合、組み合わされたこれらのテストは先のイテレーションよりも高い負荷で、最低24時間実行された。
一般に重要機能のテストのシナリオは、その後のイテレーションに投入する必要のある顧客の要件に基づいているが、現行のイテレーションで開発されている機能をベースにしている。これにより、初期のシステムテストと問題判別が機能検証直後に実行できるようになった。アジャイル環境におけるこのような新たな柔軟性により、システムテスト環境における複雑な問題の識別、隔離、追跡、パッチ適用、および実行が複数のイテレーションに渡るスケジュールで行えるようになった。
システムテストチームは、自分たちのテストトラッキングツールの中で重要機能のテストとそれ以外のテストのシナリオを切り分けた。イテレーション期間の第1週に行う確認ミーティングでは、シニアアーキテクトが各確認事項を重要機能とそれ以外に切り分ける際の指針を提示した。こうした分類はオンライン上の確認事項ドキュメントに記述され、その後これら確認事項のテスト実行記録作成時に利用された。
重要機能シナリオでは、イテレーション期間中の第5週および第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年間在籍している。
- トランザクション管理の複雑性を克服する(パート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プロジェクトを見える化する
- ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由(後編)
- 隣のテストチームが優秀ないくつかの理由(前編)
Copyright © ITmedia, Inc. All Rights Reserved.