予防テストというアプローチを知った

こんにちは、んだです。

今回のテーマは、『テスト計画』についてです。

体系的ソフトウェアテスト入門

読んだきっかけ

これまでのプロジェクトで、テストはいつもプロジェクトの後半に行われていました。 新機能を追加するときでも、実装が全て完了した後に初めてテストケースを作り、テストを始めていました。

そのことに疑問をいただいたことはありませんでした。

しかし、最近は要件定義の段階でテストケースを作り始めています。 すると、要件に漏れがないか、あいまいな点がないかがすぐに分かり、それによって修正が必要な箇所が早期に発見でき、手戻りが減ることに気づきました。

この方法を思いついたのは、特に何かを学んだわけじゃなく、なんとなく実験的にやり始めてみた取り組みでした。

しかし、自分の思いつきだけでは心許ないので、しっかりとテスト計画について学んでみようと思い立ち、『体系的ソフトウェアテスト入門』を手に取りました。

「予防テスト」というアプローチだった

さて、テスト計画というのはどういう風に進めていくのだろうか？と、ページをめくり始めたら２ページ目にいきなり僕が読みたかった内容がありました！

予防テストは、システム開発ライフサイクルの非常に早い段階から実行すれば、テストには対象のソフトウェアの品質を実際に改善する効果がある、という考えに基づいている。(p.2)

この文を読んだ時には、かなり興奮しました。

「システム開発ライフサイクルの非常に早い段階」にテストのプロセスを持ってくる。まさに、やろうとしていたことと同じです。

では、予防テストがどういったものなのかを紹介していきます。

予防テストとは？

予防テストとは、設計やコーディングの前にテストケースを作成することで、要件定義に潜む欠陥を見つけ出すというアプローチです。

要件定義の段階でテストケースを作成して、要件の精度を上げることで、後の工程での手戻りを減らすという考えです。

実装が完了したソフトウェア自体をテストするのではなく、要件そのもののをテストするという感じですね。

さて、この「予防テスト」というアプローチの背景にある「テストについての考え方」が、学びが深かったので紹介します。

時代経過に伴うテスト定義の変化

本書の1ページ目は、テストの定義の変化が紹介されています。歴史好きの私としては、たまらないですね

年	定義
1979	テストとは、エラーを見つけるつもりで、プログラムまたはシステムを実行する過程である。
1983	テストとは、プログラムまたはシステムの属性を評価することを目的とするあらゆる活動である。テストはソフトウェアの品質を測定することである。
2002	テストとは、対象とするソフトウェアの品質を測定して改善するための、テストウェアをエンジニアリングし、使用し、かつ保守しながら同時並行的に進めるライフサイクルプロセスである。

テストについての考えが進化しているのが、よくわかります。

同時に「予防テスト」というアプローチが生まれた背景も理解できますね。

予防テストの具体例

具体的な例を通じて、予防テストについてみていきましょう。

本書で紹介されているATMの要件を見てみましょう。

ここでは、

「適正なユーザーは200ドルまで、または口座残高と同額まで、預金を引き出せる必要がある」

という要件が出てきます。

これに対するテストケースです。

No.	テストケース	結果
1	残高が165ドルある口座から、200ドル引き出す	？？？
2	残高が200ドルある口座から、168.46ドル引き出す。	？？？

ただ、これらのテストケースは、要件から明確に答えを出すことができません。

なぜなら、「200ドルまで、または口座残高と同額まで」という部分の解釈が人によって異なるかもしれないからです。

この「または」が、悪さをしています。

例えば、 「200ドルと165ドルの口座残高の２つの値のうち、小さい方(165ドル)まで引き出し可能」 という解釈する人もいるでしょう。

もしくは 「200ドルと165ドルの口座残高の２つの値のうち、大きい方(200ドル)まで引き出し可能」 と解釈する人もいるはずです。

このような曖昧な要件をそのままにしておくと、実装が終わった後で問題が見つかった場合、修正のコストが高くつきます。でも、要件定義の段階で問題を見つけることができれば、要件を修正するだけなので、コストはずっと少なく済みます。この2つ目のテストケースについても同じことが言えます。

要件定義の段階でテストケースを作成することで、品質向上に寄与する予防テストの一例を見てみました。

Systematic Test and Evaluation Process (STEP) approach

このアプローチは、Systematic Test and Evaluation Process (STEP) approachというものらしい。 まだ全然読めてはいないが、テスト計画の立て方やプロジェクト全体とどう絡ませていくかを読み込んでいきたい。

このアプローチは、ICONIXプロセスとの相性も良い気がしている。 ロバストネス図を作りながら、テストケースを考えてしまえば、かなりプロジェクトの後半戦において効力を発揮するのではないか？など思う。

今回はさわりのご紹介ということで。

僕から以上。あったかくして寝ろよ。