TestLinkを運用して気付いたこと
TestLinkをテスト仕様書代わりに運用し始めて、メーリングリストで使い方を聞いたり、自分で色々試してみた。
色んな気付きがあったのでメモ。
【1】数千、数万のテストケースをTestLinkへインポートするには、下記のExcelマクロでXML出力して、TestLinkのXMLインポート機能を使う。
このツールのおかげで、既存のテスト仕様書からTestLinkへテストケースをコンバートするのが非常に簡単になった。
TestLinkへテストケースを全てインポートして一番驚いたのは、わずか数人のプロジェクトですら、テストケースが1千ケースを越えていることだ。
但し、ここでのテストケースは単体テスト、結合テストのどちらも含んでいる。
今の感触では、20人月規模のプロジェクトならば、TestLinkへインポートするテストケース数は1万ケースを越えるだろう。
つまり、普通のプロジェクトでは、数千、数万レベルのテストケースでもってテストしなければ、品質を保証できないのだ。
100人月規模のプロジェクトならば、数万~数百万という膨大なテストケースを実行しなければならないだろう。
そうなると、そもそも人間の手で検証可能なテストの限界に来ているのではなかろうか?
そんなことを考えると、我々開発者は、これだけの規模のテストケースをきちんと管理できているのだろうか?
そもそも、テスト工程になると、納期間際でテストする時間も潤沢に無いし、たくさんの人手がかかるので修正・検証・管理工数が非常に大きくなる。
だから、単体テスト、結合テスト工程は非常に難しいのだ。
テストプロセスで重要な点は、システムの操作で考えられる業務フローをテストで全て網羅することだ。
一つでもテストしていないケースがあれば、そこからバグに発展する可能性は非常に大きい。
WindowsやIEのセキュリティパッチが月1回公開されていることからしても、たった一つの未実行テストが大きなバグになりうる例が数多くある。
だからこそ、テスト計画時にテスト戦略を考えるのが重要だ。
つまり、どのテストケースを最優先にするのか、限られた時間と人員でテストの範囲をどこまでに絞ってテストするか、限られたテストでどこの機能の品質を最優先で確保するのか、というテスト戦略が重要になる。
膨大なテストケースを全てテストするのは、地球が滅びる時間を越える時だってあるのだから。
今までの自分の現場がいかにテスト管理していなかったか、を痛感させられた。
【2】TestLinkはテスト計画がテストマネジメントの中心になる。
Redmineロードマップとは機能が違う。
TestLinkは下記のようなフローになる。
テストプロジェクト作成
↓
テストスイート作成
↓
テストケース作成
(実際は、ExcelマクロでXMLインポート)
↓
テストケースをテスト計画へ追加
↓
ユーザをテストケースへアサイン
↓
テスト計画へビルドへアサイン
↓
テストケース実行
↓
リリース後、テスト計画を修正できないように、無効にする
↓
テストケースをXML出力し、Excelへコンバートして納品用テスト仕様書を作る
どうやら、大量のテストケースをストックしたテスト仕様と、実際にテストケースや担当者をアサインして実行するテスト計画を切り替えて運用するやり方みたいだ。
正直まどろっこしい所がある。
でも、アジャイル開発よりもテスト技法の方が古くから研究されているので、上記のフローには何かしらの意味があるのだろうと思う。
【3】テストNGの場合、TestLinkのテスト実行画面からRedmineのバグチケットへ連携する機能がある。更に、テスト結果画面にある「失敗したテストケース」リンクから、失敗したテストケースとバグ登録したBTSリンクの一覧が表示される。
この機能のおかげで、検証作業が非常にやりやすくなった。
また、TestLinkもRedmineと同様に、テスト結果をリアルタイムに出力できる。
失敗(つまりテストNG)が多ければ、バグが多いという事実もすぐに分かるし、ケースの消化率もすぐに分かるので進捗管理になる。
TestLinkのツールとして提供されているExcelマクロへ、毎日のテスト結果のCSVをインポートすると、テスト消化数の簡単なグラフを作ることもできる。
これは、バーンダウンチャートに相当するだろう。
ソフトウェア工学が教える所によれば、たくさんのバグが出て修正したシステムは、リリース後もバグが多く出て品質が悪いという。
そんな知識も考慮しながら、TestLinkのテスト結果を眺めれば、プロジェクトのある種の傾向を読み取ることもできる。
いわゆるデータマイニングは非常に面白い。
TestLinkはテストケース管理ツールに過ぎないけれども、Redmineと連携するとテスト工程で大きな威力を発揮する可能性を非常に感じている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
「Redmine」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmineはチェンジマネジメントのツールであるべきだ(2026.07.13)
「ソフトウェア工学」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される(2026.08.30)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- 「System of Systems(SoS)の統合テストは不可能だ」という言説を聞いた(2026.08.16)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)


コメント