ディシジョン テーブル。 これでテストケースが漏れない!効率的に単体テスト仕様書を作る方法

デシジョンテーブルを作成して上流工程の抜けモレ対策に使う

ディシジョン テーブル

【ビジネス・ルールとは】 ビジネス・ルールとは非常に曖昧で抽象的な言葉です。 以下はビジネス・ルールの一例です。 ・部品在庫がある場合の値引き率は、ICタグの色で決まる。 業務で発生する事象ごとにチェック、判断分岐、加工処理を施し、正しい業務アクションを支援します。 これは、かつて情報システム・アーキテクチャのフレームワークでデータとファンクションを分けた変革の状況に似ています。 変更頻度は、データよりもアプリケーションの方が多いため、相対的に安定性の高いデータを独立させたアーキテクチャにすることは保守性の問題を大きく改善し、経営資源であるデータの共有性を高めました。 ビジネス・ルールが変わることが仕様変更であり、安定性の低いルールをプロセスと分離することは情報システムの保守性向上の観点においても妥当性があります。 しかし、ビジネス・ルールをアプリケーションから独立して管理するというコンセプトには、違和感を覚える向きもあるかもしれません。 非常に乱暴な見解では、BRMは「ソース・コードからIF文を切り出して別管理するだけ」で、開発者側の視点で見ると「ITの管理対象が増える」ため、価値は見い出せないという理由からです。 しかし、システムの企画時に必ず起こる議論、「当社の業務は独特で他とは違う」、「業務変革のスピードが強みだ」、だから「汎用パッケージは当社に合わない。 相当なカスタマイズが必至だ」、「現行システムの仕様は、今の業務に合わない」等の根底にある主語は、ビジネス・ルールであり、業務の流れ自体は比較的安定性が高いものです。 弊社でもビジネス・モデリング・サービスを提供していますが、プロセスが構造化モデルで安定しているのに対し、ビジネス・ルールは、わずか2~3 ヵ月の間にも多くの変更が発生します。 そのため詳細設計になっても仕様がなかなか確定できないという現実があります。 【BRMSの登場】 ビジネス・ルールをアプリケーションから独立して管理するというコンセプトのもとに開発されたのが、BRMS製品です。 ユーザ視点での利点は、ビジネス・ルールをモデル化し管理することで、複雑なルールも高い透明性を持ち、保守も容易となります。 ルール変更はBRMS上で行うため、アプリケーションへの改修は不要か、軽微で済みます。 テクノロジー視点での特徴はルール・エンジンです。 パターン・マッチングのアルゴリズムをベースに多層複合的な判断ロジックを効率的に処理し、ルールの外出しで危惧される性能面の不安を払拭しました。 ルールのカプセル化で共有化を促進するとともに、ビジネス・ルールのモデリングをプログラム設計に先行して行えることで詳細設計と開発、テストを高速化します。 さらには、製品ごとの提供機能として、論理矛盾、ルールの定義モレの検出、シミュレーション、ルール変更時の影響分析などがあり、ビジネス・ルール管理を支援します。 【BRMSの現在】 現在のBRMS製品は、Suite化志向とビジネス・ルール特化志向で拡張がされています。 Suite化志向とは、BRMに加えてBPM(Business Process Management)も範囲とし、ビジネス・ルールとビジネス・プロセスを統合管理するものです。 ルールのカプセル化との親和性が高いことから、SOAソリューションとして組み込まれるものもあります。 ただ、Suite製品は製品特有の技術制約が足かせとなる面もあります。 一方、ビジネス・ルール特化型製品はビジネス・ルールのみを管理対象として、アプリケーション本体との連携はAPIやWebサービスで行います。 企業ごとのシステム基盤の制約にも柔軟に対応できる利点があります。 ビジネス・ルール特化型製品の中にはルールの設計/開発/保守をプログラマからユーザの手に委ねようと、ルールの記述、管理をノンプログラミングで平易なGUIで操作できるよう使い勝手を高めたものもあります。 ユーザ自身でルール変更作業ができるようになれば、業務変革のスピードが格段に向上し経営に寄与すると期待されています。 【保険業界への導入が早かった背景】 保険業界では、1990年代から業務を取り巻く環境が劇的に変化しました。 まず、 1990年代後半の保険業法改定によって保険商品の自由化が始まり、同じ契約条件の保険でも各社の保険料に大きな差が現れるようになりました。 2000年代になると、銀行での保険販売が開始、さらには通販やネットでの販売も現れるようになり、販売チャネルの多様化が進みます。 複雑性を増す営業活動とともに顧客ニーズの多様性も増している中で、保険業界は以下の課題に直面したのです。 1)環境の変化/市場ニーズの変化に対して、業務は柔軟かつ俊敏に対応できなければならない。 2)複雑化する業務において、実行されるプロセスやディシジョンは信頼性を担保しなければならない。 これら俊敏性と信頼性の要求に対して、ビジネス・ルールをアプリケーションのソースコードにハードコーディングした状態では対応が困難でした。 現実に一部の保険会社で、システムのルール変更対応の不備による保険金不払いという事故も発生しました。 情報システムが業務の変更要求に迅速に対応できないことは、競争力の低下に直結する状態だったのです。 【今後の適用はすべての業種へ】 BRMコンセプトおよびBRMSの導入が早かった保険業界の当時の状況は前述のとおりですが、他業界においても同様の状況が起こりつつあります。 TPPなど国際通商ルールの変更は待ったなしの状況であり、競争環境は今や地球規模の視野で考える必要が出てきたのです。 外的要因の要請(法規制、内部統制、コンプライアンス、地勢リスク) 規制ルールの変化とともに企業に求められる統制能力や法令遵守などは企業価値を大きく左右します。 リスク対応という意味でも、業務品質の信頼性、透明性の確保には確実に取り組む必要があります。 これまでのような属人的なオペレーション頼みの対応では潜在的なリスクを増大させるだけです。 競争環境から見た必要性(アジャイル経営) 激化する競争環境の中では、俊敏性がなければ生き残ることはできない時代となりました。 販売チャネルやバリュー・チェーンの複雑化によって、場当たり的な対応は困難になりました。 経営の舵取りに合わせて業務と情報システムが瞬時に反応しなければならない時代に突入したのです。 情報システムにとっては、定期改修のサイクルで変化を吸収していては、経営の要請に間に合わず、かと言って恒常的に改修を行えるリソースはありません。 となれば、今までのようなアーキテクチャでは対応困難となるのは必至です。

