2011年11月2日水曜日

TestLinkとRedmineによるテスト実行管理

 最近数ヶ月の間、新しいプロジェクトでテストケースもテスト管理システムも全くないところから作ることになり、以前のプロジェクトで使っていたExcelに代わる方法を検討した。Excelでもそれなりのことはできていたが、あまりにも自由過ぎて抜けもれがあったり、ミスしたり、といったことがあったので、他の方法をとれないか考えた。

 テスト管理システムで実現したかったことは以下のとおり。 実行管理以外にも、テスト計画やドキュメント管理も含んでいる。タスク管理システムとしては、他に以前のプロジェクトで使っていた影舞や、別プロジェクトで使われていたTracなどもあったが、既に現在のプロジェクトでRedmineを使っていたこともあり、Redmineにしぼって考えた。



 上記のように、TestLinkとRedmineはそれぞれ得意、不得意があり、どうするか迷った。TestLinkで大体のことはできるが、工数管理ができないのはかなり痛い。隠れ機能で工数集計できる、という話もあるようだが、そのために1.8.2を入れる気もしなかった。その他、テストを実行した結果テストケースの修正が必要、といった場合のフィードバックもできないことはないが、Redmineの方が(カスタムフィールドを設けてフラグを立てることで)簡単に運用できそうだった。

 結局両者を併用することにした。当然二重管理になるが、TestLinkはテストケースおよびテスト計画全般の管理、Redmineは個々のビルドに対する実行管理として使い分け、重複する部分を最小限にするよう努めた。(Redmineは実行管理用なので、自動テストはチケットに含めていない。)上記の表で色がついた部分が要求に対してTestLink、Redmineそれぞれの機能を利用したものである。

 何をテストすべきか、仕様変更に伴いどのテストケースを変更すべきかは、TestLinkのキーワードを使って影響範囲を判断することにした。

 「テスト実行時に関連するバグがわかる」ことをRedmineを使って実現しているのは、本来ならTestLinkとRedmineを連携させることでどのテストケースに対してどのようなバグがあるかわかるはずだが、設定がうまくいかなかったので、テスト用のRedmineチケットとバグを関連付けることにしたということ。バグはビルドではなくテストケースと関連付けられていたほうが自然なので、Redmineを使うにしても、TestLinkと連携させたほうがよいと考えている。

 なお、Redmineの使い方は次のようなものである。ビルドごとに前のビルドからのコピーでプロジェクトを作成する。これによってバグとの関連づけやテストケース要修正のフラグが引き継がれる。また、redmine_chartsプラグインを入れて、進捗や工数の予実が見えるようにする。

 この方法でテストを実行してみて、基本的にはうまく回っていたが、いくつか問題点も見えてきた。
  • スケジュールの変更に対応しにくい。テストの実行予定日はRedmineで管理していたが、丸一日分ずらすとか、半日分ずらすとかは手作業になる。また、準備ができていないなどの理由で特定の機能がテストできないなどといった場合も対応が困難。テストケース数が少なかったから何とかなったが、期日ではなく優先度を設定するなど、別の対応が必要になりそう。
  • 担当者による違いが考慮されない。今回はテスト担当者の対象システムに対する知識に違いはなかったためあまり考慮しなくてよかったが、2回目以降のビルドでは、前のビルドでテストを担当した人とそうでない人で違いが出てくる。人による違いが出てこないようなテストドキュメントを作る、というのが正しいとは思うが。
  • テストケースの変更が追いつかない。これは管理システムというより、テストケースの問題。
 今回のテストでは要件管理や一部の集計機能など、TestLinkに備わっていながら使っていないものもあり、あるものをすべて使う必要はないが、機会があれば使ってみたい。

0 件のコメント:

コメントを投稿