読者です 読者をやめる 読者になる 読者になる

Natural Software

KinectなどのDepthセンサーを中心に活動しています

TestLink の使い方が少しずつわかってきた

TestLink

先日 TestLink について一言二言書いたところ、あきぴーさんにいろいろアドバイス(?)をもらいました^^
TestLinkを運用して気付いたことpart4~TestLinkの概念を再考: プログラマの思索
TestLinkを運用して気付いたことpart5~TestLinkのテストケースの概念: プログラマの思索


ここで重要なポイントは以下の2点で、それぞれの使い方がよくイメージできた
・運用方法としてのテストケース、テスト計画、ビルド
・テスト実行時の未実行、成功、失敗、ブロック

運用方法としてのテストケース、テスト計画、ビルド

まずはテストケースの作成

テストプロジェクトに対してテストスイート、テストケースを階層構造で作成する。
今回は統合テストで使用したので、テストプロジェクトに UI の機能ベース(画面遷移そのまま)のテストスイート階層を作成した。


経験ゼロでもできるプログラミング現場の単体テスト

経験ゼロでもできるプログラミング現場の単体テスト

今回↑の本も買ったので次回からは単体テストもテストリンクで自動管理、C# であれば単体テストの実行結果を自動送信(?)ができる TestLink Adapter*1 があるので結果をこれで送信すればよさそう。
その場合はテストプロジェクト直下のスイートに単体テストと統合テストで一階層作ればよさそうかな。

次にテスト計画

これはあきぴーさんの言う「イテレーションごと」や、「単体テスト」、「結合テスト」といった括りで作れば良さそう。
テスト計画ごとに結果が残る(?)ので回帰テストに有効。
基本的にはこのテスト計画にビルドを増やすことでテストの結果をまとめればよさそうかな。

ビルド

これは単純なビルド番号を付与している。
リリースビルドは Hudson で行っているので、そこで自動生成されたビルド番号(たとえば「1.0.10.100*2」)を付与する。
Hudson でのビルド管理、リリースバージョンにタグ付け、Trac のバージョンの追加をすることで、TracSVN と Hudson と TestLink でバージョンの同期ができる。


欲を言えばこれらのひも付けを自動でやりたい。
TestLinkXML-RPC にビルドの作成があったので、Hudson からビルド完了 → SVN にタグ付け → TestLink にビルド登録 → 自動テスト → 結果を TestLink に登録まではできそう。
あとは Trac のバージョンの作成がリモートでできれば言うことなし。

テスト実行時の未実行、成功、失敗、ブロック

これはあきぴーさんの考え通りで運用してみる。
ブロックを活用することで、テストの効率があがるとのことなので積極的に活用してみる。

まとめ

TestLink をまともに使い始めて 1〜2 週間だけど、使い方さえわかれば意外と簡単に使いこなせた。
とりあえず最初の壁は突破できたよう。
こうやってみんなでノウハウを共有できればツールの敷居も下がってみんなが幸せになれそうだね:)


あと、あきぴーさんの記事で一番同意したのがこれ。

TestLinkでテストケースの管理や実施結果の管理を始めると、テスト工程というプロセスの品質が今までいかにおろそかだったか、よく分かる。
つまり、全テストケースを実施できずに、品質保証すらできずにリリースしていなかったのか?という疑問が湧いてくるだろうと思う。

数千〜数万のテストケースと実施結果を管理するのは並大抵の苦労ではないと思う。

TestLinkを運用して気付いたことpart4~TestLinkの概念を再考: プログラマの思索

TestLink は品質を考え始めたらまっ先に導入を検討するに値するツールだと思う。

*1:TestLink ML で知った

*2:メジャーバージョン.マイナーバージョン.Hudson のビルド番号.SVN のリビジョン番号