Borlandさんが提案している要求ベーステストについて

要求ベーステストというものを提案している資料があったので読んでみました。
以下では要求ベーステストを資料に則ってRBTと略します。

無料会員登録するとPDFをダウンロードできます。→「TechTargetジャパン：指定されたコンテンツは公開を停止しました」

僕が読んだ限りだと、

1. 要求をモデル検査したり、語句のゆれをツールでチェックして要件定義の質をあげる
2. テストケースをロジカルな図やマトリクスをつかって作成する
3. プログラマー、テストエンジニアにレビューしてもらう

というのがメインプロセスでした。

で、Borlandでは、1.と2.に関するツールを提供していますよ。っていう。
前半が現状のテストについて、RBTの概説
後半がRBTをBorland製品で実践するには って感じです。

僕はモデル検査をまだまだ知らないのですが、この書籍でたまに勉強しています。

抽象によるソフトウェア設計−Alloyではじめる形式手法−

これはいいなっていう点と、自分の意見とは異なりすぎるなっていう点があったので書いておきます。

いいなって思ったところ

p5

アプリケーションの要件は頻繁に変化しますが、その変化は適切に管理されていません。多くの場合、要件とテストケース
の間のトレーサビリティが適切に維持されていないため、変化する要件に対し継続的なテストカバレッジを確保することは
困難になります。

これらの問題によって、大抵の場合、既存のテストケース策定方法および選定方法は略式的なものとなり、テスト実施者の経験と
スキルに大きく依存することになります。テストケースを体系的かつ綿密に策定することはほとんどなく、多くのケースは直感に
基づき策定され、これが、ソフトウェアの品質および必要なテストを予測不可能なものにしている主要な原因となっています。

これは同意ですね。なのでうまく管理できるようにしたいですねー。

これは自分と異なるなって思った点

p4

意外なことに、テストは十分かつ正しく実施されたにもかかわらず、ユーザーを不愉快にさせるシステムが完成する場合があります。
その理由は簡単です。開発チームが要件定義を誤っているのです。

• >開発チーム,テストチームってわけているとしたら、開発チームにしろ、テストチームにしろ要件定義を誤っている現実は変わらない。この書き方では開発が悪いというふうに見える。

p4

その分野のエキスパートのスキル不足により、テスト可能な一貫性のある正確な要件を定義することができず、また、ユー
ザーとともに要件を効率的に検証および評価できるようなツールもないため、質の悪い要件が指定されてしまう。

• >スキル不足のエキスパートってエキスパートじゃないですよね。

p5

テストは、慎重な計画と綿密な遂行を必要とする、手間と時間のかかる作業です。

• >変更の出来ないテスト計画(テストカテゴリ間の優先順位、テストカテゴリ内での優先順位、などなどを把握できていない計画)を立てていることが「僕は」問題だと思っている。テストの特性ではなくて、それは開発も一緒です。

うむぅ。どうなんでしょうか。
ツッコミおまちしております。