前回の続きです。今回はテスト編です。
テスト
プログラミング、製造、making、codingなどとも呼ばれる、実際にプログラムの実装が終わった後にそのプログラムが期待通りに動くかを検証する工程です。管理人の経験上、一番緊張し一連の開発の中で最も長く感じる工程です。基本的にバグを検出し、修正して再検証し納品までに仕上げていきます。本工程はwikipedia上ではテストのみで説明されていましたが、多くの場合は２つに分けられると思います。一つは単体テストと呼ばれる工程で、ウォーターフォールモデルでは、詳細設計と対になります。もう一つは結合テストでウォーターフォールモデルでは外部設計に対応します。場合によっては総合テストなどと呼ばれる工程を別に分けます。管理人のお仕事上の経験では要求定義を満たすかという観点で実施しています。
この工程から参加することになったら？
繰り返しになりますが、この工程から参加することになっても管理人でしたら要求定義をまず参照します。なぜならそのシステム・プログラムが何を目的としているか把握しなければ、何をテストすべきかわからないからです。また、本工程から参画するのであれば、設計やプログラムした方と円滑にコミュニケーションをとれるようにすることを心がけます。さすがにテスト工程から参画する場合、独力で仕事を進めるのはかなり困難となるので、適宜状況を把握している方の協力を仰ぐ必要があるからです。要求定義の把握と同時に人間関係の構築が重要になります。
検証項目の作成
テスト工程における役割は、前工程の設計で定義した機能や業務フローが本当に実現できるかを確かめることです。そのため、設計や要求定義で定義されている項目を実現できるかを検証項目として定義し、実際にテストします。例えば、△△データを新規に作成するという機能があれば、テストデータを準備し、実際に新規作成する機能を動作させてデータが作成されるか、ということが検証項目になります。
テスト工程は、バグが出ることが当たり前です。人間が作成している以上ミスが含まれることはある程度想定しなければいけません。逆にバグが一切テスト工程で検出できない場合は、検証項目の作成に問題がある可能性があります。こういったことはソフトウェア工学においても認知されており、横軸に時間、縦軸にバグの累積検出数をプロットしたバグ曲線で確認することができます。バグが極端に少ない場合は、強化検証といってさらなる検証項目を新規に作成し、本当に問題ないかさらに確認すべきです。
テスト工程で、面倒だと管理人が感じるのは、単体テストよりも後の結合テストや総合テストのバグです。後工程で検出したものほど、大本の要求定義に関するものになり、プログラムのコーディングで修正が大掛かりになりがちになります。またいざ動作させてみると要求定義を満たしつつもお客さんの想定と違っているということもあり、この場合は要求定義自体が不十分なので対処のしようがないのですが、もめることが多いです。そのため要求定義を盾に戦うことになります。
検証ログの確保
検証ログはしっかり保存しましょう。自身が検証者である場合はもちろん、監督する立場であった場合はログだけが唯一の証拠です。開発や検証ではやったやらないの水掛け論が起こりますが、それらは無駄です。ログがすべてです。ログを元に議論し、検証パスかNGかを決定します。また誤操作した場合の解析にも使用しますので、ログは必ず残すようにしましょう。
あとがき
毎回テスト工程は胃が痛くなります。自身でプログラム書いてなくてもバグを適切に検出できなければ、検証の責任者として責任を問われます。開発対象の品質を担保するために、開発対象が何を実現しなければいけないかをしっかり理解し、検証する場合な項目が確認すべき観点を満たすかに留意するようにしています。それでも漏れたり、コストや基幹的な制約で落とさざるを得ないことあるので毎回ドキドキしています。次は番外編ということでスケジュールなど開発全体の管理について考えてみたいと思います。
