RDRA2.0をテスト要求分析に活用してみたというお話です。
はじめにおことわりしておきますが実業務で使ったわけではなく、テスト設計コンテストのOPENクラスに出場した際に適用したものです。
RDRA2.0とは
RDRA(ラドラ)2.0は、要件定義を行うためのフレームワークです。
RDRAには4つのレイヤーが存在します。*1
- システム価値
- システム外部環境
- システム境界
- システム
各レイヤーにはそれぞれ目的があります。
- システム価値：要求を整理してシステム化の目的を明らかにする
- システム外部環境：システムがどう使われるのかを明らかにする
- システム境界：人とシステムの境界であるシステム境界を明らかにする
- システム：システム化する情報と、その情報の変化を「状態」として明らかにする
「システム価値」から「システム」までの各レイヤーには依存関係があるため、段階的に詳細化することができます。
依存関係が存在するため、必然的にトレーサビリティを取ることもできます。
具体的には次のような構成要素にてモデリングしていくことで、各構成要素間の関連を紐づけていきます。
RDRA2.0に興味を持たれた方は次の書籍を読んでみてください。(2024/03/30現在、Kindle Unlimitedに加入していれば読み放題対象になっています。)
この書籍では、RDRA1.0と2.0の違い、4つのレイヤーの詳細、図書館システムを事例にしたモデリングの実例が示されており、RDRA2.0について詳しく知ることができるでしょう。
なぜテスト要求分析にRDRAなのか？
さて、話の対象をテスト要求分析に戻しましょう。
テスト要求分析とは、何をテストすべきなのかを明らかにしていくプロセスです。
テスト要求分析では、各画面で起きうるイベントやそこでやり取りされる情報など詳細化された内容と、
システム化の目的などシステム全体を俯瞰視した内容を、行ったり来たりしながらテスト要求を明らかにしていくと思います。
仕様書や設計書などのテストベースからシステム化の目的やシステムに関わる人々を特定し、
テスト要求分析を行うこともできますが、テスト対象システムの規模が大きくなればなるほど、全体を俯瞰することが難しくなってきます。
そこでRDRAです。
RDRAは、システム化の目的からトップダウンで読むことはもちろん、テスト要求を抽出したい機能の「画面」を起点にどんな「ユースケース」で使うのか、そこでやり取りされる「情報」はどんなものがあるのかなど関心事を中心に読んでいくことができます。
RDRAを活用する上での注意点
繰り返しになりますが、RDRAはあくまで要件定義のフレームワークであり、システムをどのようなアーキテクチャで構築していくのか、情報をどのように表現するかなどのHowは関心事として扱いません。
テスト要求分析においては、Howも関心事として扱いつつ、テスト要求を明らかにしていく必要があるので、Howの部分を補う別のフレームワークを適用する必要があるでしょう。
実際に使ってみてどうだったのか
テスト設計コンテスト2023 OPENクラスのテスト対象システムは動物園の入場管理システムで、
テストベースの総ページ数が数百ページに至る大規模なテスト対象でした。
純粋にテストベースを上から読み進めるだけでは全体像の把握は難しく、RDRAでモデリングをしていく過程で、テストベースの別々の部分に書かれた文章の内容を、モデルとして"つなげて"いくことで、テスト対象への理解を深めることができました。
特に、抽出したユースケースと情報のつながりは、RDRAのモデルなしに理解することは難しかったので、テスト対象を理解するという目的においては大きな効果を発揮しました。
おわりに
なんだ、大規模なウォーターフォール開発にしか適用できないのか、そう思った方もいらっしゃると思います。
現状、私がおしごとで関わっているチームはアジャイル開発を採用していることが多いですが、
手が空いた時にRDRAのモデルを一つ作っておけば、システムの全体像を俯瞰でき、エンハンス開発を進める中でもテスト要求分析に活かせるのではという期待を持っています。
実業務で使って良い成果が得られた際にはお知らせしたいと思います。
「RDRAをテスト要求分析に使ってみたよ」という方がいらっしゃいましたら、事例を共有いただけると嬉しいです。
