TestLinkを運用して気付いたことpart7～要件カバレッジは難しい

TestLinkの要件カバレッジを振り返って気付いたことをメモ。

TestLinkを約1年使ってみて、そして過去のテスト実績を分析しながら、特に結合～受入テストの難しさを改めて痛感している。

TestLinkでテストの進捗管理はやりやすくなるが、やはり一番大事なのは、テストケースそのものの品質だ。
テストケースの粒度が殆ど同じで、テスターがすぐに理解できる内容にする必要がある。

そして、テストケース作成で最重要な点は、要件カバレッジ。
テストケースが要件を全てカバーしていないならば、そこからテスト漏れ、引いてはバグになる。

実際のテストでは、この要件は単体テストで保証済み、とか、この要件は最後のシステムテストで確認するから保留、などのように、テストすべき要件を間引いて、最小のテストケース数でもってテストしていく。

TestLinkでは、要件とテストケースが相互リンクしているので、要件がどのテスト計画のどのテストケースに紐づいているか、追跡できるため、要件カバレッジを確認する作業が格段に楽になる。

でも、要件カバレッジは非常に難しいのが実情だ。
TestLinkで要件カバレッジを分析してみると、一つのテスト計画で全ての要件を100％でカバーできない。
僕の経験では、テスト方法によるが、一つのテスト計画で約60％ぐらいしかカバーできない。
複数のテスト計画(単体・結合・総合・受入テストなど)を実行して、初めて100％になる。

理由は、TestLinkのテスト計画をXPのイテレーションと同一視して運用するため、２～４週間と言う短い期間だから、せいぜい数百個ぐらいのテストケースしかこなせない。
全ての要件をカバーできるテストケース数をこなすには、複数のテスト計画が必要だからだ。

逆に言うと、テストしやすいようにテスト計画(イテレーション)の単位で管理しているため、テストそのものの進捗管理はやりやすくなっている。

従って、要件カバレッジを100％にするためのテスト戦略が必要になってくる。

最も現実的な戦略は、要件をテスト工程別に分割して、それぞれのテスト工程で検証していくことだろう。
つまり、境界値分析しやすい要件は単体テストでみっちりやる、とか、画面の複雑な状態遷移の要件は結合テストで色んなパターンでテストする、などのように、テストの観点を分けてみる。

要件をテスト工程別に分割する利点は、要件を仕様へ詳細化していく流れと一致しやすいことだろうと思う。
要件定義や外部設計の段階では、そもそも要件はぶれやすく、変更や追加が多いだろう。
詳細化していくに従って、要件も具体化されて、仕様としてある程度固定化できる。

この時に、テストケースの分類項目と要件の分類項目の粒度を合わせられるとよい。
TestLinkでは、テストケースをテストスイートで階層化できるため、分類しやすい。
最新のVer1.8以降では、TestLinkの要件も階層化できるようになったから、要件の階層とテストスイートを紐づけできればなお良いだろう。

要件カバレッジをコードカバレッジのように扱うことで、テストケースの品質や観点を向上できるだろうと思っている。