アジャイルとシステムテストの新たな関係（後編）：The Rational Edge（1/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]

アジャイルシステムテストの課題

　われわれがアジャイルシステムテスト作業中に直面した、いくつかの最重要課題を以下に示す。

■ 短いイテレーション期間

　システムテストシナリオのリグレッション･テストは、イテレーション期間の第2週から第6週にかけて行った。第2週から第4週にかけては、第5週から第6週にかけて新機能のテストに使えるよう、システムテストアプリケーションを強化し、単体テストを実行する必要もあった。

　そのため、新機能のためのシステムテストシナリオの実行は、第5週から第6週の間だけだった。この期間の長さは、その後のイテレーションでシステムテストの内容が複雑になってくると、今回の試みの中でテストされるシナリオの一部にとっては短すぎることが明らかになった。

本記事は、IBM developerWorksからアイティメディアが許諾を得て翻訳、転載したものです。

　例えば、テストにもっと複雑なトポロジーが必要で、3日以上の期間と、故障やフェールオーバーテストの複雑な作業負荷が絡むケースでは、割り当てられたスケジュール内にこれらの複雑なシナリオを組み入れることは困難なことが分かった。これらのより複雑なシナリオは、どちらかといえば難易度が高く、断続的にしか発生せず、デバッグが難しいバグを洗い出すためのものだ。このようなバグをトレースで再現するのも、パッチを適用してドライバとともに修正を検証するのも時間がかかった。これは、割り当てられたテスターが少ないために非常に困難なものになった。その結果、より複雑なテストシナリオやバグ検証の一部は、複数のイテレーションにまたがって行った。

　われわれはテストアプリケーションの開発を行いながら、同時にそれを使用してテストシナリオの実行を行った。しかし、テストアプリケーションの開発には1つのイテレーションで膨大な時間を消費し、シナリオ実行のための時間を圧迫した。だがこれは、テストアプリケーションへの一部機能強化を2つのイテレーションにまたがって行い、1つのイテレーションでアプリケーションの開発を行い、必要であればその次のイテレーションでシナリオを実行することにより多少緩和することができた。

　もう1つの課題が、イテレーションの結果のレビューとデモのタイミングだった。第6週では、システムテストチームが自分たちのイテレーションの結果をチーム全体に提示した。一部のイテレーションでは、テストの完成が最終週のプレゼンテーションに間に合わず、システムテスト結果のプレゼンテーションを次のイテレーションの第1週に動かす必要があった。

　また、システムテストチームが製品管理部門に対するデモの一部を担当し、イテレーションの成果物を披露することもあった。これらのデモには相当な準備が必要で、後のイテレーションになるほどシステムテストチームの参加は難しくなった。

　第5週から第6週を非常に難しくしたもう1つの要因は、開発者がシステムテストを実行できるようにし、その後のイテレーションでシステムテストを支援できるよう、開発者に訓練を施す必要があったことだ。しかしこれには、特定のイテレーションの中でシステムテストに割り当てられた開発者を、経験豊かなシステムテスターが指導する必要があった。そのため、そのテスターは割り当てられたシステムテスト項目を計画通りに消化するのが困難となった。システムテストを初めて経験する開発者には約1〜2週間の学習曲線が必要となるため、複数の連続したイテレーションの中でシステムテストに同じ開発者が割り当てられた場合（常に可能というわけではない）にしか、システムテストのメリットが実現できなかった。

■ 初となるアジャイル開発

　このプロジェクトは、チームメンバーの大半にとってアジャイル開発の初体験となり、開発とシステムテスト作業の並列化はチーム全員にとって新しいものだった。5人構成のシステムテストチームは、予想以上の残業をこなした。また、プロジェクト全体を通じて、システムテストチームメンバーを含む全員がイテレーションごとの作業のデザイン、開発、テストの規模を判断する方法を学んだ。また、過度な約束や誤った見積もりは、システムテストチームや、チーム全体の中のほかのメンバーにストレスを与えることになった。

■ ユースケースの扱い

　イテレーション全体を通じて標準化したユースケース命名手法を、アジャイルサイクルの早い段階で定義およびインプリメントする必要があった。絶対にシステムテストチームでユースケースが分からなくなることのないよう、そしてすべてのチームが各ユースケースを明確に特定できるよう、最初のイテレーションから最後のイテレーションまで標準化された「ユースケースID」を採用するべきだった。

　チーム全体のユースケースを一環して文書化するため、テンプレートが導入された。ユースケースの概念はチーム全体にとってまったく新しいものではなかったが、外部の顧客にとっての価値という意味からユースケースを提示することは、チームメンバーの大半にとって初めてのことだった。結果的に、イテレーションの最後にチーム全体（顧客担当チームを含む）からのフィードバックを検討する「教訓」セッションの結果いかんで、テンプレートやユースケースの記述の文言は頻繁に変わることになってしまった。

　プロジェクト期間中は、フォーマットを整えたユースケースドキュメントをそのまま顧客用のドキュメントとした。システムテストには標準の外部顧客レベルのドキュメントがなかったため、システムテストチームはこのようなタイプの顧客ドキュメントを検証することができなかった。この標準製品ドキュメントを将来的に作成するのであれば、新たに検証を行う必要があるだろう。