評価開発

特に研究者に多いが、ソフトウェアテストと聞くとプログラムのホワイトボックステストを思い浮かべる人が多い。もちろん1970年代前半はそうだったのかもしれないが、現在は違う。

テストと似たような活動に、レビューやインスペクションがある。バグを見つけるという意味では、形式検証もあるだろう。この際、メトリクスを測定する活動も含めてしまおう。これらは、プロジェクトの様々なフェーズにおいて、様々な手段で、様々なソフトウェアの特性を調べる活動と考えることができる。これをここでは、評価と呼ぶことにしよう。

そう、テストとは、ソフトウェア評価のうち、ソースコードの出現後に実施される動的検証という、一つの手段を意味する。でもまぁ、この分類にはあまり意味はない。

意味があるのは、こうした評価の活動には全て分析・設計が必要だという点である。言い替えると、評価開発になるかな。プログラムを開発することと同じくらい、評価項目や評価手段の設計というのは難しいのだ。だから、頭を使って方法論を構築し“開発”すべきである。

仲でも、評価戦略の策定は重要だ。開発しようとしているソフトウェアにおいて評価すべき特性にはどのようなものがあり、どのような手段、どのような単位で測定できるのか。各評価手段は、どのように棲み分けて、補完しあうのか。それらが製品価値にどのようにつながっていくのか。こうした評価戦略を決めないといけないのだ。しかも上流でね。

ソフトウェア開発の現場では、評価活動全体を俯瞰的に捉えている場合はあまりないだろう。しかし開発項数の5割以上を評価に割いており、評価工数が足りない足りないと騒ぐのであれば、評価を俯瞰的に捉えて“開発”すべきである。そうしないから、評価工数が爆発したり、評価漏れで不具合が市場に流出するのだ。

テストの方法論は、最終的に評価開発の方法論に昇華すべきだし、しなくてはならないだろう。その第一歩として、テスト戦略を立ててテストレベルやテストカテゴリに分割してみるとよい。慣れてきたらレビューの観点を加え、形式検証、メトリクスと増やしていけばよい。

我々メソドロジストも、評価全体を視野に入れて方法論を構築しないとね。これはなかなかチャレンジングだが、楽しい作業だと思う。