テストってなんだろう？ 第一回「テストは欠陥があることしか示せない」
転職してはや2ヶ月。
2016年が2ヶ月過ぎようとしてます。
私はあっという間の2ヶ月でしたが、みなさんはいかがでしたか？
東京に越してきてから、土日は勉強会に参加しています。
その中で、テストエンジニアと名乗ると興味を持ってくれる人が多いです。
まだまだひよっこのテストエンジニアですが、開発者だった前職から品質やテストについて考えることが多かったです。
そこで、今回はテストってなんだろう？と考えてみました。
JSTQBでは、「テストの7原則」として公開している原則があります。
- テストは、欠陥があることしか示せない。
- 全数テストは不可能
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- 「バグゼロ」の落とし穴
この原則が成り立つことは私も同意します。
7回に分けて、1つずつ見ていきましょう。
原則1．テストは、欠陥があることしか示せない。
「よし、テストをすべて消化したから、これで欠陥がないことが証明できたぞ」
と言って、リリースしたらお客さんから欠陥が発生したと連絡があったという経験はありませんか？
私はたくさんあります。そして、その経験があるので経験則でこの原則が成り立っていることも理解しています。多分、開発者からプロジェクトマネージャになった方も経験しているのではないでしょうか？
なぜ、欠陥が無いことは示せないのでしょうか？
これは、幾つか原因はあります。1つ目は製作したサービスがOS上で実行されるからです。当然OSもソフトウェアです。欠陥を十分に含んでいます。じゃないと月に何回かアップデートが入りませんよね（笑）
というわけで、OSの欠陥に起因するサービスの欠陥があるかもしれません。それが、OSの特定バージョンだけだったら。。。と考えると欠陥が無いことは示せませんよね。OSを例にしましたが、ブラウザだってそうですね。IEとかIEとかIEとか。
2つ目は、納期、コストが制約になる場合、優先順位をつけてテストを実行するしかありませんよね。テストが重要ということはわかっているけど。。。ということです。テストケースもこの制約を受けるので、無いことを示すまでテストを実行し続けるのは不可能です。全数テストについては「全数テストは不可能」の回で詳しくお話します。
3つ目は、デグレーションが発生する可能性があるということです。デグレですね。
欠陥を発見して、修正しましたがその修正が新たな欠陥になるデグレーションです。
欠陥を修正したときにどこまで回帰テストをやるかというと、納期、コストがここでも制約になります。
と、まだまだあると思いますが、上記を考えるだけで欠陥が無いことは示せません。
ただし、この原則を伝えると、経営者やプロジェクトマネージャの方はお怒りになるのではないでしょうか？ もしくは彼らは不安で眠れない夜が続くかもしれません。
この不安を完全に解消することはできません。断言できます。(だって、欠陥が無いことは示せないんだもん) しかし、テストをすることで和らげることはできます。
そのために、テストレベルが存在します。
例えば、コンポーネントテスト(機能テスト、単体テストとも呼ばれる)、非機能テスト、統合テスト、システムテスト、受け入れテストなどレイヤーが分かれているのはそのためです。その他にも会社によって違う呼び名があるかもしれませんが、同じような内容のテストをしていると思います。いろいろなレベルのテストを実施することで細かな欠陥から、ユーザーの要件を満たしているかという仕様の欠陥を見つけ出すことができます。
「ローマは一日にして成らず」
テスターも一日にしてなりません。特に開発者と違って、経験値が必要な職種だと思います。職人技とも呼べるでしょう。
みんながゆったりと眠るために、少しずつテスト力を蓄えていきましょう！
