TestLinkを運用して気付いたことpart5~TestLinkのテストケースの概念
TestLinkのテストケースの概念についてのメモ書き。
【元ネタ】
TestLink 実戦投入 - かおるんダイアリー
TestLinkの「テストケース」も「テスト計画」と同様に、「ビルド」(回帰テストの実施結果)と1対多の関係になる。
「テストケース」の状態遷移図を考えると、下記のようなフローになる。
アサイン前→未実行→成功 or 失敗 or ブロック
「アサイン前」の「テストケース」は「テスト仕様」にあるが「テスト計画」にアサインされていない状態。
つまり、イテレーション計画に組み込まれていないので、TestLinkへただ貯めている状態になる。
「未実行」の「テストケース」は「テスト計画」にアサインされて、いつでもテストを開始できる状態。
テスターは担当の「テストケース」をフィルタリングして、どんどんテストをこなしていく。
テストケースがいつも「成功」ならば良いが、やはり「失敗」する時もある。
この時、「失敗」したテストケースに依存するテストケースにも「ブロック」を付けて、テスト保留とする。
つまり、「ブロック」とは、バグが直らないと先に他のテストケースをテストしたとしても、再検証が必要になるテストケースの状態を指す。
例えば、Amazonのような小売系Webシステムでカート画面のテストケースが失敗したら、注文フローのテストケースは全て「ブロック」になるだろう。
TestLinkのテスト実施時には「ブロック」を上手に使うことが重要だ。
上記のような「ブロック」するテストケースは「見なしバグ」と言われるらしい。
つまり、テストしていないから失敗してないし、バグも出ていないが、テストしたら必ずバグが出ることになる。
「見なしバグ」のテストケースは一生懸命テストしたとしても、工数の無駄だ。
実際の現場では、バグが多発すると「見なしバグ」の切り分けが難しく、プロジェクト後半と言うただでさえリソースが少ない状況で、工数を無駄に浪費してしまいがちだ。
だから、「見なしバグ」のテストケースは保留として、他のテストを先行したり、本来のバグが修正したらすぐに再テストする管理が必要になる。
TestLinkでは、テスト結果をリアルタイムにモニタリングできるため、テスト結果を見ながら管理者はバグの状況に応じて、テストを中断したり、別のテストを指示したりする。
TestLinkの機能で惜しいのは、失敗したテストケースはバグ管理IDとリンクできるが、ブロックしたテストケースの発生源である失敗したテストケースIDにリンクする機能がないことだ。
ブロックの発生源のテストケースのステータスがTestLinkのテスト結果上で分かるようになれば、管理者の指示なしでテスターが自発的にテストできる状況になる。
TestLinkによるテスト管理には、世界中のテスト技術者のノウハウがたくさん詰まっていると思う。
| 固定リンク
「TestLink」カテゴリの記事
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- TestRailの感想(2021.06.23)
コメント