ソフトのバグを出さないようにと周りから言われますし、私もいうと思いますが・・・現実的には難しいと言われますよね。無名ベンダどころか、超有名で実力もあるGAFAレベルでもバグはあります。バグが混在する原因や理由はいろいろ異なると思いますが、テスト工程で何で見つけきれないのか、整理してみました。
■備忘メモ
JSTQB http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf （P17より）
●テストの7原則
1.テストは欠陥があることは示せるが、欠陥がないことは示せない
→ある条件下においてバグがないと証明する事が限界。
負荷状態、ハード条件、各アプリのバージョン、入力条件なら正常でしたなど。
2.全数テストは不可能
→現実的に入力される情報が無数にあるので現実的ではない。
漢字、数字、半角、画像などなど、バリエーションが無数にある。
3.早期テストで時間とコストを節約
→実装や結合が進んでからの修正は影響範囲が広くなるので早期に修正すべし。
4.欠陥の偏在
→特定の部分にバグが集中する傾向がある。
もともと複雑な処理部分や経験が薄い人物によるコーディングなど。
5.殺虫剤のパラドックスにご用心
→同じテストを繰り返すと、最終的にそのテストで新たなバグは見つからなくなる。テスト条件を変える事が必要。
6.テストは状況次第
→システムの社会やビジネス影響によって変えるべき。
生命にかかわるようなシステムと社内に閉じるシステムで同じテストは不要。
7.「バグゼロ」の落とし穴
→バグゼロは困難かつ、仮に修正や改良を加えたとした場合に、他の満たすべき機能や非機能（処理時間等）が使いにくければ本末転倒になる。
ある処理が時間かかりすぎて実用に足らないだと使われないソフトになる。
■Tips
バグがテスト工程で、「ゼロ」や「著しく低い」場合は、テスト自体が甘い可能性があるとの指摘も散見されました。進捗報告を受ける際に、バグがほぼないので順調ですと言われた際は、テスト自体は大丈夫ですか？と一つ確認するのもいいかなと思いました。とはいえ、今度はバグばかりです、なんて言われたらそもそもソフトの品質が悪いのかとなるので、システム開発は難しいですね。
誠実な対応もらえるとして、他のシステムと比べてバグは明らかに多い・少ないですかと？比較して判断していくのが１つ回答なんですかね。
