Computer Weekly製品導入ガイド

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

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

公開 2014年09月16日 08時00分

著者

Diego Lo Giudice

[Computer Weekly]

印刷する Googleで優先するソースとして追加

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

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

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

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

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

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

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

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

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

Computer Weekly日本語版　9月3日号無料ダウンロード

本記事は、プレミアムコンテンツ「Computer Weekly日本語版　9月3日号」（PDF）掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

Computer Weekly日本語版　9月3日号：企業はApple製品を受け入れるべきか？

なお、同コンテンツのEPUB版およびKindle（MOBI）版も提供しています。

　ユーザーストーリーが変わると、アジャイルチームは従来型のTCOEでテストケース確立のために使っていた正式な細かい要件にはあまりこだわらず、バックログで優先順位を変更することがある。従来のような前倒し型のテスト管理（TM）やプランニングプロセスは、刻々と変わる優先順位や、アジャイルメソッドに必要とされる短いサイクルに対応できる設計にはなっていない。TMツールがアジャイルプロジェクト管理要件のバックログと連携していなければ、問題はさらに複雑になる。

　テスターを開発者から切り離せば、継続的な配信の流れにその仕事を組み込むことは難しくなる。動きの速いチームはコードを開発してからテスト組織に引き渡すのではなく、コードを開発してアプリケーションを導入し、それを実行して直ちに結果を観察する。特にこれは、Webアプリケーションやモバイル開発で一般的な多変量テストを採用している開発チームに当てはまる。こうしたチームは変更を加えるとそれをサーバのサブセットに導入し、それぞれの系統で実行した結果を比較して、その変更がうまくいったかどうかを判断する。Blue-Green Deployment（Netflixの場合はRed/Black）を採用しているチームは、システムテストとユーザー受け入れテスト環境を複数の本番環境に入れ替えて、常に1つの環境を拡張しながら別の環境を停止させている。

従来型のテストがアジャイルに追い付けない理由

　従来型のテストがアジャイルチームに追い付けないのは、手作業による大量のテストが配信を遅らせているためだ。Testing Centre of Excellence（TCOE）におけるソフトウェアのテストでは、手作業のテストが最も古く、そして最も一般的なアプローチであり続けている。テストのプロフェッショナルはできるだけ多くの機能を網羅するテストケースを作成し、それが問題を悪化させる。手作業のテストは時間がかかり、リソースを集中的に消費するという現実を免れる方法は存在しない。問題のある手作業テスターをまとめて切り捨てたところで解決はしない。手作業テストは単純に、アジャイル配信チームによる日々の開発や継続的な統合、機能的および非機能的テストのペースに追い付けない。以下のポイントは、従来型のテストがIT開発プロジェクトのライフサイクルに及ぼす影響を物語っている。

プロジェクトの終盤までテストを先延ばしにしてプロセスに詰め込む

従来型テストのアプローチでもう1つありがちな矛盾点は、開発が終了してシステムに組み込んでからテストを開始することにある。これは手作業のテストに経費と時間がかかることも一因だ。残念ながらプロジェクトのスケジュールに遅れが出ると、終盤に残された作業は詰め込み状態になって犠牲にされる。結果として他のプロセスの遅れを埋め合わせるためにテスト時間が犠牲になり、品質に影響が出る。

後になって発覚した欠陥がプロジェクトの足を引っ張る

欠陥が放置されたままコード存在している時間が長引くほど、開発者が修正するのに時間がかかり、プロジェクトの締め切りにとって悲惨な結果をもたらす。開発者は新しいコードと新しい問題に移っているので、既に達成済みの機能については経緯が思い出せなくなっている（先週の月曜のランチに何を食べたか覚えているだろうか？）。何週間も何カ月も前に書いた欠陥に立ち戻る必要が生じた場合、そのコードにまつわる経緯を再び把握するのは時間がかかる。

技術的ツケの重なり

開発サイクルの終盤になってアプリケーションに重大な品質問題が発覚すれば、期限通りに配信できなくなるのは必至だ。終盤での欠陥の発見は、大量のやり直し作業と浪費につながる。その品質問題が、例えばアーキテクチャの設計問題など体系的なものである場合や、基本的なユーザー機能が欠けているのが見つかった場合、さらに事態は悪化する。テストを早く始めるほど、特にシステムテストやユーザー受け入れテストの場合は、システム的なリスクの表面化が早まる。

Computer Weekly日本語版最近のバックナンバー

Computer Weekly日本語版　9月3日号：企業はApple製品を受け入れるべきか？

Computer Weekly日本語版　8月20日号：Windows 9は必要なのか？

Computer Weekly日本語版　8月6日号：RAIDはもういらない

Computer Weekly日本語版　7月16日号：Windows 8をめぐる中国 vs. Microsoft

印刷する

この記事の著者

Diego Lo Giudice

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

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

Computer Weekly日本語版　9月3日号無料ダウンロード

従来型のテストがアジャイルに追い付けない理由

Computer Weekly日本語版最近のバックナンバー

この記事の著者

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

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

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

Computer Weekly日本語版 9月3日号無料ダウンロード

従来型のテストがアジャイルに追い付けない理由

Computer Weekly日本語版 最近のバックナンバー

この記事の著者

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

Computer Weekly日本語版　9月3日号無料ダウンロード

Computer Weekly日本語版最近のバックナンバー