ソフトウェアテスト設計の品質を検算する方法（その①）

問題の在り処

少し考えればすぐに気付くことですが、プログラマが間違えそうなところと、テスト設計者が見落としそうなところは重なっている可能性が高いでしょう。
複雑で厄介な問題となる部分は両者にとって変わりなく共通となるはずですから、これは当たり前ということになってしまいます。これは実に困ったことです。

ソフトウェアテスト設計の品質を合理的な範囲で検算可能な場合があるので、本稿ではその方法の一つを示します。

松尾谷[1]が示した［簿記の歴史に学ぶ］検算による品質向上

松尾谷[1]は上図のように「内部で借方と貸方の累積値から検算することで複式簿記の品質は単式簿記と比較し飛躍的に改善された」ことを引きつつ、下図のようなソフトウェアの検算についての考察を示しています。

「複式簿記の検算は、借方と貸方が対称であることから、双方向に検算できるのに対して、ソフトウェアの場合は非対称で、検算PtoTを行うことが難しい」としています。

何が検算に相当するか？

ところで、例えば動的テストでは、テストケースTが指定する条件で実装Pを動作させ、得られる結果とテストケースTが示す期待値とが一致するか否かを比較します。「これって双方で検算したことにならないの？」と私は思ってしまいます。

しかし一方、松尾谷[1]が主張したいことは「上記のような動的テストの結果比較は、簿記システムで言えば財務諸表と実際の資産等との比較のようなものだから、その手前での品質向上を論点にしているのだ！」ということであろうとも思います。

いずれにしろ簿記システムとのアナロジーは、検算が有効に働くことを分かり易く示す例え話として捉え、本稿ではそれ以上にこのアナロジーにはもう拘らないことにします。

重要なことは、せっかく検算が上手く機能する場面を見逃さないことだと考えます。

先に示した動的テストの実行結果と期待値との比較を考えた場合、これを検算と呼ぶことについては大分心許ないと思う人も多いだろうとも思います。まあ、その通りだと思います。特に、テスト設計のヌケモレを発見することは難しいでしょうから、ザックリとしている感が否めません。

ヌケモレが発生しないようにテスト設計技法があるわけですが、テスト設計者がテスト技法を正しく理解して、正しく適用して作業できているかどうか、これをしっかり検証したことはないのではないでしょうか。レビューの現場を見ても、作成したテストケースを見るのに時間を取られ、ヌケモレて作成されていない方に注意を払う時間も人も少ないようです。

しかし一方、もしこれをしっかり検証しようという話にしてしまうと、そのテスト設計の検証が十分なのか検証が要るのではないかということになり、無限後退に陥ります。そんな事情もあり、テスト設計の質については検算と表現するほど理詰めの評価を免れているケースが多いのだと思います。

さてところで、大事なことなのでもう一度繰り返しますが、せっかく検算が上手く機能する場面はあるので、少なくともそれは見逃さないことが肝要だと考えます。経済合理性があって、なおかつテスト設計品質が評価できるわけですから。

上手くできそうな検算PtoT

さて、松尾谷の議論に戻します。「検算PtoTを行うことが難しい」と主張しているわけですが、ただしホワイトボックスについては、次のようにも述べています。

テスト検算は2つの成果物の比較を行うことであり，ホワイトボックステスト技法単独では検算にならない．
ホワイトボックステストが有効なのは，図の検算PtoTとして，ブラックボックステストで作成されたテストケースの漏れを，プログラム側から検算する場合である．

別稿の『原因結果グラフ法と MC/DC カバレッジ』で示した通り、基本的にブラックボックステストとして作成し、さらに実装に整合するように調整したはずの原因結果グラフからテストケースを生成したのであれば、それでMC/DCカバレッジ100%を達成できるはずです。コードカバレッジツールで計測してそれを確認することが可能でしょう。
つまり、有則組み合わせテスト設計Tを実装Pとの間で検算PtoTを行うことができ、そのテスト設計Tの品質について客観的な評価が行えます。
(正確には実装PとテストケースTそのものを直接比較することにはなっていませんが、検算と表現して良い定量的な比較が可能です。)

もちろん、これは説明の稿の方に示しているように、カバレッジ100%を達成できない理由はいくつかあるはずです。その理由が明確になっていれば問題はありません。

まとめ

ブラックボックステストとして作成し、さらに実装に整合するように調整したはずの原因結果グラフからテストケースを生成したのであれば、MC/DCカバレッジ100%を達成できるはずです。コードカバレッジツールで計測してそれを確認することが可能なので、検算してテスト設計の品質を検証するとよいでしょう。

勘違いしないで欲しいのですが、ヌケモレを見つけられるので、見つけた不足分のテストケースを足してください、という話ではありません。
そうではなくて、ヌケモレがあったということは、テスト設計技法の理解や適用方法、プロセスの中でどこかに問題や失敗があったということです。少なくともその問題や失敗、また影響範囲を把握し、十分見直し、対応を検討する必要があるということです。

バグを作り込み易いクリティカルなポイントで、テスト設計の品質を測定できるメリットは大きいので、ぜひ試してみることをお勧めします。

参考文献）
[1] 松尾谷徹『テスト／デバッグ技法の効果と効率』情報処理 Vol.49 No.2 Feb. 2008