「不安だから」はテストをする理由にならない
ご無沙汰です、夏以来ブログ更新を怠っていたhalspringです。
特になにかあったわけではなく、ふと思い立ったのでそのまま綴ります。 変な文章になっていてもご容赦願います。
テストをする理由
テストには目的があり、テストには必ず理由があります( なければ実施する意味がありません )。 では、テストは一体なぜ行われるのか。
JSTQBのFLシラバスでは以下のように書かれています。
すべてのプロジェクトで、テストの目的は以下を含む。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 明確にしたすべての要件を満たしていることを検証する。
- テスト対象が完成し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- 欠陥の作りこみを防ぐ。
- 故障や欠陥を発見する。
- ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
- （以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する。
- 契約上、法律上、または規制上の要件や標準を遵守する、そしてまたはテスト対象がそのような要件や標準に準拠していることを検証する。
これらの目的のために、要件を満たしていない機能がないか/ビジネス上のリスクはないか/ユーザーに不利益はないか/法的に問題はないかなど悲観的な考えを持つことが重要になります。 ( JSTQB FLにもテスト担当者のマインドセットとして悲観的な考えが挙げられています。)
悲観的な考えには、不安がついて回ります。
プロダクトで起きてほしくないこと、潜んでいそうな欠陥(過去の欠陥や類似機能の欠陥など)について考えたりと、あらゆる不安を考えます。
不安だからテストをする？
さて、ではテストを行う理由は「不安だから」で良いのでしょうか。
※ここからは勝手な妄想を含みます。 特に誰かが「不安だからテストします」をしていたのを見たわけではないですが、なんとなく「起こり得るのでは？」と思っているだけです。
不安を考えることは誤りではありませんし、悪いことではないと思います。 しかし、「テストを行う理由」にしてしまうことには違和感があります。
「不安だから」は論理的ではなく、感覚的です。 感覚的なテストは果たして良いテストなのでしょうか。
特にテスト仕様書を準備するようなテストにおいて、理由として十分なのでしょうか。
不安をブラックボックスから取り出す
その不安は何に起因しているのでしょう。
不安が現実になってしまったらどんな影響があるのでしょう。
「不安だから」のままでは定量的な評価ができません。 また、際限なく不安は生まれます。
際限なく生まれてくる不安すべてをテストしていては人も時間も足りません。 工数が足りないどころか、工数を掛けるだけの価値があるのかもわかりません。
不安は不安のままでは良くなく、正体を探る必要があります。
不安を「ビジネスインパクト」「影響するユーザー(ステークホルダー)の規模」「発生する可能性」などで定量的な数字に落とし込みます。
( はい、お気付きかもしれませんがリスク分析です。 )
定量化することでテストの優先順位付けや実施する/しないの意思決定が容易かつ合理的になり、納得感も増すことでしょう。
可能であればさらに、テストで確認する必要があるのかも検討すると良いかもしれません。 別の方法でより簡潔もしくは確実にケアすることができるのであれば、最適な手段を用いるべきです。
テストで確認すると決定しても、どんなテストをどれくらい実施すればケアできるのかまで踏み込み、可能な限り合理的で効率的に設計します。プログラムと同じです。
「いい感じに実装しました」と言われてテスト側が良い顔しないのと同じように、「不安だからテストします」と言われても開発側は十分かどうか判断できませんしモヤモヤするでしょう。少なくとも自分はそうです。
プロジェクトの関係者が納得できる、そして合理的で効率的なテストができるようにするためにも不安の中身を知る必要があります。
「不安だから」で行っていいテスト
不安を理由にするのはどうなのか、と書き綴っていましたが、もちろん例外もあると思います。
例えば探索的テストのような工数を掛けずにテスト担当者の経験に基づいて実施するテストであればこの限りではないと考えています。 過去のプロジェクトから得た経験を活かしたり、視点を切り替えながら欠陥を探す活動は感覚的な一面も持っていますし、言語化の難しい不安も確かに存在するからです。
加えて、探索的テストは再現性を犠牲にしている一面があり、逆に考えるとテスト仕様書を用いるテストは再現性が(粒度はさておき)確保されています。テスト仕様書を作成した人でなくとも、一定のテスト実施ができるようになっています。 テスト仕様書を用いるテストは、実施されるテストが再現性を持つことに意味があるから行われるとも言えます。
だとすれば、再現性のためだけに言語化の難しい不安の正体を探り時間を掛けるくらいなら、手を動かしてテストしてしまった方が早いです。
おわりに
お読み頂きありがとうございました。
もしご意見ご感想等あればコメント、ツイート、DMなどお待ちしております。
——
参考までに、WACATE2013の井芹さんのリスクベースドテストに関するスライドをぶら下げておきます。
