こんにちは。HumanCrestの荒川です。
元日や誕生日に体調を崩すと、意外に良い一年を過ごせるというジンクスが私にはあります。
なぜ唐突にこんな事を書くのかというと、去る4月16日、左耳に発症したヘルペスがもたらす激痛と共に誕生日を迎えた私自身をなんとか励ましてやりたかったからです。
朝起きて最初に口にしたのは抗ウィルス剤と抗生剤でした。
今もウィルスやら菌やらに抗ってます。荒川だけに。ってうるさいわ。
さて今回は「テストの終了」についてです。
『テスト終了って何ですか？』
再び唐突ですが、皆さんはこの質問に何と答えますか？
“何をもってテストが終わったと言えるか？”という意図の質問ですね。
いわゆる「テストの終了基準」と言われるものです。
皆さんが関わっているプロダクトにはいくつくらいあるのでしょうか。
当然プロダクトによって様々かと思われますので、書籍やネットで書かれているような一般的なものをいくつか挙げてみます。
・テスト項目が全て実施済みである
・想定数のバグを検出している
・信頼度成長曲線が正常と判断できる推移で収束している
・検出されたバグが全て対応済みである
・修正されたバグのリグレッションテストをすべて実施済みである
・通常バグとデグレードバグの割合が妥当である
・テスト実施期間の終了80％以降に深刻なバグが検出されていない
※今回はシステムテスト寄りのものを選定しています
私の肌感でしかありませんが、こういった終了基準を明確に掲げているプロジェクトチームはそれほど多くないと感じています。
特にアジャイル開発でのテストプロセスにおけるテスト終了基準は関係者全員の”暗黙知”としている場合が多いです。
うまく回っているうちはいいのですが、こういったプロジェクトは少しの不幸が重なっただけで重大な欠陥を抱えたままプロダクトを世に送り出してしまうリスクを常に孕んでいます。
そうなる前にいま一度、
1. 自分のプロダクトのゴールは何か
2. 1を達成したと断定するには何がどうなっているべきか(主にここが今回の話)
3. 2を導き出すための材料は何か
を見つめなおしてみましょう。
それをチームで”形式知”として共有することによって、いま以上に明確なビジョンを持ってテスト活動に臨むことができます。
そしてその営みは、リリースや納品前に検出すべきバグをしっかり摘み取る可能性を上げることができる一つの要因になると私は思います。
＃ちなみに上記1,2,3の考え方は「GQM」という計測手法です。
＃こちらも勉強してまた近いうちに皆さんに展開できればと思っています。
Tweet