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