« チケット駆動開発のベストプラクティスを収集したい | トップページ | SVNリポジトリの管理方法の追記 »

2009/09/08

TestLinkの運用例part2

allpair法をTestLinkに使う方法が書かれた記事があったのでメモ。

【元ネタ】
TestLinkメモ - 科学と非科学の迷宮

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな?Rubyグループ

allpair法は、組み合わせテストのテストケース作成技法の一つで、同じ値のペアが最低1回現れるように組み合わせてテストケースを作成する方法。
直交表に比べると、テストケース数を少なくできる。

実際のテストケース作成時は、複数の入力項目の組合せテストが非常に多い。
例えば、組込製品やパッケージ製品ならば、ドライバやOSのバージョンを組み合わせたテストケースを作っているだろう。
業務システムならば、業務のパターンや状態を組み合わせてテストケースを作りこんでいるだろう。

実際の現場では、直交表からテストケースを作ると、ケース数が爆発してしまい、限られた工数ではテストできない時が多い。
その時に、直交表よりもallpair法を使えば、少ないテストケースでたくさんのバグを見つけることができるはず。

TestLinkのテストケースへ出力する方法は、garyoさんが作ったRubyスクリプトを使うのが一番よいだろう。
僕は実際に使ったことがない(使いこなせなかった)が、上記の方は実際に試されているので非常に参考になる。

TestLinkでテスト工程をマネジメントする場合、インプットのデータであるテストケースの品質が一番重要だ。
テストケースの品質が悪く、テストケースの粒度にばらつきがあったり、テストケースそのものに間違いや仕様漏れがあると、TestLinkを使う利点が半減する。
実際、TestLinkの要件カバレッジを使ってみると、テストケースに紐づかない要件がよくあるので、要件漏れが頻繁に発生している時が多い。
すると、テストしていない要件、機能があるため、そこから潜在バグになる危険がある。

結合テスト以降のテスト仕様書は、Excel上で仕様書を見ながらテストケースを増幅して作る時が多く、非常に工数がかかる。

TestLinkを運用するようになって、テストケースはTestLinkのマスタデータなのだ、と思うようになった。
マスタデータが狂っていると、TestLinkでいくらテスト管理を頑張っても効果は半減する。
テスト仕様書は設計書を書いているのと同じレベルなのだ。
だから、テスト仕様書をきちんとレビューしてもらい、間違いや漏れをなくすのが大事だ。

TestLinkが運用しづらい原因の一つは、テストケースと言うマスタデータを作りこむのが大変だという点もあると思う。
テストケース作成技術は、プログラミング技術とは異なる別個の重要な技術なのだ。

|

« チケット駆動開発のベストプラクティスを収集したい | トップページ | SVNリポジトリの管理方法の追記 »

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

ソフトウェア工学」カテゴリの記事

TestLink」カテゴリの記事

コメント

> TestLinkの要件カバレッジを使ってみると、テストケースに紐づかないテストケースがよくあるので
は、
テストケースに紐づかない要件
ではないでしょうか?
(コメント公開しなくてもOKです

投稿: kawanabe | 2009/09/17 08:15

kawanabeさん、ご指摘ありがとうございました!

投稿: あきぴー | 2009/09/17 21:19

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« チケット駆動開発のベストプラクティスを収集したい | トップページ | SVNリポジトリの管理方法の追記 »