TestLinkにあるといい機能
All In One TestLink JPを少し試してみたり、プログラマの思索のTestLinkに関連するエントリを読んでみて、あるといい機能について考えてみる。
テスト実施予定件数、実績数、バグ数、ブロックされたテストケースの件数などをグラフ化したバグ曲線はやはり欲しい。バグ曲線が意味をもってくるのはある程度大きなプロジェクトに限られてくると思うが、顧客や社内のPMO的な部署に提出しなければならないことも多い。たいていリーダがファイルサーバ上のExcelをかき集めて作っていると思うが工数がかかるし、トラブっている状況だと個々の数字自体怪しい。それにブロックという概念はたいていのプロジェクトには無いだろう。
ブロックの意味は下記参照。この概念はおそらくTestLinkで初めて登場したものだろう。
テストケースがいつも「成功」ならば良いが、やはり「失敗」する時もある。
この時、「失敗」したテストケースに依存するテストケースにも「ブロック」を付けて、テスト保留とする。つまり、「ブロック」とは、バグが直らないと先に他のテストケースをテストしたとしても、再検証が必要になるテストケースの状態を指す。
TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索
この概念はTracのチケットと同じく革新的だと思う。ブロック無しのバグ曲線の場合、ブロックされたテストケースの件数が多く本来ならバグ修正を優先しなければいけない状況でもテスト消化が遅いという理由でテスト担当者が増員される可能性がある。そうするとますます混乱するだろう。
そうでなくとも結合テストは鬼門だ。
普通のプロジェクトでは、結合テストで火を噴くことが多い。
TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理: プログラマの思索
理由は、結合テストになって初めて、顧客だけでなく開発者も、実際にシステムが動くのを見れるからだ。
システムは、いくら設計をやったとしても、動かさないとイメージが湧きにくい。
そこで初めて、設計漏れ、要件漏れに気づくことも多い。
トラブルの気配はたいてい最初の要件定義の時点から漂い始め、コーディングや単体テストでそれがほぼ確信できるようになり、結合テストで確定する。
結合テストをどうまわすかは重要だがいまだに改善されているかんじがしない。TestLinkはそのいい突破口になりそうだ。
ただ現状だとテストケースにテスト予定日や実施日の情報が無い。
しかし、TestLinkには、テスト予定日の欄がなく、テスト予定日でテストケースをフィルタリングする機能がないため、使いづらい弱点がある。
TestLinkの弱点～マイルストーン管理: プログラマの思索
テストの事前条件も無い。
一番不満な所でもある。
TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索
理由は、ユースケース記述書みたいに書けないから。
テストの目的、テストの事前条件、テスト手順、事後条件を書きたい。
しかし、目的、事前条件の欄がない。
事前条件が欲しい理由は、システムテストのテストケースでは、テストの前準備が大変だからだ。
例えば、ネット注文のテストの場合、指定の会員が指定の商品を購入してカート画面まで遷移しておく必要がある。
その前提条件が崩れると、いくらテストしても無意味だから。
バグに関してはBTSに任せるべきだし、TestLinkにも連携機能があるが、これもやや面倒。
バグを見つけたら、まずBTSに登録しそのバグIDをTestLinkに入力する必要がある。これはちょっと面倒だしBTSからTestLinkへのリンク付けも手動になる。TestLink上のバグ登録ボタンを押したらBTSに登録できさらに双方向のリンクが自動的についてほしい。それでも要件IDに比べればまだいい。要件IDはTestLink固有のものだ。これも本当ならTracやRedmineのチケットと関連づけたい。
そのほかにもExcelからimportしたい。TestLinkCnvMacroを使ってまずxmlにしてからimportできるが直でimportしたい。
エビデンスもうまく管理したい。
こうして好き勝手書いてみても明らかなようにｗ 要件、ソース、テスト、エビデンス、バグの全てが関連付けられる総合的な開発インフラが望まれているように思う。それぞれのツールはそろってきているのでいかにうまく関連づけていくか、それが考えていくべきポイントだろう。
