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と連携するとテスト工程で大きな威力を発揮する可能性を非常に感じている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
コメント