テスト工程の見積り手法
バカにされがちなウォーターフォールですが、工程単位での見積り手法という意味では一味枯れたものがあって、ある数量的予想値を根拠にして、いろんな工程の予測工数を立てることが出来ます。というか、やります。(出来る、というと精度の議論が出てくるので)
標準にも拠るので一例を挙げて見ると、要件定義が終わったあたりで、システムの複雑性からなにからのパラメータをもって製造物の規模を割り出してみます。そして、規模と複雑性のパラメータから今度は「試験密度」と「予想される試験項目数」を出してみるわけです。試験項目数が出ると、今度は試験項目の消化ペースの見積りをしてみます。消化ペースは経験値で出すことが多いのかな。
- f(規模予測(不確実), 複雑性予測factor(不確実)) = α(不確実^2) = 試験密度
- f(α(不確実^2), 試験項目ペース(不確実)) = β(不確実^3)...
というわけで(どういうわけだ)当初の予測値がかなり不確実なものに対して、さらに不確実な値をパラメータにとった関数を適用することで不確実の次数?が上がります。ブレがあるものを連続してブレのある器に通す…うーん、カオスのバタフライ現象みたいな話になりますが、結局の値は「根拠あるように見えてあんまりない」世界になってきます。でも、手法としては結構枯れてるんですよね。
ところで、試験を行う、という工程は存在するとして、現在においてはその工程の工数をどう見積もればいいのでしょうか。別にイテレーション型開発でもウォーターフォールでもなんでも良くて、『試験』を目的とした作業・工程は存在するわけで見積りだって出来る／必要 なはずですから。
一例を考えてみると
- テストケースを作成するためのコスト
- テストケースそのものに誤まりがある場合もあるわけで、これが安定するまでの工程みたいなものもあるかも
- テストを実施するコスト (自動テストの場合はここが安定して低いのでしょうか?)
- 予測されるテスト再帰回数(うーん)
- 予測されるテスト再帰回数を求めるためのパラメータには「バグなどの修正回数」もあるか
自分が置かれている状況を見てみると、たとえばテストの自動化などで頻繁に再帰テストできるとして、それだけのテスト体制を作るのにかかる工数というものの見積りという作業が軽視されているような気がします。どんなに開発プロセスが俊敏になったりしても、作業とそのボリュームの計画というのはマネージャ層は必要にしているでしょうし、「見積もる対象」は１イテレーション全部、とするよりは「テスト」とか「スパイク」とかの単位に区切った方が再利用性も高いですよね...
なにが言いたいのかよくわからんのですが、今後も『見積り』というところは予・実・フィードバックのサイクルには必須だと思うわけで、プロセスや手法が変化するなら見積り手法もいいものを見つけて、自分なりにこれだと思うものを準備しておかないといかんなあ、と。
