スキルアップ
テストケースの再利用を実践するための3つの勘所

本記事では、継続的なテスト活動の効率化のために、テストケースをうまく再利用していくためのアプローチを紹介します。普段「Microsoft Excel」や「Google Spreadsheet」に代表される表計算ソフトでテストケースを管理していて、「テストケースの増減や変更への対応や、バージョンアップによるテストケース数増加への対応などで、取り回しがうまくできないと感じる方は、ぜひ本アプローチを参考にしていただければ幸いです。
なぜ再利用が必要か
近年のデジタルプロダクトの開発は、1回作ってローンチしたら一区切りではなく、継続的に仕様追加や変更がされていくことが当たり前となっています。このトレンドは、いわゆる「アジャイル開発」型のプロセスが主流のB2C Web製品に限った話ではなく、大型家電や自動車のような大規模組み込みプロダクトであっても、年に一度のモデルチェンジや、継続的なファームウェアのアップデート提供などがなされています。従って、テスト活動もリリースの度に発生することとなり、昔に比べその発生頻度は増えており、またその一方で、1回のテスト活動の期間はより短くなる傾向にあります。このチャレンジングな状況へ対応するには、進化し続ける開発技術と同様、テスト活動も進化し、効率化していかなければなりません。
テスト活動における重要な「成果物(テストウェア)」の一つとしてテストケースが挙げられます。テスト対象の「仕様(テストベース)」が継続的に変化していく状況下において、テストケースも当然そのまま変更なく使い回せることはなく、その時々の品質状況や仕様の変更内容に応じて更新し続けていくことになります。このとき、都度テストケースを作り直していては、到底前述のスピード感には間に合わないため、既存のテストケースを最大限生かしつつ、必要最低限の更新をしていく工夫が必要となります。
本記事ではこれから、この工夫を効果的に実践するための3つの勘所を紹介します。
3つの再利用のシナリオ
さて、ひと口に「テストケースの再利用」といっても、そこにはさまざまな状況に応じた課題があります。本記事では、継続的なデジタル製品開発プロジェクトの中でよく発生するであろう、以下の3つの粒度別のシナリオに整理し、それぞれ個別に解説します。
1. フェーズ内再利用
あるテストフェーズ内で、テストケースが全てパスするまで、もしくは定められた基準に達するまでテストを繰り返す際のテストケースの再利用
2. バージョン間再利用
プロダクトの仕様追加や変更に追随する際のテストケースの再利用
3. プロダクト間再利用
同じ企業・組織で複数のプロダクト開発をする際の横断的なテストケースの再利用
フェーズ内再利用の勘所
1つ目として、最も小さな粒度でテストケースを取り回す状況です。これは、テスト対象プロダクトが継続的に進化しない状況でも必ず発生する、最も基本的なシナリオです。
この状況でのバッドノウハウは、テストケースと、それに対するテスト実行結果を一対一の形で管理し、テスト実行を繰り返す度にテストケースも含めた形でファイルやデータのコピーを単に行うだけの再利用にとどまるパターンです。テスト対象のテストケースは同じはずなのに、テスト実行した分だけデータの重複が発生し、また、あるテストケースに対する結果の変遷を知りたいときに、重複するテストケースに対して異なるテストデータが存在しているが故に集計の手間が発生します。
逆に考えると、このシナリオでの再利用をうまく実践するには、下図のとおり、テストケースとテスト結果は一対一ではなく、一対多であるように扱うことで簡単に達成できます(図表1)。

