こんにちは
システムチームのKです。
開発にテストはつきものですが、
そのテストで問題が発生することが、ここ最近多いので、
先人の知識を参考に考えてみようと思います。
テストの７原則
JSTQB（日本ソフトウェアテスト資格認定委員会）という組織で規定されたもので、
そんな資格があるんだと思いつつ中身を見てみたのですが、
かなりしっくりくる内容になっています。
７原則の中身は以下の通り。
1. テストは欠陥があることは示せるが、欠陥がないことは示せない
2.全数テストは不可能
3.早期テストで時間とコストを節約
4.欠陥の偏在
5.殺虫剤のパラドックスにご用心
6.テストは状況次第
7.「バグゼロ」の落とし穴
特に3、4、7は今のうちのチームのテストの問題を解決するヒントになるかなと思います
早期テストで時間とコストを節約
基本的にすべての実装を終えてから、テスト環境に上げて一気にテスト、
という手法を取っているため、
タスクによっては、膨大な量の不具合が返ってきたり、仕様や要件から逸脱していて、
大きな差し戻しになるようなミスが発覚します。
実装途中でも、段階的にテストを実施することで、
最終的にかかるコストやミスを減らせます。
欠陥の偏在
これはテストをする側、の場合ですが、
2.全数テストは不可能 でもある通り、
与えられた時間の中で、実装内容のすべてを網羅しきることは不可能です。
それなのに、まんべんなく浅いテストをしてしまうので、
根深いところにあるバグを検知できず、
リリースからしばらくたってから、とんでもないことになります。
テストで見つかるバグの大部分は「特定の少数のモジュールに集中する」傾向があるので、
ひとつバグを見つけたら、その部分を集中的にテストして、深いところまで見つけ出す方がより効果のあるテストになります。
「バグゼロ」の落とし穴
″テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織
があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけで
システムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべて
を徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期
待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがあ
る。″
引用：http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
リリースしてから不具合が発生したときに、
「テストをして問題なかったから大丈夫だと思いました。」
という発言をよく聞きますが、
それは＝システムにバグがないということではありません。
今動いているシステムも、たまたまバグが見つかっていないだけ、という可能性も大いにあります。
ここからはテストよりも実装の話になりますが、
「これなら不具合が出ても仕方がないじゃないか」と思うかもしれません。
プロのプログラマとして、不具合は絶対出しちゃダメです。
しかし、人間としてミスは起こりうるものなので、
もし不具合が発生してもいかにユーザのストレスを抑えつつ、
素早く、確実に不具合対処できるような準備が実装に組み込まれているかが大事だと思います。
例えば、
例外処理が発生した場合でも、
画面にFatalが表示されるのではなく、
用意されたエラーページに飛び、管理者にメールで通知が行く仕組みを組み込んでおく とか
わりと当たり前のことだとおもいますが、
それもちゃんとできていないことが多いので、きちっとする必要があると思いました。
最後に参考サイト、資料を掲載しておきます。
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