次の

デシジョンテーブルとは 「決定表」 (decision table):

ディシジョン テーブル

スポンサーリンク 多くの現場で作られている単体テスト仕様書はわかりにくい アサインされた現場にある単体テスト仕様書を見た時に、こういった疑問を感じたことはないですか?例えば、次のような条件を持つ機能を作ろうとしたとき、多くの現場では以下のような項目を持った単体テスト仕様書を作ることが多いでしょう。 会員には「ブロンズ会員」「シルバー会員」「ゴールド会員」の3種類のランクがある。 特別値引商品はシルバー会員とブロンズ会員だけが購入できる。 No 条件 期待値 1 ブロンズ会員が通常商品を購入する。 購入できること 2 シルバー会員が通常商品を購入する。 購入できること 3 ゴールド会員が通常商品を購入する。 購入できること 4 シルバー会員が特別値引商品を購入する。 購入できること 5 ゴールド会員が特別値引商品を購入する。 購入できること この単体テスト仕様書をみてどう思いますか?非常に見づらいですよね。 そして、この単体テスト仕様書では、テストすべき条件がすべて網羅されているかがパッと見てもわかりません。 ブロンズ会員がどのようなに動作すべきかがわかりませんし、「購入できない」ということが何を指しているのかも不明確です。 また、ここでは条件が「会員のランクが3種類」と「特別値引商品を購入できるか否か」の2つしかないので、上記のテストケースでもギリギリなんとかなるかもしれません。 ですが、ここにさらに以下のような条件だったらどうでしょうか?• ブロンズ会員は特別値引商品を参照することも購入することもできない。 シルバー会員は特別値引商品を参照はできるが購入はできない。 こうなると、テストケースの行が倍増してしまって、ますます条件を網羅した単体テスト仕様書を書くのが難しくなります。 さらに、テストケースを書くことが難しいだけでなく、テストを実施するときもテストケース全体を把握してから実施することが難しくなります。 単体テストで大切なのはテスト対象を漏らさないこと 単体テストで最も大切なことはテスト対象を漏らさないことです。 実装者がどんなに注意深く実装をしても、バグがないことはまずありません。 なので、そう言ったバグは単体テストや結合テストをはじめとしたテスト工程で検知する必要があります。 上記のような漏れのある単体テスト仕様書でテスト項目をすべて消化しても、その漏れたテストケースの部分にバグが含まれていた場合はそれを検知することはできません。 上記の例だと、もし漏れたテストケース部分にバグがあったとすると、次のような事象が発生します。 ブロンズ会員とシルバー会員が値引商品を購入できてしまう。 これで問題になるケースとしては、たとえば「値引商品はゴールド会員だけが購入できるプレミアの高い商品で、ゴールド会員になるには毎月1万円以上購入しないとなれない。 」といったような条件があったようなケースでしょう。 ゴールド会員からすると、このプレミアの高い商品を購入するために毎月1万円以上も払っているのに、それがブロンズ会員やシルバー会員でも買えていたとなると、非常に大きなクレームになります。 最悪の場合、 それが原因で退会してしまうという可能性もあります。 この内容のバグを直す場合、おそらくは数行の判定条件を変更するだけで済むでしょうし、リリースするまでに1日もかからないと思います。 でも、たったこれだけのことで 毎月見込まれていた売上や利益がなくなることもあるんです。 だからこそ、テスト対象を漏らさずに単体テストを行う必要があります。 マトリクスを作って漏れなく、ダブりなくケースを洗い出す テストの実施者は必ずしも機能仕様を把握してる人が行うわけでも、テスト仕様書を作った人が実施するわけでもありません。 まともに説明も受けずに単体テスト仕様書を渡されて実施するということも往々にしてあります。 そのため、パっと見て全体像が把握できて、どういうテストを実施するつもりなのかを理解できる必要があります。 では、どういうテストケースを書けば、すぐに全体が把握できるような単体テスト仕様書が書けるでしょうか? いちばん効果的なのは、以下のようにマトリクスにすることです。 会員区分と商品区分の取りうる値を行と列に書き出して、すべての組み合わせを視覚的に見えるようにすることです。 こうすることで考慮しなければいけないパターンをすべて洗い出すことができます。 今回は、参照と購入を商品区分の下においてマトリクスを作りましたが、これは特にルールがあるわけではありません。 自分の好みによって、参照と購入の区分を会員区分の下に置くこともできます。 テストケースを考えるときは、こうやってすべての条件を俯瞰できるように洗い出して整理することが大切です。 もし、単体テスト仕様書のフォーマットが決まっていて、上記のようなマトリクスで作ることができなかったとしても問題ありません。 こうやって整理した結果を、みなさんのプロジェクトで決められたフォーマットに落とし込むことで漏れのないテスト仕様書を作ることができます。 単体テスト仕様書をレビューしてもらう時に上記のマトリクスを添えてレビュー依頼を出せば、レビュアーからの評価は間違いなく上がります。 条件と期待値が複数ある場合はデシジョンテーブルが効果的 上記の会員ランクの例のようにしてテストケースを整理する方法もあるのですが、それでは表現が難しいことがあります。 たとえば、以下のような条件と期待値がそれぞれ複数あるようなケースです。 来店による割引と割引券による割引が同時に発生した場合は割引券による割引だけを適用する これをマトリクスで整理しようとすると、条件と期待値がそれぞれ複数存在するためにマトリクスが非常に大きくなってしまいます。 そういった時は以下のようなデシジョンテーブルを作ると全体がスッキリします。 条件部分をYesとNoで判断できる形で定義し、縦に並んでいる条件を組み合わせた期待値を期待値欄に書きます。 そうしないと、テストケースを網羅することができずに、実施すべき単体テストが漏れてしまうからです。 でも、5つくらいまでであればなんとか1つのデシジョンテーブルで表現できますが、それ以上になるとマトリクスが大きくなりすぎてテーブルを作ること自体が大変になってしまいますし、見通しも悪くなります。 そのため、もしマトリクスが大きくなりすぎるようであれば、デシジョンテーブルを複数に分割することを考えます。 上記の例であれば、「男性である」という条件を切り出して、「男性用のデシジョンテーブル」と「女性用のデシジョンテーブル」を作ることで、なるべく1つのデシジョンテーブルに含まれる条件を減らしようにします。 最後に 単体テスト仕様書を作るとき、その現場で過去に作られた単体テスト仕様書のサンプルをもらって何も考えずに作る人が非常に多いと思います。 むしろ、一次開発のときには炎上プロジェクトで、「なんでもいいから、とにかく終わらせろ!」みたいな方針で作られていることも十分にありえます。 また、最初の例のような箇条書きでテストケースを挙げてしまうと網羅していることがパっと見でわかりませんし、人によって表現方法がブレるのでテストケースが漏れていないかをチェックするのも一苦労です。 なので、過去のやり方にとらわれすぎずに、 テストケースを網羅するにはどうすれば良いかという観点でテストケースを整理することをおすすめします。 もし、単体テスト仕様書のフォーマットが絶対に変えられないのであれば、まずは上記のようなマトリクスやデシジョンテーブルの形でテストケースを整理した後に、それをプロジェクトのフォーマットの単体テスト仕様書に転記するようにしましょう。 そうすることで、単体テスト仕様書も実際に行う単体テストの品質も格段に上げることができます。 おまけ 上記で解説している内容、見る人が見ると「これ、単体テストじゃねーだろ。 」と言われます。 というのも、教科書的なお堅いところで定義されている単体テストは、「モジュール単位」や「メソッド単位」で行うものだと書かれているからです。 じゃあ、これが絶対にダメかというとそんなことはなくて、この切り口や粒度で十分というプロジェクトも多くあります。 それどころか、このレベルのテストさえできていないプロジェクトもかなり多いのが現実です。 私自身も本来的には単体テストなんだから、もっと粒度を細かくしてメソッド単位のレベルでテストをする方が望ましいとは思います。 でも、昨今のシステム開発の現場は、この単体テストが定義された頃のプロジェクトと比べて 大幅に短納期化し、 費用が大幅に削減されています。 また、システムによっては、多少の不具合があったとしても早くリリースしてマネタイズすることの方が重要だと割り切っている企業もあります(Webサービスを提供するベンチャー起業にその傾向は多いです)。 なので、「開発するシステムで求められている品質」や「クライアントやプロジェクトオーナーとの合意」、「お財布事情」といったことを考慮して、実施する単体テストの粒度をプロジェクトごとに決めること重要です。

