ソフトウェアテストの専門の方に話を聞く機会があったので、今の自分の立場で意識しておくべきだと感じたことを書き残しておきます。 プログラミングで仕事してるのに、エンジニアリングのことを何も知らないのはヤバいなと危機感を募らせています。
ソフトウェアテストの7原則
- テストは欠陥があることしか示せない
- 全数テストは不可能
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- 「バグゼロ」の落とし穴
「4.欠陥の偏在」について、2割程度のモジュールに大部分のバグが発見されるという経験則があるそうです。
それは経験不足のプログラマー（おれのことじゃん）や、複雑なモジュールが原因です。
「それをどうやって見つけるのか」という質問があったところ、
「それは誰もが頭を悩ませている問題で一般的な方法はないが、
あらかじめプログラマーと話をすればポンコツかどうかわかるのでそいつをマークしてた。
そういうヤバいやつほどモノが分かってなくて過度に楽観的か悲観的なことが多い。」みたいなことを言ってました。
やっぱりおれのことじゃん。
テスト仕様書を知見として残しておくことが重要
自分の会社でもそうなのですが、テスト仕様書を毎回0から作ってしまい、
テストケース漏れが発生してしまいがちという話を聞きました。
それを防ぐために、きちんと振り返り・整理して知見を貯めていくことが大事だそうです。
「システム自体、機能仕様書と同様、テストケースも資産として残しておくべきなのにあまり理解してくれない」と
仰ってました。
私のいるのが比較的新しい部署なこともあり、
「テスト仕様書を振り返って資産化する文化がないのですが、上司たちをどう説得していけばいいですか？」
と質問したところ、
「そういう重要性がわかっているなら既にやってるはず。
一発デカい失敗したときにバカにしてちゃんと追及して変えるしかない」と言われました。
また、自分の日報に作業ログをまとめる＆個人でドキュメントツールを残していくべきという具体的なアドバイスも頂きました。
手順とテストケースを分離する
手順書は
- [前提]の状態でセッティングする
- [インプット]に従ってテストする
- その時の状態が[アウトプット]であるかを確認する
- エビデンスを残す
というように書いておいて、 テストケースとして[前提]、[インプット]、[アウトプット]の組み合わせを別に置くべきだそうです。 そうすることで、手順の不備と、テストケースの抜け漏れが別々にチェックでき、レビューがしやすくなります。
また、テストケースに直にチェックを入れるところもあるが、 資産として残していくためには良くないことだ、 オリジナルを残すべきだ、とも仰っていました。
ステークホルダーの合意形成が重要
プロジェクトに関わるステークホルダーが納得して作業を進めることが重要だそうです。 そのため、計画時点で必要なテスト仕様書の粒度（細かさ）も変わるという話も面白かったです。 計画がいけてればプロジェクトの半分は成功したようなものだと仰ってました。
逆に失敗するとQCD（Quality, Cost, Delivery）か人間関係のどれかが犠牲になるという話は笑えませんでした。
