ソフトウェアテストの粒度は？

ソフトウェアテストをするときに、その粒度はどうしているのでしょうか。揃えているのでしょうか。もし揃えていないとしたら、テストケース密度やそれによって発見できるバグ密度は信用できるのでしょうか。もし揃えているとしたら、どの程度に揃えているのでしょうか。ということで、今回はソフトウェアテストの粒度は揃える必要があり、その粒度はテストの対象によって異なり、対象が小さくなとほど、テストケースの粒度もそれにつれて細かくなります。図引用元：IPA ソフトウェア開発分析データ集 FAQ

ソフトウェアテストの対象は色々

ソフトウェアテストの対象は色々あります。ソフトウェア開発の各工程、各場面での各対象になり、例えば、要求分析から設計、プログラムコード、テストケースを対象にしたレビューによる静的テストと、そしてプログラムの最小単位であるモジュール、複数のモジュール、システム全体を実際に動作させてテストする動的テストがあります。

このようにソフトウェアテストと一言でいっても、その対象には上記のように、色々とあります。つまり対象が色々とあるソフトウェアテストでは色々と考えなくてはいけません。ああ、色々と面倒です。

ソフトウェアテストの粒度は揃えて

ソフトウェアテストの粒度がばらばらであれば、管理も統計も、あったものではありません。粒度は揃える必要はあります。

プログラムの最小単位であるモジュール、例えば、Cであれば関数、Javaでいえばメソッド関数に対して実施する単体テストは、粒度は放置しても自動的に揃います。なんて言ったって、テストツールでもテストケースを自動生成できます。もちろんプログラマならお手の物です。

問題は単体テスト以外のテストです。動的テストだけでなく静的テストのレビューにおいても、粒度を揃える必要があり、その粒度をどうするかが問題です。

テストの対象が大きくなれば、テストの粒度も大きくなります。システムテストのときは、エンタープライズソフトウェアの場合は業務機能レベルの粒度のテストになるでしょう。これが正義なのに、システムテストの粒度を単体テストのように細かくしてはいけません。

システムテストでは細かいことに拘ってはいけません。細かいことは単体テストのときに拘ってください。

ソフトウェアテストの粒度はこうして

それでは具体的にテストの粒度はどのくらいにするのがいいのでしょうか。その答えは逆説的になりますが、目標とするテストケース密度から導かれるテストケース数になるように、粒度を調整します。

これはジョークではありません。（本気と書いて）マジです。求めるテストケース数が100個であれば、対象を100分割してテストケースを作ります。

テストケースは正常系（有効テスト）よりも、異常系（無効テスト）の方が重要ですから、分割のバランスは異常系を多くするようにします。簡単に言えば、いじわるテストです。

このソフトウェアテストの粒度については、ITシステム可視化協議会(MCIS)の「テストケース粒度の定義」を参考にしてください。
参考：MCIS公開資料 | MCIS (mcis-jp.org)

ということで今日の結論。「テストの粒度は逆説的に揃える」　以上です。

マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構