TestLinkの可能性

「塹壕よりScrumとXP」の「15.1. 多分受け入れテストフェーズは回避できない」を読んで、TestLinkを受入テストで使うアイデアをメモ。
以下メモ書き。

【元ネタ】
塹壕よりScrumとXP(日本語訳PDF)

第1回：テスト設計の必勝テクニック：ITpro

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

【1】TestLinkをSW開発のどの工程で使うべきか？
TestLinkは受入テスト(あるいは結合テスト以降のテスト)で使う。

XPが生み出したテスト駆動開発によって、プログラムは単体テスト品質をクリアするようになった。
継続的インテグレーションによって、コミットしたコードラインは常時リリース可能になった。
しかし、それらのプラクティスだけで、開発したらすぐに顧客へ納品可能か？

答えはNo。
受入テストをクリアしなければ、納品可能な品質にはならない。
＃XPにも受入テストのプラクティスは当然ある。

受入テストと単体テストには大きな違いがある。
単体テストはホワイトボックステスト。
受入テストは、業務インターフェイスが正常動作するか確認するテスト。

つまり、単体テストはプログラムの正常動作を保障する目的に対し、受入テストは、設計した仕様の正常動作を保障する目的。
間違った設計書、考慮漏れの設計書から作られたプログラムは、単体テストではバグを検知できず、受入テストで初めて検知できる。

受入テストのテストケースのベースは、シナリオやユースケース。
受入テストのテストケースとして、SeleniumやFITを使おうとしたが、結局使いこなせなかった。
どうしてもExcelのテスト仕様書に頼ってしまう。

理由は、技術上のハードルが高かったこともあるが、テストケースが要件をすべて網羅しているか、という観点が薄かったから。
受入テストのテストケースを自動化するよりも、要件カバレッジの観点の方がはるかに重要だ。
つまり、業務の理解、モデリング力をどれだけ持っているかがSEに試されている。
質の高いテストケースを作る方がはるかに大事。

システムを納品するまでの全テストケース数は、単体テストから受入テストまで数千～数万ケースにのぼるのが普通だろう。
これだけの膨大なテストケースをこなして、プロジェクト後半と言うリソースも限られた期間にバグ修正するのは至難の業。
プロジェクト管理は、実はテスト戦略が大半を占めるのではないか？

受入テストはどうしても手動のテストにならざるを得ない。
僕はそれでも良いと思う。
但し、TestLinkで受入テストの生産性を上げることはできるはず。

【2】TestLinkならExcelのテスト仕様書をWeb化でき、更に計画から実行、メトリクス採取まで一貫して管理できる。
TestLinkに大きなポテンシャルを感じる点は二つ。

1.W字モデルのような使い方。
要件定義や設計のような上流工程で、テスト計画も同時に作る。

例えば、要件カバレッジを使って、要件をカバーするテストケースが必ずあるか、これらのテストケースで要件を全て網羅しているか、を確認していく。
そうすれば、新たな要件が見つかったり、矛盾する仕様が見つかる時もあるだろう。

仕様漏れ、仕様の認識相違を早い工程で検知したい。
設計もテスト駆動開発のように、テストケースを考えながら検証可能な仕様へ落としていく。

上流工程の品質UpにTestLinkを使えないか？

2.テストケースとバグ修正の連携。

TestLinkでNGのテストケースが発生した場合、RedmineなどのBTSのチケットに紐付ける。
TestLinkでは、「各テストケースの全バグ」欄で、NGのテストケースとバグチケットの一覧が表示される。
しかも、バグチケットのステータスがチケットのタイトルに表示されるので、テスト担当者はチケットが解決されたかどうか、リアルタイムに確認することができる。

この機能のおかげで、テスト担当者と修正担当者がペアプロのように作業できるため、管理者は作業状態さえモニタリングすればよい。

TestLinkでは「ビルド」と呼ばれる機能があり、これは組込製品なら製造番号、あるいはビルド番号に相当する。
つまり、TestLinkのテスト計画に紐づいた全テストケースを回帰テストで使った場合、TestLinkのビルドにモジュールのビルド番号を入れておけば、どのビルドモジュールでNGのテストケースにが出たのか、という判別に使える。
TestLinkを使って、アジャイルにテストするインフラが整う。

【3】TestLinkで数千～数万の受入テストを実施した経験から気付いたことがある。
1回のビルド(TestLinkのビルド)で、NGのテストケースは全体の何%だろうか？

もし5%以上なら、そのシステムは品質が悪い。
1千件のテストケースなら50件のバグ、1万件のテストケースなら500件もバグが出たことになる。
例えば、納期まで残り1ヶ月で上記の状態になったら、手遅れだろう。

バグの原因は単体テスト漏れもあるだろうが、設計漏れや設計ミスもあるだろう。
受入テストが業務のインターフェイスのテストであるならば、単体テストで判明しなかったバグはまさに設計ミスそのものだろう。

つまり、受入テストを実施しなければ判明しなかったバグは、業務を正常稼動するためのインターフェイスが間違っていた、あるいは漏れていたわけで、実はとても重大で危険。
そんなバグは早めに検出しておきたい。

TestLinkで、受入テストで判明する全てのバグを検出できるわけではないが、バグ出しとバグ修正のワークフローを一貫して管理できるため、生産性を上げることはできる。

TestLinkの最新Ver1.8には、XML-RPC経由でTestLinkを操作するAPIが公開予定。
このツールを使えば、TestLinkで受入テストを自動化することも理論的には可能なはず。

TestLinkには大きな潜在性があると思う。