FaRSeTの説明④(テストチャーターの設計)

前回の記事の続きです。

前回はFaRSeTの2つのテスト設計指針のうち、仕様変更の少ない部分(業務要件)をマインドマップで描いていくことを書きました。今回は仕様変更の多い部分についての記事です。

業務系のシステムでは、業務要件とシステムの一致が最優先なので、それを達成するためのUIや機能要件(以降は「システム要件」とする)は重要度が相対的に低く、仕様変更が多発します。乱暴に言うと「どんな方法でもいいから、業務にフィットしたシステムを作ってくれ。でもなるべく使いやすくな。」なので、開発の都合や利用者の意見によって頻繁に変わります。

せっかく作ったテスト設計もテストケースも、作り直しになります。テスト担当からすれば、「仕様を変えないでくれ」なのでしょうけど、これはもう仕方がない。仕様が変わることを前提にテストを進めるしかないわけです。

どうせ仕様が変わってしまえば役に立たなくなるテストケースなど、最初から作らなくてよいのでは?

が最初の発想です。

ということで、システム要件についてのテストは「探索的テスト」で行うことにしました。探索的テストについてはコチラ参照

探索的テストはテストケースを事前には作らずに、テスト設計と実施を並行で行います。ただし、「まったく自由に探索して!」だと「探検テスト」になるので、ある程度のテスト方針を「チャーター」として設計し、そのチャーターの中で探索してもらうことにします。チャーターについては以下を参照ください。

前回は探索的テストの情報収集でした。 さて、いよいよテストチャーターです。 テストチャーターは、「テスト目的」を定義したしたものです...
前回のエントリーに引き続き、テストチャーターの話です。 これは日本ナレッジ風「NKC探索的テスト」の方法です。 (これが正しい探索的...

上の記事にも似た内容が出てますが、チャーターの設計に「JIS X 25010:2013」の「品質モデル」を活用することにしました。非機能を含めた広い範囲のテストを行いたいことと、担当者によって「まったく違う方向性のテスト」にならないためです。また、探索的テストは不具合の検出には優れますが、網羅を目指したり見える化したりは苦手です。とはいえ「ふんわりと」抽象度の高い内容で網羅したいとは考えました。そのために品質特性を採用しています。ただ、上の記事にも書きましたが、品質特性をそのまま使うのは抽象度が高すぎるのでブレークダウンしてチャーターにしていきます。

さて、品質特性によってのチャーター設計のアプローチを以下としました。まずは、性能効率性以下の赤い囲みの部分から。

性能効率性以下は、俗にいう「非機能」の部分です。ここは、製品ドメイン毎にある程度の汎用性を持たせることができます。たとえばWEBアプリならばおおよそ共通になります。なぜかというと、同じ製品ドメインの中において、システムごとのそれぞれの違いは機能適合性のなかに大体が集約されるからです(使用目的の違いだったり、機能実装の違いだったりなので)。ということで、ここはドメイン毎の汎用テスト観点を利用します。以下はWEBシステムについての汎用テスト観点の例です。

この観点をもとに、実際のテスト対象に合わせてテーラリングしていきます。不要な内容などはカットしたり、変更したりしていきます。

さて、「機能適合性」の部分は、以下のようにあらわすことができます。

機能完全性:システムが業務要件を満たしている?

機能適切性:システムが業務ニーズに適合している?

機能正確性:機能が正確な実装をされている?

上の図でもわかる通り、機能完全性と機能適切性は、前回の記事で書いたマインドマップの「想定ユーザー・業務シチュエーション分析」の部分にあたりそうです。また、機能正確性は、マインドマップの「システム分析」にあたりそうです。

ということで、最終的にはチャーターを上の表のような形にしています。これで、品質特性からのブレークダウンを、マインドマップ及び汎用テスト観点を使って行うことができました。これで、ある程度の探索方針の決定と「ふんわりした」網羅ができるようになる、、、はずです。

この抽象度のさじ加減が結構難しいです。あまりに具体化させてしまうと、テスト設計と変わらなくなってしまうので。

さて、このチャーターをどうやって使うか。次回は実際のテスト実施のお話です。