メディア

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

» 2008年06月24日 12時00分公開

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

前のページへ 1|2|3 　　　　　　

■ 製品サイクルの初期に排除されるバグ

　イテレーション期間中にリグレッション、負荷、およびデータ持続性のテストを実行するため、バグはそれが作り込まれてからすぐに排除された。製品コードが開発者の頭の中で新鮮に記憶されているため、システムテストチームは開発部隊からすぐに修正コードを受け取ることができた。バグ修正のターンアラウンド・タイムが早く、正確なテスト環境が残っているため、アジャイル環境の方がシステムテストによる修正の検証が簡単だった。同じユースケースに同じスケジュールで取り組んでおり、いずれも同じ優先事項を持つことから、開発者とシステムテスターとの間のコラボレーションも良かった。これにより、バグの特定、修正、検証が従来より円滑かつ迅速になった。

　初期のイテレーションでは、基本的な製品機能のテストが行われた。この間はシステムテストアプリケーションも基本的でもっとシンプルだったが、バグを見つけ出すために特定の負荷や時間をかけて実行することができた。この後のイテレーションでは、製品の機能が増えて、構成も複雑になった。また、システムテストアプリケーションも機能が高まり、複雑になった。さらにその後のイテレーションでは、負荷のレベルが高まり、テスト時間も延びた。これらのイテレーションではもっと複雑なバグが見つかったが、それでも製品にそのバグが混入してから早期に発見された。

　アジャイル開発サイクルの最中、おおむね開発作業の重点はシステムテストで発見されたバグの修正に重点が置かれた。その結果、バグは早く検知され、短時間で修正された。

■ プロセスの進化

　アジャイル環境自体は、継続的にプロセスを強化することを可能にする。イテレーション期間の最後には、すべての関係者が問題点を特定し、全体的な改善と効率を示唆できるようにする「教訓」セッションがあった。

　アジャイルモデルの重要な特性の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年間在籍している。

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

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