奥深く悩ましく、そして楽しいソフトウェアテストの世界

テストの世界地図

»

今回のコラムはアドベントカレンダー、ソフトウェアテストの小ネタAdvent Calendar 2021とのコラボになります。
年の暮れをソフトウェアテストの小ネタと共にお過ごしくださればと思います。

「テストの世界地図」を描いてほしい

タイトルの「テストの世界地図」とは私が実際に開発プロジェクト初期のお客様との会話で出てきた言葉で、"テストの全体像"を意味します。
テストの世界情勢を語ることを期待されていた方にはすみません(いないと思いますが)。

しかしご安心あれ!今年のソフトウェアテストシンポジウム 2021 北海道において「テストの現状調査~世界を覗いてみよう~」というセッションがあり、資料も公開されています。ぜひこちらも見ていただければと思います。(JaSST Hokkaido 実行委員の皆様の素晴らしい取り組みの一つです!)

本題に戻りますが、テスト計画におけるレビューでは現場の開発担当者だけでなく、その上位層の方もおられることが常ですが、とにかく伝えることが大事になってきます。
どのような目的でテストを行うのか。どのようなテストプロセスで、どのようなテストを構築して実行していくか、言葉だけではなくモデリングしての説明も必要になるでしょう。
特にテスト戦略は詳細すぎると上位層ではわかりにくくなるため、システムをモデル図とテストの流れをUMLの配置図で表現したり苦心していました。以下のような図です。

テスト戦略イメージ.PNG

そのレビューの中で、全体を理解するため「テストの世界地図を示してほしい」旨の発言があったわけです。

「テストの世界地図」=機能一覧では今一つ

テストの世界地図=テストの全体像=テスト戦略の可視化と異なるもの、ということはわかるのですが具体的に何か?の回答は得られず、ともかく全体を俯瞰するドキュメントと捉えて考えてみました。

まず思いつくのが"機能"という視点で、それらを一覧化し詳細化することを考えました。
俗に「機能一覧」と呼ばれるドキュメントです。
機能一覧はテスト活動の初期に作成するものではありますが、実は開発初期の段階では機能が不明確で暫定でしか書けない状況だったので避けていました。
また、機能と一口に言っても、システムが大きく複雑な場合は、単純にユーザ視点でのみ書ききれるものではないことにも気付いていました。
安直に機能一覧を作成してしまうと、その視点の違いから混乱を招きそうで、ある定義に従って書き分ける必要があると思っていました。
その定義については後述になりますが、ともあれ機能一覧は作成し、お見せしたのですが、結果は「複雑すぎてイメージできない」というような感触で、もう一工夫が要りそうでした。

要求マトリクスで全体像を表現してみる

機能を書き分けについてですが、まずは機能という言葉ではなく「要求」と「仕様」という形で紐付けることで整理を行いました。
機能という言葉自体には要求と仕様が混在しています。
製品に求められている機能=要求、要求を満たすための機能=仕様、という定義で整理したわけです。
また要求についても、ユーザが直接操作したり触れる部分を外部要求(システム要求)、ユーザの目には見えない内部処理を内部要求(ソフトウェア要求)として分けることにしました。
その外部要求と内部要求の関連性(関与の度合い)と、テスト実行の状況をスコアにしたのが以下の「要求マトリクス」になります。
要求マトリクス.PNG
詳細な説明は本コラムでは割愛しますが、内部要求には詳細設計レベルの仕様が、外部要求には工程ベースのユースケースを、USDM(要求仕様記述手法)によって構造的に書かれた要求仕様書があるという運用になります。
テストの世界地図の話が、機能をどう表現するという転換になり、結果的にモデリングではなくマトリクスで表現するという形になりつつも、ひとまず決着ということになりました。

まとめと考察

今回は開発初期段階で機能が明確になっていないこともあり、テスト観点を出さない(出せない)形での全体像として苦心した結果、最初の段階で描いた配置図と要求マトリクスの作成でテストの世界地図を表現しました。
もちろん、世の中にはテストの全体像を示す手法がこの他にもいくつもあります。
例えば、ゆもつよメソッドにおける「テスト分析マトリクス」や、書籍『ソフトウェアテストの教科書[増補改訂 第2版]』では機能と観点のマトリクス「テストマップ」があります。
またテスト観点のモデリング記法としてNGT(「テスト設計におけるモデリングのための記法の提案」)もあります。
こうしたモデリングやマトリクスといった手法は状況で使い分けるためにも幅広く知識として抑えておく必要がありそうです。
また、こうした全体像の作成に関する課題としては、作成コスト、作成の容易性:書きやすさ、保守性:更新のしやすさ、といった点も考慮したいところです。

それではこの辺で。またお会いしましょう。

Comment(0)

コメント

コメントを投稿する