TestLinkを受入テストで運用する方法

以前のhokorobiさんの記事にあったTestLinkの使い方の意味がようやく分かったのでメモ。
僕が勘違いしていた部分もあったので、再考してみる。

TestLinkを受入テストで運用 from akipii Oga

【元ネタ】
TestLink を使ってみた - hokorobiの日記

テスト手法の概念をTestLinkで説明する: プログラマの思索

第5回　脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記

TestLinkの運用方法は、開発チームがシステムテストで使う場合と発注者が納品モジュールを受入テストで使う場合で、観点が異なるようだ。

【1】開発チームがシステムテストで使う状況では、テスト計画をイテレーションと同一視して、Agileに開発するのがいいと思う。
理由は、スコープを狭めて徹底的にテストでバグを潰し、リリースできる範囲を少しずつ広げる手法の方が、システムの品質を確保しやすいからだ。
バグが残っているのに、新規機能をどんどん開発しても、開発チームはどんどん混乱するだけ。

この状況では、複数個のテスト計画をイテレーション単位を作り、テスト計画とビルド(テスト実施結果)は1対1の運用になる。
つまり、数百に絞ったテストケースをテスト計画にアサインし、ビルドは、テスト完了直後にビルドモジュールの最終バージョンでリネームする運用方法。
すると、バグ1個の発見と検証の作業履歴は、同一ビルドで運用する。

僕が運用している方法は、このやり方であり、まずは全てのテストケースを最低限1回はテストするのを最優先する。
そうでなければ、数千のテストケースを数ヶ月以内に終わらせることはできないし、バグが出るほどバグ修正と検証の連携作業が混乱してしまい、最悪の場合は、全テストケースすらテストできないだろう。

【2】しかし、発注者の観点では、SIが納品したモジュールを発注者が作った受入テストケースでテスト管理したい。
この状況では、テスト計画は受入テスト1個だけで、ビルドは納品モジュール単位に管理したいはず。
つまり、テスト計画とビルドは1対Nの関係になる。

状況としては、SIから届く納品モジュールでテストできるバグの履歴をビルドで別管理しておきたい。
理由は、どの納品モジュールで確実にバグが修正されたか、区別したいからだ。
すると、バグ1個の発見と検証の作業履歴は、異なるビルドで管理して運用するため、ビルドは納品モジュールのビルド番号でリネームしてテストを開始するだろう。

第5回　脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記で紹介されたhokorobiさんのテスト手法はこのやり方に相当する。

TestLinkのVer1.8のテスト実行画面では「以前のすべてのビルドにおける結果」というフィルターがあるので、過去のビルドで失敗したテストケースをフィルタリングして、そのテストケースだけテストに専念すればいい。
つまり、最新版の納品モジュールでは、過去直近の納品モジュールでバグが出たテストケースを最優先にテストすればいい。

しかし、hokorobiさんの指摘通り、上記のやり方では、我々が想定しているテストケースが「以前のすべてのビルドにおける結果」でフィルタリングできないバグ（？）っぽい現象がある。

本来ならば、TestLinkには、過去直近のビルドの情報を最新版のビルドへ複製する機能があるべきだ。
その機能があれば、最新版のビルドで、テスターは「成功」以外のテストケースを順次テストしていけばよい。

TestLinkはまだまだ使いづらいけれど、テスト管理を改善してくれるポテンシャルがある。