次の

ソフトウェアの動作をデシジョンテーブルで視覚化する

ディシジョン テーブル

デシジョンテーブルとは デシジョンテーブルとは、決定表 JIS X 0125 [1]として規格が定義されています。 論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せます。 プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。 デシジョンテーブルの例(駐車場料金の割引計算) デシジョンテーブルを作成する手順は一般的に以下の通りです。 分析対象・テスト対象の持つ条件・原因を洗い出し、それぞれを行として追加します• 処理・動作・結果を洗い出し、それぞれ行として追加します• 起こりうる条件・原因の組合せを作成し、それぞれ列として追加します• 作成した列のうち、集約可能な列の組を圧縮します• 組合せの作成と圧縮についての検算をします デシジョンテーブルを使うことで以下のようなメリットが挙げられます。 (作成中) しかし、以下のような分析対象・テスト対象を扱う場合は注意が必要です。 (作成中) デシジョンテーブルの構成 デシジョンテーブルは以下のような要素で構成されています。 条件記述部(condition stub) 考慮すべき条件・原因を列挙する部分で、図2では「3000円以上10000円未満」「シネマ利用」などが該当します。 制限指定の場合は、記述した語句が真であるか偽であるかが明確になるように命題形式で記述するとわかりやすいです。 拡張指定の場合は、記述した語句が数値や複数選択肢を持つことが明確になるように変数形式で記述するとわかりやすいです。 原因結果グラフ技法で使われるデシジョンテーブルは、制約指定のように命題形式で記述します。 条件指定部• 動作記述部(action stub) 考慮すべき動作・結果を列挙する部分で、図3では「30分無料」「3時間30分無料」などが該当します。 制限指定の場合は、記述した語句が実施されるかされないか(真であるか偽であるか)が明確になるように命題形式で記述するとわかりやすいです。 拡張指定の場合は、記述した語句が実施される動作そのものや結果そのものを記述するとわかりやすいです。 原因結果グラフ技法で使われるデシジョンテーブルは、制約指定のように命題形式で記述します。 動作指定部• 条件指定部(condition entry) それぞれの条件・原因を特定の値・意味で指定し、ひとつのルールと関連付けをします。 条件指定部には表1のような書き方をします。 すべての条件・原因の値・意味が指定されるとひとつのルールが定められ、自動的に動作・結果が決定されます。 また、ひとつのルールは他のルールと一致しないように値・意味の組合せをとります。 JIS X 0125 では規定していませんが、列挙される条件・原因の順序が判定順序などの意味を持つ場合もあります。 ただし、原因結果グラフ技法で使われるデシジョンテーブルの場合は、順序に関するREQ制約などを用いて判定順序を表現し、特にCEGTestでは列挙される順序を論理点の検証順序として利用しています。 条件指定について 表記 ルールで関連付ける意味 CEGTest 表記 Y (Yes) この行に対応する条件・原因が真であることを意味します。 T、t N (No) この行に対応する条件・原因が偽であることを意味します。 F、f 値、語句など この行に対応する条件・原因が記述された値であったり、語句を満たすことを意味します。 — この行に対応する条件・原因が無関係であることを意味します。 また、特に他の条件・原因の組合せによってこの行に対応する条件が起こり得ないことを「 」で表記する場合もあります。 条件指定部• 動作指定部(action entry) それぞれの動作・結果を特定の値・意味で指定し、ひとつのルールと関連付けをします。 列挙される動作・結果の順序は、実行される動作(生じる結果)の順序を表現しています。 動作指定部には表2のような書き方をします。 もし、順序の異なる動作・結果がある場合には、必要な順序組合せの個数分だけ動作指定部を記述する必要があります。 動作指定について 表記 ルールで関連付ける意味 CEGTest 表記 X (eXecute) この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じることを意味します。 T、t — この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じないことを意味します。 F、f 値、語句など この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が記述された値であったり、語句を満たすことを意味します。 動作指定部 デシジョンテーブルの具体例 (作成中) 参考文献・引用文献 [1] , 日本規格協会.

次の