ソフトウェアテストの7原則とは
JSTQBという日本におけるソフトウェアテスト技術者資格認定の運営組織があり、「ソフトウェアテストの7原則」とはそこで提唱されている原則です。
1. テストは「欠陥があること」しか示せない
どういうこと？
これでもかというほど、ありとあらゆるテストケースを消化して「よし！欠陥はないぞ！」となったとしても、それは「欠陥が「ない」こと証明しているのではなく、これ以上欠陥が「ある」ことを証明できない」だけです。もしかしたら超レアケースのテストケースが抜け漏れていて、そこに欠陥が潜んでいるかもしれません。悪魔の証明と似ていますよね。
経験と照らし合わせて考えてみる
今のプロジェクトでも過去の数々のプロジェクトでもそうですが、本番障害は定常的に発生しています。もちろんリリース前にテストケースはかなり手厚く有識者にレビューをしてもらっていて、更に場合によっては「強化テスト」と題してモンキー的なテスト？もやっています。ですが、それでも本番障害は発生します。本番障害の内容を全て詳細に把握しているわけではありませんが、原因としては超レアケースのテストケースの抜け漏れが半分以上を占めている感じはあります。つまり、「1. テストは「欠陥があること」しか示せない」はその通りだと思います。
2. 全数テストは不可能
どういうこと？
システムが取り得る全ての状態、入力条件の組み合わせをテストすることは、仮にスーパーコンピュータを用いた自動テストを用いたとしても時間的に不可能、というものです。
経験と照らし合わせて考えてみる
システムがものすごく小規模で、入力される可能性のあるデータパータンがある程度限られていれば、全数テストは可能かもしれません。しかし、経験上必ずと言っていいほどそういいたシステムはありません。また、大規模システムの場合、関連のある機能をサブシステムという括りで分割させるケースがありますが、各サブシステムが取り得る全ての状態の組み合わせ、入力条件の組み合わせでのテストなどもってのほかです。つまり、「2. 全数テストは不可能」もその通りだと思います。
3. 初期テストが重要
どういうこと？
開発が進めば進むほど、不具合が発生した時の影響が前工程まで遡るため、その分修正・やり直しのコストが多くなります。逆に、ベイビーステップで少しずつテストをすることで、不具合が発生した時の影響が小さくなり、その分修正・やり直しの範囲も狭めることがきます。つまり、開発の早い段階でテストを行って不具合を潰しておくことが重要なのだ、ということです。
経験と照らし合わせて考えてみる
これもその通りだと思います。私自身そこまで大きな手戻りをした経験はないのですが、特に外部システムとIFがある場合なんかは、（本来結合テストで確認すべきものだけど）IF部分だけはその前に確認しておく、なんてことはよくあります。また、設計が複雑な機能なんかも、設計→実装（場合によってはテスト）、設計→実装（場合によってはテスト）のアプローチを繰り返すことが多いです。
4. 欠陥の偏在
どういうこと？
欠陥というのは、ソフトウェア全体に均等に分布しているのではなく、ある特定の機能、モジュール、クラスに集中しているというものです。
経験と照らし合わせて考えてみる
振り返ってみるとそうなのかもしれません。特に、業務要件が複雑な機能や難易度の高い機能に偏りがちな傾向にあるのかなと思います。また、かなり逼迫したスケジュールの中で作られた機能や、有識者が少なく質の高いレビューが出来ていない機能なんかも該当するのかなと思います。
5. 殺虫剤のパラドックス
どういうこと？
同じような観点のテストを何度も繰り返しているといずれは新しい欠陥が見つからなくなる、というものです。なぜなら、開発者はその観点のみを意識し設計・実装を進めるためです。これは、同じ成分で構成された殺虫剤を繰り返し使用していくと、それに耐性を持った虫が出現することで、いずれ効果がなくなってしまうということに似ているため、このように例えられています。
経験と照らし合わせて考えてみる
経験の少ないメンバーで構成されたチームの場合、（経験が浅いということもあり）相対的に視野が狭くなる傾向にあるためそういったチームには当てはまると思います。そこに経験のあるメンバーが1人でも加わることで、視野を広げることができ結果としてこういった現象に陥らないのではないかと考えています。
6. テストは条件次第
どういうこと？
ここでいう「条件」とは、構築するシステムや会社を取り巻く環境を指しています。例えば、構築するシステムが金融系のシステムであれば、金額計算やトランザクション制御にはかなり重きを置いてテストをする必要があります。個人情報を大量に扱うシステムであれば、セキュリティに重きを置いてテストをする必要があります。このように、全て同じ条件のテストではなく、システムの性質や会社を取り巻く環境によって、テストのやり方は変える必要がある、というものです。
経験と照らし合わせて考えてみる
私の経験してきたプロジェクトではほぼ全ての現場で、対象となるシステムやモジュールの特性を理解したうえでテスト計画を立てたり観点を洗い出したりしているため、あらゆるシステム、モジュールにおいて同じ条件でテストを行う、、、ということは経験したことないです。
7. 「バグゼロ」の落とし穴
どういうこと？
「バグ0＝高品質なシステム」というわけではありません。高品質かどうかを測る指標は、バグの件数だけでなく性能や信頼性等の指標によっても評価されます（所謂非機能要件といったものでしょうか）。例えば極端な例ですが「バグ0です、でも画面表示するのに30秒もかかります」といったシステムは高品質とは言えません。
経験と照らし合わせて考えてみる
これはどうなんでしょう。私の経験してきたプロジェクトではほぼ全ての現場で単体性能テストや高負荷テスト、その他非機能要件も意識して様々な角度からテストをしてきたので、自然と「バグ0＝高品質なシステム」とは思いませんでした。ですが、こういった原則がある以上、「バグ0＝高品質なシステム」という誤った理解を持った現場もあるということでしょうか。
最後に
ソフトウェアテストの7原則について経験と照らし合わせて考えてみましたが、ほぼ全ての原則が当てはある、ということになりました。
最近ではテストを重点的に行うQAエンジニアというロールも登場してきました。そういった方はもちろんのこと、実業務では開発がメインの方もこういった原則があることを知り、より質の高いテストとより質の高いソフトウェア開発の助けになれば幸いです。
また、当社の2018年Qiitaアドベントカレンダーも本記事で最後になります。初のアドベントカレンダーということで、メンバーもある程度限定し自由気ままにやってきました。来年はもう少しメンバーを増やしてより良いカレンダーにしていければと考えています。
以上です。
参考
http://jstqb.jp/index.html
https://appkitbox.com/knowledge/test/20121112-8