テスト設計コンテストを見て残ったもやもや感

JaSST'13 Tokyoへ行ってきました。
テスト設計コンテストを見てたらだんだん訳が分からなくなってきました。

[そのフェーズなの？]

機能テスト以外のユーザビリティやユーザーに対するリスクを重視しました！みたいなチームが多かったように感じました。
結果、「仕様をこうしたほうが良い」みたいな仕様に対するテスト結果がでてきてたりしました。
ただ、どのチームもテスト要求分析から始めるウォーターフォールな感じの進め方をしていたため、仕様変更を要求するには結果がでるのが遅すぎるのではないか？と感じました。
開発プロセスも含めてどのタイミング（仕様検討と同時にテスト分析するとか）で行うのまで絡めて考えないと有効ではない、というかやり損じゃないのかなぁ。

[テストと評価の違い？]

どうにも機能テスト以外の項目が腑に落ちなくて。
ユーザビリティとかって割りと普通のテストの範囲を超えているような気がします。
OK、NGをつけるテストではなく、評価っぽいなと。
では評価としてみると、全然足らない訳です。
車なんかでは官能評価と言って、「ドアを閉めた時の音」だとかそんなのも評価項目にしてたります。
「評価」ならば、今回のお題だとポットの質感、肌触り、ボタンを押す感触とかも項目にあがって欲しい。価値って結構相対的なので、競合ベンチマークとかも。

[ドキュメント多くない？]

新規開発ならこんな感じでいいのかもしれない。
実際は、新規開発なんて少なくて、改造や派生開発が大半のはず。
次回の改造時に作ったドキュメントをどうメンテナンスしていくのか。
どうにも実際の仕事に組み込める気がしなかったんですよね。
もっと楽して効果のあるやり方はないものか。

[良いテストを評価する方法は？]

開発の場合はLOC、複雑度、OOならCKメトリクスみたいに、ある程度指標となるメトリクスがあるのだけれど、テスト設計ではテスト設計に対する良い指標がない。
基調講演ででてきたDDP（テストで見つかったバグ数を、リリース後に見つかった合計バグ数で割ったもの）は有効そうだが、コンテストのようにリリースしていないテストには適用できない。
なんというか、テストの世界はまだまだ工学的に発展途上なんだな、というのは理解できたんですけどね。