Computer Weekly製品導入ガイド

従来型テストではアジャイル開発に勝てない理由

従来のような方式のテストでは、大規模なテストを集中化して最適化することが可能だ。だがアジャイル開発のような速いペースの配信に対応するのは難しい。

　アジャイル方式に移行する開発者は、必然的に自分でテストを行うことが多くなる。従って品質保証（QA）のプロフェッショナルは、開発チームの日常業務への関与を深めることにより、状況の変化に対応する必要がある。テスト駆動型の開発や、テスト自動化の推進、持続的な開発と統合といった先進的な手法は、開発者やテスターの日常業務に大きな影響を及ぼす。

　テストの方式が変われば、開発チームによるテストツールの選定も変化する。開発者は、自分たちの統合開発環境（IDE）と連動させやすいツールを望む。これに対してQAなどのソフトウェアプロフェッショナルは、高いレベルの抽象化を実現できる使いやすいツールを求める。そうした中で、アジャイルチームが開発の流れに沿ってテストツール戦略を刷新するためにはどうすればいいのか。

　従来型のテスト方式は、Testing Centre of Excellence（TCOE）モデルを使う大規模な集中型のテストグループの業務に最適化した設計になっていた。だが、そうしたサービス共有型のアプローチはアジャイル開発チームの配信ペースの速さに対応できず、アジャイル組織では機能しない。

　例えば米財務省の金融管理サービス局は、TCOEを含む通常のIT部門のガバナンスプロセスから、大型アジャイルプロジェクトを完全に切り離す必要があった。同チームはBehaviour-driven Development（BDD）のアプローチを使ったテストと開発プロセスを採用し、大きな成功を収めた。

　同開発チームは、従来型のテストツールに勝る新しいアプローチに対応しているという理由から、オープンソースのテストツール「Cucumber」を利用した。その結果、TCOEガバナンスとプロセスの順守を強いられていたのでは実現できなかった高いレベルのテスト自動化とスピードが実現できた。

　テストチームが開発と切り離されていれば、テスト担当者は一般的に、できるだけ多くのバグを見つけようとする。だがその時点で開発者はコードを書き終えている。開発者はバグを修正する責任を負うものの、さかのぼって品質に十分な注意を払わなかった結果を目の当たりにすることになる。自分がやったことを修正するのは難しく、コストもかさむ。

　つまりTCOEでは、作業のアウトソーシングを通じて全体の作業量を減らし、コストを抑えている。だがそのコストは高いレベルでの解体修復作業を通じて開発サイクルに跳ね返ってくる。テスターによるバグ記録と開発者によるバグ再現・修正を支援するツールは役には立つが、解体修復のコスト高を招く体系的な問題解決の役にはほとんど立たない。

前倒し型テスト管理と変化の速い優先順位

　テスト実行業務を集中化した場合、アジャイル開発チームの特徴である急ピッチの軌道修正にテストスケジュールが追い付けなくなる。

この記事の著者