要件管理はテストの目的のために存在する
要件管理とテストの関連についてメモ。
【元ネタ】
Software Testing - Columns: VerificationとValidation
ソフトウェア開発のすべての規律はテストの規律と関連がありますが、その中でもテストと特に重要な関連を持つ規律がいくつか存在します。
* 要件管理
* 変更管理
* 構成管理
「要件管理」は、大部分のテスト作業に先行するもので、極めて多くのテストのモチベーション (動機付け) と検証のニーズを提供します。プロジェクトの個々の要件管理プロセスは、テスト管理のプロセスに大きな影響を及ぼす可能性があります。この関係をリレー競走に例えると、第 1 走者が要件管理で、渡されたバトンを受け取る次の走者がテスト管理です。
(中略)
「変更管理」は、ソフトウェア開発のすべての部分に影響しますが、追跡される変更のなかでテスト作業に最も関連が深いものは「欠陥」です。欠陥はしばしばテスト・チームと開発チームの間の主な意思疎通経路の役割を果たします。また、欠陥から引き出される集計とメトリックスは、多くの場合、品質の指標としても使用されます。
(中略)
テストにはどのビルドをいつテストするかの追跡が不可欠であるため、「構成管理」はテスト管理にとって重要です。構成管理では、ビルドに加えて、テスト管理がテストの実行のために追跡する環境も管理します。
(後略)
テストが変更管理に関係するのは、バグという変更要求が正しく実装されたか検証するプロセスとして必要だから。
テストが構成管理に関係するのは、どのバージョン、どのビルド番号のモジュールでテストしたのか、という観点が必要だから。
テストが要件管理と絡むのは、要件がテストの目的そのものだから。
テストにはV&Vという考え方がある。
Verification(検証)は、正しいプロセスで、仕様通りに動いているか、テストする。
Verificationは普通、コンポーネントとして単体テストや結合テストで行う。
Validation(妥当性)は、製品が意図された要求を達成しているか、テストする。
Validationは普通、システムテストや受入テストで行う。
要件管理が必要なのは、Validationのテストにあると言っていい。
システムに単にバグがなければ、品質がよいわけではない。
製品として魅力的でなければ、システムの価値は下がる。
要件を意識したら、テストの目的が明確になり、テストケースもその観点で詳細化されるだろう。
要件は受入テストのために存在するのだ。
せっかく苦労してシステムを作ったのに、次から次へと改善要望がやって来る場合、製品としてまだ成長途中か、あるいは、ユーザの欲求不満があるのかもしれない。
つまり、要件をきちんと管理できていなかったのが原因の一つなのかもしれない。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
コメント