開発におけるテストについての復習その2

テックポエム

テストの目的を明確化する理由

以前のポエムでテストの目的を明確化することについてお話しましたが、今回はその理由について振り返りたいと思います。

テストケースを絞る理由

Unifinityには300以上のロジックと、16のコントロール、そして11の処理実行イベントがあります。(2019/05現在)
本当は最新のバージョンをリリースするたびにこれらの機能をすべて組み合わせたテストを行いたいですが、あまりにもテストケースが膨大になりすぎるため現実的ではありません。
どれくらいテストケースが膨大になるかというと、以下の動画を参考に総テストケースをイメージしていただけると幸いです。


参考動画:日本科学未来館 MIraikanChannelより

スマートフォンアプリとして更に詳細にテストするのであれば、今日までに販売された全機種のスマートフォンを網羅的に収集してテストすることになります。
以上のことから、全数テストは工数的にも資金的にも不可能であるということがわかります。

そのため、実際のソフトウェアテストでは、ソフトウェアの性質、目的、リスクなどにより、重点的にテストを行う箇所を絞り、優先順位をつけてテストを行うことが一般的のようです。

テストの種別ごとに異なる観点を持つ理由

前回とりあげた4種のテストですが、それぞれのテストにおいて重要視する観点は異なり、別々のテストケースが必要です。
もしもそれぞれのテストで全く同じテストケースを続けた場合、どのようなリスクが発生するのでしょうか。
前回のポエムを書く際にソフトウェアのテストについてあれこれ調べていると、"ソフトウェアテストの7原則"という原則があることを知りました。
その原則のうちの1つに「殺虫剤のパラドックス」というものがあります。
掻い摘んで言うと、ソフトウェアテストにおけるテストケースというものは、害虫駆除に使う殺虫剤と同じようなものであるということです。
害虫駆除に同じ殺虫剤を使い続けていると、そのうち虫(バグ)が耐性をもつようになり、その殺虫剤がだんだん効かなくなります。
ソフトウェアテストでもそれは同じことで、同じテストケースを何度も繰り返し使い続けていると、そのテストケースでは新しい欠陥(バグ)が見つからなくなります。
ソフトウェアテストで見つけたバグを修正するということは、そのテストに対する耐性を身につけているのと一緒で、ソフトウェアテストではいつも新しいテストケースでテストを実施する必要がある、ということです。

毎回同じテストケースを使うことで、それと同じ動作については保証することができます。
しかし、そのテストケース以外の使い方をされた場合に起こる事象については全く保証できないので、障害が発生するリスクが高くなります。

今回のポエムをまとめると、テストの段階や種類ごとに違ったテスト観点から作成されたテストケースが必要になる、ということです。