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

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

アジャイルシステムテストで成功した部分

　ここからは、われわれのアジャイルシステムテスト作業で達成した重要な成功、直面した課題、そして得られたメリットについて解説していく。まずは成功した部分からだ。

■ より堅牢かつ現実的なシステムテストアプリケーション

　このアジャイル開発サイクルは顧客から始まった。アーキテクトは、経営目標、IT戦略、アプリケーションの方向性、そして優先事項を理解するために顧客と頻繁に話をした。システムテストチームはそのイテレーションで検証するユースケースを分析し、外部の顧客にとって重要だと考えられるユースケースの一部をベースにしてテストアプリケーションの強化点を設計した。このテストアプリケーション強化点が広範に及ぶ場合は、前回のイテレーションで強化点を開発し、テストアプリケーション開発のために時間を確保した。そして、アプリケーションが早く強化できる場合は、現在のイテレーションの中で開発を行った。

　第2週に入ると、システムテストチームがテストアプリケーションのデザイン強化点をアーキテクトに示した。ここから話し合いが始まり、それによってアーキテクトの勧告を受け入れる機会がシステムテストチームに与えられた。アーキテクトの方もこれにより、検討していなかった可能性もあり、製品デザインの変更につながる場合もあるシステムテストの視点を得ることができた。システムテストチームとアーキテクトや開発チームとの密接な協力関係から、システムテスターは顧客の要件を一段と深く理解できるようになった。

　開発作業に少数のシステムテストチームを含めることにより、システムテストチームははるかに堅牢で「顧客指向」のテストアプリケーションを段階的に開発できるようになった。こちらの方が、ウォーターフォール開発サイクルにおいて従来行われてきたことよりも現実的なアプローチだった。大きな成果物の理解とテストを短時間で行うことを余儀なくされるのではなく、システムテストチームが成果物そのものの作成に参加できるようになるためだ。アジャイル開発サイクルにより、アプリケーションの設計からコード開発、そしてシステムテストアプリケーションの単体テストまで、システムテストチームはまるで本当のユーザーのような視点でシステムに接することができた。

■ 開発チームとシステムテストチーム間の密接なコミュニケーション

　アジャイル開発手法の採用とシステムテスト作業の導入がもたらした大きなメリットの1つが、毎日スクラムミーティングに参加することにより、開発チームとシステムテストチーム間のやりとりが増え、その内容も深まったことだった。その結果、システムテストチームはテストプランやテストアプリケーションに影響を与える現在の問題、発見されて間もないバグ、デザインの修正などを見抜けるようになった。

　スクラムミーティングは、システムテスターが同時進行中のシステムテスト中に発見した問題をレポートする際も、開発チームにメリットを提供した。毎日行うスクラムミーティングのコミュニケーションにより、複数の開発者による調整や理解が必要だと思われる問題が、関係者全員にシステムテストで簡単に表せるようになった。

　さらに最後に、スクラムミーティングによってシステムテストのアプローチが現行のコードベースの機能と一致しないときは、開発チームがそれを指摘できるようにもなった。

　開発チームとシステムテストチームの密接なコミュニケーションのもう1つの重要なメリットは、開発中の製品ビルドに新機能が搭載された際に、システムテストチームが即座にそれを認識できることだ。システムテスト、コーディング、そして単体テストの期間は1回のイテレーション期間中にわずか3週間しかないため、利用可能な機能を素早く伝達することが重要になる。システムテストチームでは、そのイテレーション時の製品機能のテストと同時に、テストアプリケーションの開発も進めているときがあるため、これが重要になる。

　システムテストは、テストアプリケーションの強化や、その改良のための単体テストを非常に素早く行えるということを覚えておきたい。必須の機能がビルドの中にあるというタイムリーな通知をシステムテストチームが受け取ることができたため、テストアプリケーションのテストを素早く実施することができた。

　アーキテクト、開発者、およびシステムテスターの間の密接なコミュニケーションにより、チーム全体が複数の観点やアドバイスを受けるメリットを享受できるようになり、コードの品質と完成度が向上した。

■ システムテストスキルの深まり

　アジャイル開発サイクル中にシステムテストの一部を含めるもう1つの利点は、これがシステムテストアプリケーションの開発およびテストスキルの深化を促進することだ。

