脱Excel！ TestLinkでアジャイルにテストをする：エンジニアがお薦めする 現場で使えるツール10選（5）（1/6 ページ）
ITエンジニアの業務効率を改善するために、現役エンジニアが実際の現場で利用している便利ツールを、10回にわたり紹介します。
今回はTestLinkをテスト工程でどのように使うのか、テスト特有のマネジメント手法や概念を、TestLinkの機能に合わせて詳しく説明した。
【1】TestLinkの概要
TestLinkはPHPで作られたテスト管理Webシステムである。最新版はVer 1.8.3 （2009年6月）で、GPLで公開されている。WAMP、LAMP環境で動作する。
主な機能は下記である。
（参考：「きちんと学びたいテストエンジニアのためのTestLink入門」（gihyo.jp）、「簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト」）
- 数千から数万のテストケースを一括登録して貯蔵できるので、テストケースを再利用できる
- テストケースとは別に、テスト実施結果を履歴として残せる
- テスト実施結果をいろいろな観点で集計できる
- テストケースからバグ管理システムと連携してバグ修正 ＆検証フローを管理できる（Mantis、Bugzilla、Trac、Redmineなど）
- 要件仕様とテストケースを関連付けて、要件カバレッジを出力できる
テストケースの登録・実行・集計を一元管理できるため、特に結合テスト以降で、数千から数万のテストケースの一括管理を行う場合に有用である。バグ管理システム（BTS）との連携も簡単で、テスト工程の進ちょく管理に大きな威力を発揮する。最近は、TestLinkによって、Excelのテスト仕様書をWeb化する機能が注目されている。
国内の事例は乏しいが、海外ではいくつかの事例がある。
【1−1】TestLinkのインストール
インストール方法は下記を参照してほしい。
⇒ きちんと学びたいテストエンジニアのためのTestLink入門（gihyo.jp）
なお、本稿ではTestLinkのインストールやカスタマイズ方法については解説しない。TestLinkCnvMacro（以下、Ver 4.5bで説明する）というExcelマクロを組み合わせた運用方法を中心に、TestLinkのVer 1.7.4の機能について解説する。
【2】TestLink運用前のテスト工程における問題点
筆者がTestLink運用前に持っていたテスト工程の問題点は下記2点あった。
【2−1】Excelのテスト仕様書は進ちょく管理がやりにくい
普通のプロジェクトでは、単体テストから受け入れテストまでのすべてのテストケース数が数千から数万に及ぶため、仕様変更に対応しながら、テストを漏れなくきちんと管理していくのは非常に難しい。
また、テスト工程で人員が最大化するため、管理者は日々の進ちょく管理やExcelによるテスト実績の集計に忙殺されやすい。
そのため管理者は、再テストやバグ修正の作業指示を場当たり的に出すだけで1日が終わるときも多い。
第三者から眺めると、失敗したテストケースが多くなるほどチームが混乱しているように見えるのではなかろうか。
【2−2】アジャイル開発でも結合テストから受け入れテストまでの品質を確保するのは難しい
筆者は、【2−1】の問題点に対し、XP（eXtreme Programming）のプラクティスの実践例であるJUnitによる単体テストの自動化や、Hudsonによる継続的インテグレーションを実践してみた。
これらのプラクティスのおかげで、単体テストまでの品質は確保できたが、結合テスト以降、特に受け入れテストの品質を確保するのは依然難しかった。
理由は、結合テスト以降のテスト工程では、Seleniumなどですべてのテストを自動化するのは難しく、手動でテストせざるを得ないからだ。
以上をまとめると、結合テスト以降のテスト工程の管理が難しい原因は2つある。1つは、受け入れテストの自動化が難しいこと、もう1つは手動の受け入れテストの生産性が悪いことである。この2つのうち後者の解決を目指して、TestLinkを導入した運用方法について述べる。
【3】TestLinkの運用サイクル
筆者は、上記の問題点に対し、TestLinkをアジャイル開発へ組み込むために、下記のような運用方法を試みている。
前提として、手動のテスト管理の効率を上げるために、TestLinkを結合テストから受け入れテストまでに導入する。
単体テストはJUnitでテストを自動化できているため、TestLinkでは結合テスト以降の業務シナリオベースをテストの対象とする。
結合テストから受け入れテストまでのテストケースは、TestLinkの「テスト計画」の単位に分割してグループ化する。TestLinkの「テスト計画」をXPのイテレーション、Scrumのスプリントに見立てて、アジャイル開発のプロセスに組み込む。
次に、TestLinkの「テスト仕様」へテストケースを一括登録し、TestLinkのそれぞれの「テスト計画」へアサインする。例えば、TestLinkCnvMacroであらかじめテストケースを作っておくと、数千のテストケースをTestLinkへ一括インポートできる。
「テスト計画」にあるこれらテストケースを、テスター（テスト担当者）は1つずつテストしていく。テストの進ちょく状況は、TestLinkのテスト結果集計機能によって、リアルタイムに可視化できる。テスターがテストに失敗すると、BTS（例：Redmine）のチケットにバグの現象を登録し、開発者と共有する。TestLinkはBTSと連携する機能があるので、テスターと開発者の間で、バグ修正とバグ検証のワークフローを容易に管理することができる。
このテスト計画を2〜4週間のサイクルでアジャイルにテストしていく。ただし、テスト計画のテストケース数が膨大な場合、TestLinkの「テスト計画」を複数個に分割して実施するテスト戦略（イテレーション計画）が必要になる。「テスト計画」のテストケースをすべて成功に導けたら、リリースするように運用する。
TestLinkのテスト実施結果は「ビルド」と呼ばれており、テストケースとは別の概念として存在する。この概念によって、同じ「テスト計画」を複数回実施して回帰テストすることもできる。筆者は、Hudsonと連携して、「ビルド」にモジュールのビルド番号を振り直すように運用している。
テスト計画終了後、TestLinkにたまったテスト実績を集計・出力すると、テスト工程の進ちょくや品質に関するメトリクスが得られる。開発チームやテストチームは、このメトリクスから得られた知見を、次のイテレーション計画やテスト計画で改善すべき点として反映していく。
図3−2は、TestLinkの運用サイクルの概念イメージ。
Copyright © ITmedia, Inc. All Rights Reserved.