« TestLinkでテストプロセスをマネージする | トップページ | ウォーターフォール型開発はバージョンの概念が無い »

2008/06/07

TestLinkがExcelのテスト仕様書よりも素晴らしい点

TestLinkはオープンソースのWebのテスト管理ツール。
TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。

TestLink_main


【0】インストールが超簡単

XAMP+TestLinkが一体化されたパッケージがある。
解凍して起動するだけ。
USBメモリに入れて持ち歩くことさえできる。

【1】テストケースを再利用しやすい

シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。
実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。
この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。

また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。
後の保守で再利用できなかったりする。

TestLinkの場合、テストケースはDBにあるから複製が簡単。
また、TestLinkの入力フォーマットが固定されているので、テストケースの書式を統一化できる。
テストケースの属人性を排除することが可能になる。

【2】テスト結果をリアルタイムに集計できる

DBにあるから色んなクエリで集計可能だ。
ユーザ単位、機能単位などで集計結果を表示できる。
しかも、Webで入力できるから、リアルタイムに集計結果を表示できる。

TestLink_graph


JaSST関西では、「バグ収束曲線や信頼度曲線を描くことはできるか?」という質問があった。
JaSST関西はソフトウェアテスト技術者のイベントなので、テスト技術者らしい質問。

バグ収束曲線を描くことができれば、後どれくらいの工数で品質が分溜まりに達するか予測できる。
TestLinkにはそんな機能はまだ無いが、DBにテスト結果があるから、プログラムを書けば実現可能だ。
うまく使えば、ソフトウェア工学の知識を使える。

【3】テストフローを一元管理できる

RedmineのようなBTSと同じく、ユーザ単位の権限管理もできる。
テスト担当者はテスト結果書き込みだけで、テストケースの修正は不可など。
つまり、テストのワークフローを設定できる。

また、Webだからどこでも誰でも入力がOK。
オフショア開発のように、テスト部隊と開発部隊が地理的に離れている場合、TestLinkでテスト結果を共有することも可能だ。
大人数のテスト担当者を管理するのも随分楽になるはず。

ここで、TestLinkにおけるテストのワークフローを確認しておく。

3-1.テストプロジェクトを作成
 プロジェクト単位になる。

3-2.ビルドを作成

 TestLinkコミッタに聞いたら、これは「製造番号」のことだそうだ。
 例えば、iPodなどの組み込み製品の製造番号。
 つまり、これは「バージョン」「マイルストーン」のことだ。
 製造番号とは、組み込み系テストを念頭に置いたものみたいだ。
 
 TestLinkのマイルストーンはビルドの日付ラベル。
 ビルドのような管理対象ではない。
 
 更に、ビルドで注意すべき点は、ビルドをCloseしたらテストケースを修正できない。
 TestLinkでは、ビルド(バージョン)単位にテストケースをアサインする。
 過去のバージョンのテストをしないように、過去のビルドはCloseして閲覧専用にする仕組みがある。
 理由は、常に最新モジュールをテストするようデグレを防ぐ仕組み。
 これによって、テスト担当者は必ず、最新ビルドのテストケースをテストするようになる。

3-3.テストスイート

 テストケースをカテゴリ化したもの。
 機能単位。

3-4.テストケース

 概要、ステップ、期待結果を書く。

TestLink_case

 一番不満な所でもある。
 理由は、ユースケース記述書みたいに書けないから。
 テストの目的、テストの事前条件、テスト手順、事後条件を書きたい。
 しかし、目的、事前条件の欄がない。
 
 事前条件が欲しい理由は、システムテストのテストケースでは、テストの前準備が大変だからだ。
 例えば、ネット注文のテストの場合、指定の会員が指定の商品を購入してカート画面まで遷移しておく必要がある。
 その前提条件が崩れると、いくらテストしても無意味だから。
 
 カスタムフィールドで代用できるが、一旦ビルドをCloseすると表示されない。
 おそらく、概要の欄に事前条件を書き、テストの目的はテストスイートで代用する方法がベターだと思っている。
 もう少し調査してみる。

3-5.テストケースへアサイン
 テストケースへテスト担当者をアサインする。

TestLink_assign


3-6.テスト結果
 「失敗」「成功」「ブロック」の3種類がある。

TestLink_build_2

 バグが出れば「失敗」になる。
 この時、他BTSのチケットとリンクする機能が付いている。
 つまり、バグ報告票はBTSで管理し、BTSチケットと1対1に紐づけることが可能。
 BTSは、Bugzila、Mantis、Trac、Redmineが対応している。
 RedmineのようなBTSはガントチャート、バーンダーンチャートなどのプロジェクト管理機能が強い。
 だから、テスト管理はTestLink、リソース管理はRedmineと区別すればよい。

 「ブロック」とは、他のテストケースが失敗しているため、テストできない状態のこと。
 例えば、ネット注文システムの場合、カート画面が動作できなければ、注文のテストはできないので、注文のテストケースは全て「ブロック」になる。
 これは、未着手の状態だが、依存するテストケースのバグが直れば、すぐにテスト可能の状態を指す。

3-7.テスト結果
 テスト結果は履歴に全て残る。
 【2】と同じ。

TestLink_report


【4】要件とテストケースを紐づけできる

TestLinkには要件管理という機能がある。
ver1.7.4では使いづらいが、発想としては、要件とテストケースを紐づけること。
これによって、要件からテストケースをトレースできる。

TestLink_spec_2


使い道としては、バグが出たテストケースから、影響を受ける要件を洗い出すことが可能。
つまり、バグ修正の影響を受ける機能、要件がはっきりするため、再テストの工数を見積もることが簡単になる。

あるいは、1次開発でたくさんバグが出て修正した機能に手を加える時、影響を受けるテストケースを洗い出し、再テストする方策も明確に出せる。

今年の夏に出るver1.8.0では、要件管理が使いやすくなっているらしい。

【5】直交表からテストケース作成
 
直交表からテストケースを作成すると、ケース数が爆発して、全てのテストケースを実施するのは現実的に無理な時が多い。
この時に、AllPair法を使う。
AllPair法は、直交表のパターンを網羅するようにテストケースを間引きする方法。
実際の現場では、AllPair法を使って、最小のテストケースでもってテストして、できるだけバグ出しさせる。

このツールは、gyaroさんが公開しているRubyスクリプトで、TestLinkに読み込むのが可能。

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb

他にも、下記ツールがあるので、試してみようと思う。

5-1.特定のJavaDocタグからTestLink用テストケースを出力する。
5-2.FreeMindで作ったテストケースをTestLink用テストケースを出力する。
5-3.インポート用Excelマクロ


TestLinkはテストケース作成に特化していて、マネジメント機能が弱い。
だが、マネジメント機能は、Redmineで代用すればよいと考える。

TestLinkを使う主な目的は、作成したテストケースをDBにどんどん放り込んで貯めていくことだ。
運用保守フェーズでは、最新の仕様が反映されていないドキュメントよりも、バグ修正でテスト済みのテストケースがある方がありがたい。

2次開発や運用保守が長く続くプロジェクトでは、テスト仕様書が他のドキュメントよりも一番価値があるからだ。

TestLinkがどこまで使えるか試してみよう。

|

« TestLinkでテストプロセスをマネージする | トップページ | ウォーターフォール型開発はバージョンの概念が無い »

Redmine」カテゴリの記事

TestLink」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事