　この人数の少ない「コア」システムテストチームは、リリースサイクルのかなり早い段階でプロジェクトに割り当てられている。アジャイル開発サイクルのイテレーションの特性により、システムテストチームは長い期間をかけ、小さく、かみ砕きやすい単位で製品を理解できるようになった。

■ システムテストの一部をイテレーション全体を通じて行う

　イテレーション期間中に割かれるシステムテストの時間が限定されていたとしても、その一部はイテレーション全体を通じて実施された。テスト全体を通じて負荷テスト、メモリリーク分析、データ整合性テスト、およびリグレッション・テストを実現するため、各種自動化テクニックが採用された。

　負荷ツールにより、システムテストチームは特定の期間クライアントの数をシミュレートしてテストアプリケーションを実行できるようになった。ブラウザの操作をキャプチャする実行スクリプトが幾つかあり、これを再生することで、実行は自動化できるようになった。これらのスクリプトはさらに、ランダムなデータも生成できるようにし、これが顧客との多様なやりとりをシミュレートした。関連するコンフィギュレーションスクリプトでは、実行するたびにテスターが望ましい期間とシミュレートされるクライアント数を指定することができた。

　彼らは、定期的に製品ログや負荷ツールのログをチェックすることで実行の様子を監視した。負荷ツールは統計情報も生成し、そこから潜在的な問題の兆候や想定外の動作が分かった。負荷ツールは最初のイテレーション後も、すべてのテストで利用された。

　コードが安定し、それにより長期間テストの実行が可能になると、3回目のイテレーション完了時からメモリリーク分析が追加された。各テストに先駆け、システムテスターは複数の製品パラメータのコンフィギュレーションを行い、テスト中にメモリリーク分析情報を収集できるようにした。そして、実行が終わるたびに実行時のログをメモリリーク分析ツールに入力し、一連のグラフが生成された。これにより実行中のメモリ利用率を見て、メモリリークの兆候をチェックできるようになった。メモリリークが見つかると、バグレポートを開いて追跡が行われた。最後の実行が問題なく完了すると、テスターはテストトラッキングツールの完了記録に情報を入力、これが最終的なメモリリーク分析結果を示した。

　システムテストの一部が実行されていることを確認するため、テストシナリオの中でデータ整合性テストを行う場合もある。テストアプリケーションは、データ持続性をIBM DB2に大きく依存していた。このアプリケーションは、一連のトランザクションの作業負荷で構成されており、データベースにある同じ一連のテーブル更新処理を行う。これらのトランザクションの作業負荷は同時に実行されるため、作業負荷をかけ、データベースの争奪を意図的に作り出した。そこには、トランザクションのロールバックを強制的に発生させ、リカバリを確実に成功させる意図があった。すでにロックのかかったレコードでアップデートを実行しようとすると、トランザクションはロールバックされ、後で再試行される。実行が完了すると、データベースの処理がすべて完了し、トランザクションはすべて照合が行われる。

　データベースの一貫性チェックについては、テストアプリケーションに組み込まれた。アプリケーションが保持するデータは、複数のテーブルに渡って相互に関係のある値で構成されていた。テスト実行終了時にはテスターが付加的なテストを実行し、各テーブルにあるデータ相互の整合性を検証した。

　2回目のイテレーションからは、リグレッション・テストも行われた。これは、前のイテレーションのシステムテストアプリケーションのバージョンを、現在のイテレーション用のビルドに対して実行することで、イテレーションごとに実行された。これらのテストは、その後のイテレーションに進んでいくと、同時に実行されてきたこれまでのテストの集合へとすぐに変わった。これによって、バグ修正により新たに作りこまれたバグ、いわゆる「リグレッション・バグ」は、ウォーターフォールのようにテストの最後ではなく、イテレーションのプロセス全体で特定し、処理できるようになった。

　従って、リリースサイクルが一連の比較的短いイテレーション期間で構成されていたにもかかわらず、システムテストの一部を実行することができた。負荷テスト、メモリリーク分析、データ整合性テスト、およびリグレッション・テストはいずれも、チームが利用した自動機能があったために実現できた。この種のテストは、シミュレートされた顧客環境における製品コードの安定性に信頼を与えた。