アジャイルとシステムテストの新たな関係（前編）：The Rational Edge（1/3 ページ）
The Rational Edgeより： 自社製品の品質改善とタイムリーなリリースを行う手段の1つとして、多くの企業がアジャイル開発手法の採用を進めている。どの会社やチームも、アジャイル開発環境においてシステムテスト戦略を最良の形で実行に移す方法を見つけたいと考えている。
本稿で使う「システムテスト」という言葉は、ソフトウェア製品を顧客に提供する前に行われる最終製品テストを指す。このテストは、開発と機能検証テスト終了後に行われるのが一般的だ。コードのシステムテストが実行できるかどうかを判断するには幾つかの基準がある（リグレッション・テストの状況、バグ残数など）。システムテストを正式に開始し、結果を求めるにはこれらの基準を満たす必要がある。
典型的なシステムテストでは、顧客と同様の環境のシステムに、同様の作業負荷を掛けることが目的となる（マルチプラットフォーム、複数バージョンのソフトウェアなど）。正式なシステムテストには、負荷テスト、長時間運用、メモリリーク分析、マルチアプリケーション、複雑な各種トポロジー、高可用性／停止テスト、混在リリーステスト、フルプラットフォームテスト、製品統合テスト、およびドキュメントの検証が含まれる。
本稿は、あるチームがわれわれのアジャイル開発環境の一環として、コード開発と並行してシステムテストの一部を含める際に取ったアプローチを解説する。われわれはこのアプローチによって、システムテストアプリケーションの機能・品質が向上し、コード開発と並行してシステムテストの一部を含める価値と効率性を最大限に高める試みが可能になったこと、そしてチーム全体でコミュニケーションや技術スキルが向上したことを紹介していく。これらの成功は、ソフトウェア検証チーム全体の立ち上げ期間短縮や、フルシステムテスト開始時における製品品質の改善といった、予想通りのメリットにつながった。
システムテストのコアチームは、6回以上のイテレーション（反復）にわたって開発チームと同時に作業を進めた。これにより、従来のシステムテストアプリケーション開発とテスト実行の一部が各イテレーションごとに実現した。この並列化が、ここで説明されている成功へとつながった。
アジャイルプロセスのインプリメンテーションモデル
既存のウォーターフォール手法で1年間の開発を行い、アルファ版とベータ版を公開した後、われわれのプロジェクトは趣向を変えてアジャイル開発モデルを採用した。そしてアジャイル開発の原則を、特定の顧客の要件を満たすための「生きた試み」として受け入れることがチーム全体に求められた。
最初のイテレーションはウォーターフォールからアジャイルへの移行期間となり、従来の開発モデルで開発していたコードを完成させることに主な重点を置いた。最初のイテレーションの開始時には、デザイナー、開発者、テスター、ドキュメント担当、顧客担当からなるチーム全体で約55人だった。
第1イテレーションは移行のために使われ、すでに開発中だった成果物を完成させるために利用された。アジャイル開発への移行は控えめに始まり、最初の1〜2回のイテレーション中は開発の内容を適度に抑えた。ここで目玉になったのが、新しいプロジェクトやチームの枠を超えた個人間の文化の構築および伝達、そしてこの新しい環境でチームを成功させる早期システムテストなどのプロセスの統合だった。
先のウォーターフォール開発サイクル中は、システムテストチームの一部である9人のシステムテスターが非常勤で開発に参加した。コードは開発が進んでいたが、重点は技術スキルの構築、プランニング、テストケース開発、そしてアプリケーション単体テストに置かれた。そうした中、彼らはプロジェクトが利用する技術スキルを磨くことができたが、実践的な経験はあまり積めなかった。
アジャイル開発への移行当時、9人中5人のシステムテスターは、プロジェクトにフルタイムで配備された。従って、最初のイテレーション以前に、システムテストチームはすでに新技術を学習し、テストアプリケーションを作成し、チームとして共同作業を進めていた。これら初期のテストや開発作業により、アジャイルサイクルの開始時に高い生産性が実現した。
■ システムテストチームの参加で目指すゴール
5人のシステムテスターに与えられた課題は、どのイテレーションでもベータ版レベルに相当するコード品質を保証することだった。この課題に対応するため、彼らは最後のイテレーションを複雑で顧客に特化したシナリオベースのテストに集中させることを見越し、各イテレーション期間中に従来のシステムテストアプリケーションの開発および実行の一部を行うことにした。
システムテストチームはプロジェクトのシニアアーキテクトと話し合い、システムテスト強化および実行のためのシステムテストアプリケーションを一緒に選択した。このアプリケーションは、すべてのイテレーションにおける負荷テストと長時間運用テストに焦点を当てて使用され、最後のイテレーションでも徹底的に使用されることになる。そこには、システムテストのリソースを限定的かつ即時適用することで、プロジェクトがカットオーバーへ近づく中、最終的なフルシステムテストのための堅牢な基盤を確立する意図があった。
■ プロジェクトとイテレーションのスケジュール
各イテレーション期間は6週間となっていた。表1は、一般的なイテレーションの内容と、毎週予定される具体的なシステムテスト作業を示している。各イテレーションの第1週では、シニアアーキテクトがテスト候補となる機能リストを提案した。このリストは主に具体的な顧客の要件を基本にしており、ユースケースを使って解説が行われた。このリストは、イテレーションの進展に合わせてチームメンバー全員がユースケースを洗練させられるように、ネット上で共有できるようにした。チームの各メンバーが候補リストを調査し、デザインを協議し、チームメンバーやシニアアーキテクトと議論して、イテレーションの最後で提供する（あるいはしない）機能を週末までに確定する。
スクラムミーティングは毎日開催された。シニアアーキテクトも大半のスクラムミーティングに出席し、すべてのイテレーションでチームのメンバー全員がコンタクトできた。
前述のように最後のイテレーションは最終的なバグの排除と、それ以前のイテレーションでの実施は現実的でない複雑なテストに重点を置くために計画された。安定性を高めるため、最後のイテレーションには新機能の追加を予定しなかった。
最終的に、6回のイテレーションが実施された。また、最後のイテレーションでは、相当数の開発者がシステムテストチームのメンバーに加わり、最後のイテレーションを完了するためにテストの実行とデバッグを支援する予定だった。また、残りの開発者はバグを処理する。これは、初期のイテレーションにおける開発フェイズでは、最後のイテレーションに備えて一部の開発者がシステムテストのトレーニングを受ける必要があったことを意味する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Copyright © ITmedia, Inc. All Rights Reserved.