テストを止めろ！
今回のコラムはタイトル先行で考えていて、某映画のように「テストを止めるな！」としたかったのですが、内容を検討するに、むしろテストは時には止める判断をしないといけない、という結論からこのタイトルになりました。
基本的には「テストは止めるな！」が正しい
タイトルは「テストを止めろ！」と言っていますが、基本的にはテストは常に動き続けいている状態が正しい姿になります。
例えば、TDD(テスト駆動開発)のように実装とテストが並走したり、アジャイルのようにイテレーションを小さく早く実装～テストのサイクルを回すプロセスは、テストの導入を早く途切れなく行うことになります。
それが結果として、ソフトウェア品質／プロダクト品質向上の近道であると期待ができるわけです。
ただ、今回のコラムはそうしたTDDやプロセスの話ではなく、IT(結合テスト)～ST(システムテスト)～UAT(受け入れテスト)において、テスト実行担当者が気にした方が良いポイントといった視点で書きたいと思います。
テストを止めろ！～その１「多すぎる不具合に疑問を持つ」
テスト実行者が割り当てられたテストケースを誤りなく実行したところ、不具合が思った以上にザクザク出る、ということがあります。
テスト実行者というのは不具合をテストケースを通じて見つける役割からか、1日中テストを実行して不具合検出がないことに対してストレスを感じる人が多いです。
そのため、不具合検出が多いことに関しては寛容になりがちですが、多すぎる不具合については敏感になるべきです。
不具合が多すぎる、ということですが、まずコスト面から考えると、修正コスト～回帰テストの工数が増えるということになります。
また、品質目線で見ても"木を見て森を見ず"と言うように、自分が担当する範囲以外にも不具合が多い＝大元でコケている(仕様を勘違いして実装しているなど)可能性もあるかもしれません。
また、実装メンバーが行う単体テストに関するルールや手順にも問題があるかもしれません。
テストは不具合を多く見つける作業ではありますが、優先すべきは早く品質を上げるための行動であるべきです。
冷静に状況を判断し、時にはテストを止めてアラートを上げる、原因を探る、というアプローチも必要ではないかと思います。
テストを止めろ！～その２「不具合ゼロにも疑問を持つ」
多すぎる不具合とは逆に、不具合が全く出ない状況にも問題は潜んでいる可能性はあります。
不具合の予測値が多くなる新規開発など、状況と併せる必要はありますが、ここではテストミス(バージョン、環境)やテスト設計品質に対する問題がある可能性があります。
もちろんこのケースでは何も問題がない、ということもありますが、テストエンジニアの経験から言うと、不具合というのはある程度やれば何かしら出るもの、なので、不安を鎮めるためにも一度立ち止まることも必要ではないかと思います。
テストを止めろ！～その３「自分以外に目を向ける」
自分一人で開発～テストをしていれば、全ての状況は把握できるわけですが、そうではない場合、周囲の状況が今のテストを無駄な作業に変えている場合があります。
例えば、非常に広い影響範囲の不具合を自分以外のテスト実行者が見つけた場合、自分の担当箇所への影響をまず確認した方が良いでしょう。
黙々とノルマをこなすべく作業に没頭したいタイプのテスターも多いですが、コミュニケーションは素早く綿密に行うことで作業ロスは減っていきますので、周囲の状況を見て一度立ち止まるといった判断も必要です。
まとめ
今回は、テストを止めないといけない時、というテーマで考えられるケースをいくつか書いてみましたがいかがでしたでしょうか。
実行者目線で書きましたが、テストマネジメントの視点でも同じことが言えます。
テストリーダー、テストマネージャには実行タスクをメンバーに丸投げするだけでなく、全体の状況を見ながら中断／再開の適切なコントロールが求められていると思います。
機を見るに敏、できていますか？と自分にブーメランしながら、今回のコラムはここまでです。次回またお会いしましょう。