テスト実行が何回発生しようとテストケースのデータは一意であり、だからこそテストケースを軸にその実行履歴を簡単に知ることができます。
バージョン間再利用の勘所
2つ目は、本記事の冒頭で触れた継続的なプロダクト進化に適応するという、最も重要なシナリオです。
ここで大切なのは、プロダクト仕様とテストケース間のトレーサビリティを確保することです。特に筆者は、以下の3つのトレーサビリティが重要であると考えます。
- プロダクトの機能・非機能仕様ごとに対応したテストスイート分割
- 機能横断要素を取りこぼさないためのテストスイートへのタグの付与
- プロダクトのリリースバージョンに対応したテストスイートの変更・バージョン管理
※テストスイート:特定のテストランで実行されるテストスクリプト、またはテスト手順のセット
現在のデジタルプロダクトの仕様は複雑なため、管理するテストケースの数も非常に多いでしょう。全テストケースを階層化なくフラットに扱うのは現実的ではなく、何かの単位で分割して管理することが必須となります。なお、ここでは、何かしらの基準でまとまったテストケースの固まりを「テストスイート」と呼称することとします。テストスイート分割の最もオーソドックスなアプローチが1点目に挙げたとおり、まずはプロダクトの「機能」の単位で分割し、また非機能テスト、例えばセキュリティテストやパフォーマンステストはそれぞれでテストスイートにまとめると全体の見通しが良くなります。
とはいえ、これだけでは不十分であり、各機能を横断するような仕様要素もあるため、これらを扱うためには、タグ付けをすることで、横断要素が影響するテストスイート群の特定をしやすくできます(図表2)。

前述のテストスイート分割、そしてタグ付けでテストケースの構造化の下地ができました。最後にプロダクトのリリースバージョンに対して、テストスイートも同じルールでバージョン付けをします。また、バージョン間の変更の内容も管理することで、無駄のない効果的なテストケースの取り回しが実現できます。
プロダクト間再利用の勘所
最後の3つ目は、最も粒度の大きい、マルチプロダクト組織における再利用のシナリオです。
今では異なるドメインのプロダクト群を一つの企業・組織で開発をしていくことも多く、この場合、細かい粒度のテストケースをそのままでは再利用できません。一方で、抽象度を上げた「テスト観点」「テスト条件」などといったノウハウをプロダクトごとに個別に扱うのは非効率的なため、これらを再利用する仕組みが求められます。
ここでポイントとなるのは、細かい粒度のテストケースの属性は、例えば「事前条件」「入力操作」「期待結果」のように固定化して扱いやすい情報に対し、前述の「テスト観点」「テスト条件」などの抽象度の高い情報の構造は固定化しにくいことが挙げられます。いわゆる表形式とは異なる、より柔軟なツリー・グラフ構造で別管理した方がより効果的です。
抽象度の高い「テスト観点」「テスト条件」はツリー・グラフ形式でプロダクト横断管理をし、そこからさらに詳細化する形で、細かい粒度のテストケースはプロダクトごとに個別に管理する、というのがバランスの良いテスト資産の取りまわし方であると筆者は考えます(図表3)。

まとめ
本記事では、3つの抽象度・シナリオにおける効果的なテストケースの再利用の実践の勘所について解説しました。
実はこれらの内容を実践しようとする際、そのための仕組みをいちから自身で構築する必要はありません。なぜなら、ソフトウェア開発支援ツール群の一つのジャンルとして「テスト管理ツール」と呼ばれるツール群がすでに市場には多数あるからです。これらのツールは、どれも前述のテストケースの構造化や変更管理、バージョン管理の仕組みを備えています。従って、実践の際は皆様のプロジェクトに合ったテスト管理ツールを選び、足りないところは運用ルールでカバーする、ということが現実的な手段となります。
ベリサーブでは、テスト管理ツールとして「QualityForward」を提供しています。1つ目・2つ目の勘所を支える「テストスイート」「テストスイートバージョン」「タグ」機能、そして、3つ目の勘所を支える「要求ツリー」機能など、継続的に繰り返されるテスト活動をスマートに支えるツールして自信を持って開発・提供しています。
テスト管理ツールがどのようなものなのかは、実際に触ってみることをお勧めします。本ツールでは無償版を用意していますので、ぜひお気軽に試してみてください。
この記事は面白かったですか?
今後の改善の参考にさせていただきます!