社内でTestLinkを検証しました。正確には自分では検証していません。社内のテストリーダーに検証してもらいました。

• http://testlink.org/

以前、社内の開発者からテスト管理ツールの導入の提案を受けたことがあったのですが、あまり気が進まずなんとなく放置していました。気が進まなかった理由は導入の利点が見えなかったからです。たとえばテスト管理ツールを紹介する次の記事があります。

• http://itpro.nikkeibp.co.jp/article/COLUMN/20071106/286467/

この記事は、テスト管理ツールの利点に次の3つを挙げています。

• 「リポジトリ」によるテスト情報の一元管理
• 自動テストの実行管理
• 集計/分析機能

1番目の件は、テストケースをテキストファイルで書いてソースコードと一緒にCVSやsubversionで履歴管理すれば解消します。アリエル社内ではテストケースの管理は伝統的にこうしています。

自動テストの実行管理はよくわかりません。現状、社内では、自動テストは自動テスト、テストケース文書による手作業のテストは手作業のテスト、と分けています。自動テストは自動テストのスクリプト自体がテストケースなので、別途、文書化する意味を感じません。

集計/分析機能については、テストケース文書をシンプルなテキストファイルにしてフォーマットを決めておけば、grep、uniq、sort、wc、awkを駆使して一瞬で必要な情報を取得できます。少なくとも、テストの総件数、成功/失敗の割合などは簡単に出せます。

などと考えてテスト管理ツールに手を出しませんでしたが、突然、試してみる気になりました。理由はふたつあります。

ひとつは、自分のテスト管理ツールに対する態度が「自分の知らないものはダメだ論理」だと感じたからです。この態度は危険です。流行っているものやみんなが良いと言っているものを無批判に称賛するのもダメな態度ですが、自分が知らないものや使ったことのないものを批判するのもダメな態度です。

もうひとつは、テキストファイルから情報をひっぱるのに「そんなのgrepで一瞬じゃないですか」という言葉が万人に通じないことに気づいたためです。悲しい事実ですが仕方ありません。

そんなわけでTestLinkを検証しました。

結論を言うと、想像より使えそうです。スモールスタート的に社内で使い始めようと思っています。

テストケースの管理と、テスト計画(=テスト実施の記録)の管理のふたつの軸があるのがポイントです。RDBアプリ風に言えば、前者がマスター(リソース)、後者がトランザクション(イベント)的な構造です。テストケースは手順と期待値の記述で、何度も実施されればその度ごとに結果レコードができます。テストケースの1レコードに対して、実施結果のレコードは1対多の関係で存在します。

テストケースと実施結果が1対多の関係になるのは、言われてみれば自然で当り前の構造なのですが、バグトラッキングシステム(BTS)とは違うんだという現実に改めて気づきました。昔、wishlistもBTSで管理している話を書きました(http://dev.ariel-networks.com/Members/inoue/wishlist-management)。実を言うと、テスト管理もBTSでできるのでないかと漠然と考えていたことがあります。テストの実施をテストエンジニアにアサインして、実施後に結果がでるという一連の流れがBTSの一連のフローと似たようなものだと思っていたからです。実に浅はかでした。テスト管理ツールにはテスト管理ツールの存在意義がありました。先人の知恵を無視してはいけません。

ソフトウェア・テストPress(http://gihyo.jp/magazine/testpress)の次号(Vol.9)に記事を書くので、TestLinkを現場で使った報告も書けると思います。