Twitter等で「まともにテストできてないところはたいていCPM法だよねwww」みたいなことを見かけることがありますが，ちょっともやもやすることがあります。
私はCPM法は「最低限やるべきテスト」としてそれなりに大切というか基本的な考え方と考えています。
[amazonjs asin=”4817193603″ locale=”JP” tmpl=”Small” title=”ソフトウェアテスト技法ドリル―テスト設計の考え方と実際”]
CPM法ってのは要求項目や仕様項目の記述のおしりに「○○できることを確認する」とか「○○であることを確認」みたいにテストケースを作るという”やっていることは塗りつぶしチェック”に近いわけですが，故に定義した要求や仕様のそれぞれが確実に最低１バリエーションのテストケースが実行されます。この場合テストとしての強度や充実度については，ドキュメントが相当テストのことを考えて書かれていない限り弱いことは明白なのですが，少なくとも一回はテストされているということで記述に対するテスト実行の網羅性は100%を達成することになります。要求項目や仕様項目に対するテストがありませんでしたみたいな話をそれなりに聞くことがありますが，それは解決できるわけです。だって最低一回はやりますから。
また，CPM法をきちんとやると結果として要求項目や仕様項目とテストケースとのトレーサビリティが確保されるように誘導されます。だって，仕様項目に対してテストケースを紐付けしておかないとテストレビューで指摘されることになります。「ことを確認するテストが漏れてるじゃん！」ってね。でもこれって大切なことで，テストで基本的な考え方として抑えておかねばならない「バリデーション」を（程度はあるけど）フォローできるってことなんです。
つまり，仕様書等に書かれていることはある意味まじめにテストされているわけですから，きちっとCPM法をやると要求や仕様ベースの品質はけっこういい線までいきます。この結構いい線までいったところで，さらに高い品質をもとめるためにテストケースを増やすためにテスト技法などが活躍します。基本的な品質を確保したところでテスト技法を活用して合理的にテストの強度や充実度，ある尺度における網羅性をさらに高めるわけです。テスト観点によるテスト分析設計技法を使おうが，要求や仕様について漏れなくテストするということが大切なことは変わらないわけで，そういった意味でCPM法はそれなりに価値がありますし，基本的なことなのだと思います。
そんなことからCPM法はまじめにやれば結構役に立つので，雰囲気でCPM法wwwと使われている場合などにもやもやするんだろうなぁと思います。