TestLinkのFAQ

TestLinkを運用する時のFAQをまとめたみた。
TestLinkは癖があるために運用しにくいと思うので是非参考にして欲しい。

【元ネタ】
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索

簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社

TestLinkCnvMacro

【テスト計画】
【1】TestLinkをインストールしましたが使いこなせません。TestLinkはSW開発のどの工程で運用すれば効果的ですか？
【回答】
TestLinkを運用する場合、結合～受入テストで導入するのが良いでしょう。
TestLinkは手動のテストを管理するためのツールなので、自動化しやすい単体テストよりも、業務シナリオをベースにした結合～受入テストのテストケースやテスト実績を一括管理するのが効果的です。

【2】テスト計画はどんな単位で扱えばいいですか？　テスト計画にリリースバージョンを当てはめていいですか？
【回答】
TestLinkのテスト計画は、例えば「結合テストのPh1」のように、一つのテストサイクルのように扱えばよいでしょう。
つまり、テスト計画はせいぜい数百ぐらいのテストケースにグループ化して、テスト計画を順次テストしいてく戦略を採るのが無難です。

そして、テスト計画を複数回実施した場合、TestLinkのビルドで回帰テストの結果を残す運用にすればいいでしょう。
例えば、全てのテストが終了後、ビルドにビルド番号を振り直す運用にすれば、もっと分かりやすくなるでしょう。

【3】TestLinkをアジャイル開発と連携する時の注意点はありますか？
【回答】
TestLinkのテスト計画をXPのイテレーション又はScrumのスプリントのように扱えばいいでしょう。
例えば、設計から開発・単体テストまでは、1個のイテレーションでアジャイルに開発後、結合～受入テストは別のイテレーションと見なし、TestLinkの「テスト計画」として実施する運用がよいでしょう。

【テストケース】
【4】TestLink上でテストケースを登録するのが面倒です。数百～数千のテストケースを一括インポートする方法はありますか？
【回答】
最もお勧めな方法は、Excelで作りこんだテストケースをTestLinkCnvMacroへコピーして、XML出力後、TestLinkへインポートすることです。
他に、マインドマップで作ったテストケースをMmToTestLinkでインポートしたり、C/Java/Ruby/C#のテストユニットのタグからインポートしたりする方法もあります。

参考：
TestLinkCnvMacro

JavaToXml - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

CToXml - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

RubyToXML - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

【5】TestLinkのテストケースと既存のテスト仕様書の形式が合いません。どのように落とし込めばいいでしょうか？
【回答】
基本は、テストスイートでテストケースを階層化して、上手に分割することです。
結合テスト以降では、一つの業務シナリオに対し、複数のテストケースがあり、それぞれにテストの目的があります。
例えば、下記のような形式にすればいいでしょう。

(TestProject)小売システム
(TestPlan)結合テスト
(build)9月リリース
(TestSuite1)xx画面
(TestSuite2)姓名の入力チェック機能が正常であることを確認する
(TestCase-ID)テスト仕様書のケースID
(TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。
(TestCase-ステップ)zzボタン押下
(TestCase-期待値)xx画面でE1メッセージを表示する

【再テストするワークフロー】
【6】テストに失敗した場合のワークフローはどんな流れになりますか？
【回答】
基本は、テストに失敗した症状をBTSチケットに記載し、テストチームと開発チームの間で、BTSチケットをやり取りする運用になります。
テストチームが無い場合は、開発チームのテスターと開発者が連携することになります。

注意すべきポイントは2つあります。
一つ目は、失敗したテストケースとBTSチケットを必ず紐付ける運用にすること。
TestLinkは各種BTSと連携する機能があるため、活用すればいいでしょう。
失敗したテストケースが増えて面倒だったとしても、BTSチケットと連携しなければ、いつ再テストすればいいか分からなくなります。

二つ目は、BTSのワークフロー機能を使って、バグ修正とバグ検証のワークフローを管理すること。
Redmineの場合、ワークフローを柔軟に作れるので、テスターと開発者のそれぞれが作業中のステータスをチケットに追加できるように運用すればいいでしょう。

TestLinkでは、BTSチケットのステータスを一覧表示する機能があるので、再テストするタイミングが分かりやすい利点があります。

【ブロック】
【7】ブロックの使い方が分かりません。どのように使えばいいですか？
【回答】
ブロックとは、事前条件を満足できないためテスト不能な状態を表します。
(参考：ソフトウェアテスト標準用語集 日本語版Ver 1.3)

つまり、「失敗」したテストケースに依存するテストケースに「ブロック」を付けて、テスト保留とします。
例えば、小売系Webシステムでカート画面のDB更新のテストケースが失敗したら、注文フローのテストケースは全て「ブロック」になります。
つまり、ブロックとなるテストケースは、例えば、最下層のテストスイートに含まれる未実行のテストケースや、バグが出た要件に紐づくテストケースなどがあるでしょう。

上記のように、「失敗」したテストケースは「ブロッキングバグ」、ブロックするテストケースは「みなしバグ」と言われるそうです。
つまり、「みなしバグ」はテストしていないから失敗してないし、バグも出ていないが、テストしたらバグが出る可能性が高いことに注意して下さい。
「みなしバグ」のテストケースは一生懸命テストしたとしても、ブロッキングバグが解消されたら再検証する必要があるので、工数の無駄です。

TestLinkでは、ブロックを上手に使うことが大事です。
バグの状況に応じて、テストを中断したり、別のテストを行ったりする意思決定がテスト戦略になります。

【要件カバレッジ】
【8】要件カバレッジの使い方が分かりません。どのように使えばいいですか？
【回答】
TestLinkでは、要件とテストケースを紐づける機能があります。
この機能を使えば、要件カバレッジを行うことができます。
例えば、テストしていない要件がないか、チェックすることにも使えるでしょう。

TestLinkCnvMacroには、要件とテストケースを紐付けてインポートできる機能があるので、それを使えばいいでしょう。
例えば、下記の運用になります。

例：テストケース
(TestProject)小売システム
(TestPlan)結合テスト
(build)9月リリース
(TestSuite1)xx画面
(TestSuite2)姓名の入力チェック機能が正常であることを確認する
(TestCase-ID)テスト仕様書のケースID
(TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。
(TestCase-ステップ)zzボタン押下
(TestCase-期待値)xx画面でE1メッセージを表示する
(keyword1)1-1.1　←要件管理IDを振る

例：要件リスト
要件仕様-タイトル：小売システム
要件仕様-スコープ：小売システムの要件
要件リスト-要件名：1-1.1　(注：要件管理ID)
要件リスト-DOC-ID：1-1.1
要件リスト-タイトル：1-1.1
要件リスト-スコープ：xx画面/姓名は必須で、全角文字40文字まで入力可能

TestLinkでは、テスト実績の要件カバレッジも一覧表示できるので、リアルタイムに要件のテスト網羅率を確認することができます。

【メトリクス分析】
【9】テスト終了後、TestLinkに溜まったテスト実績を分析する方法はありますか？
【回答】
TestLinkCnvMacroを使えば、下記の観点でメトリクスを出力できます。
テストプロセスの進捗や品質について考察する資料になるでしょう。

・テスト結果の推移データ
・要件カバレッジの推移データ
・時間帯別の試験結果データ
・試験結果のピーク時間帯推移データ
・曜日別の試験結果データ
・時間当り実施数推移データ
・試験者別時間当り実施数データ