要件のテスト

技術

1.W字モデルのような使い方。
要件定義や設計のような上流工程で、テスト計画も同時に作る。

例えば、要件カバレッジを使って、要件をカバーするテストケースが必ずあるか、これらのテストケースで要件を全て網羅しているか、を確認していく。
そうすれば、新たな要件が見つかったり、矛盾する仕様が見つかる時もあるだろう。

仕様漏れ、仕様の認識相違を早い工程で検知したい。
設計もテスト駆動開発のように、テストケースを考えながら検証可能な仕様へ落としていく。

上流工程の品質UpにTestLinkを使えないか？

TestLinkの可能性: プログラマの思索

これは興味深いテーマだ。
ソフトウェア要求でも要求に対してテストを考えることで矛盾点や仕様バグを見つけることを提案している。

これは確かに有効そうだ。ただ要件定義の段階では画面遷移も決まってないだろうから、「〜画面で〜を入力して〜ボタンを押して〜画面に遷移して〜を確認」というような結合テストレベルの詳細なテスト仕様書を書くことは無理だろう。それでもあまり詳細でない抽象度の高いテスト仕様書を書いたほうがいいのか？これは難しいところだ。大規模開発なら書く価値がありそうだが。

画面遷移図を含んだ外部設計書、機能仕様書から結合テストの仕様書をおこすというのはある。というかこれが推奨されている方法だろう。現実的にはプログラムが完成してから結合テストの仕様書を書くことも多いだろうけど。

エンハンスならすでに動いているプログラムもあるのでテスト仕様書も比較的書きやすいだろう。
新規の場合はプログラムが出来ていない段階からテスト仕様書を書ければ仕様バグを発見できる可能性が高い。ただ仕様をしっかり理解した人がテスト仕様書を書かないと手戻りも多いだろう。応援要員にテスト仕様書を書かせるはつらい。書き直しが多発するようでは意味がない。

その意味ではテスターが要件定義から参加するというのもありかもしれない。