Facebook x

ジャンル

ソフトウェア開発・テスト用語
ソフトウェア開発・テスト用語 2024.03.22
x hatenabookmark

デシジョンテーブル(決定表)とは|概要・目的と作り方3ステップ

監修: 布施 昌弘

バルテス・ホールディングス株式会社 R&C部 副部長

デシジョンテーブル(決定表)とは|概要・目的と作り方3ステップ

ブラックボックステストで用いられるデシジョンテーブル(決定表)

ソフトウェアの動作条件は、複数の条件が組み合わさった場合の挙動が不明確になる場合があります。

デシジョンテーブルは、複雑な仕様に対して、条件の考慮漏れを防ぐために活用できるテストです。

今回は、デシジョンテーブルの概要・目的や作り方について解説していきます。

さらに、作る際のポイントや活用方法についても分かりやすくご紹介しますので、実際のテストにお役立てください。

デシジョンテーブルの基本の「き」

テスト技法「デシジョンテーブル」について解説しているミニ冊子です。技法の概要から使い方とポイントについて、初心者にもわかりやすく解説しております。

もくじ
  1. デシジョンテーブル(決定表)とは|概要と目的
    1. デシジョンテーブルとは
    2. デシジョンテーブルテストとは
  2. デシジョンテーブルの作り方3ステップ
  3. デシジョンテーブルを見やすくする3つの方法
    1. 矛盾している条件を削除する
    2. 表を簡略化する
    3. 表を分割する
  4. こんなに使える! デシジョンテーブルの活用術
  5. まとめ

1.デシジョンテーブル(決定表)とは|概要と目的

デシジョンテーブルの概要や目的、活用されるシーンについて解説します。

1-1 デシジョンテーブルとは

デシジョンテーブルは、想定され得るさまざまな条件(入力)と、その結果のソフトウェアの動作(出力)を洗い出し、表形式で整理したものです。

ソフトウェアの機能仕様を表すのに使用されます。

日本産業規格のJIS X 0125:1986では、「決定表」と規定されているため、「決定表」と呼ばれるケースもあります。

1-2 デシジョンテーブルテストとは

デシジョンテーブルを活用して、想定され得る入出力の組み合わせを規則ごとに実行するテストケースを設計するテストを「デシジョンテーブルテスト」といいます。

ソフトウェアの動作は複数の条件が組み合わさって決まることが多いので、条件の組合せに漏れがないかを確認する場合に有効なテストです。

例えば、タクシーの割増料金の仕様が、以下のように定義されていたとします。

  • 月曜~金曜は通常料金、土日および祝祭日は割増料金

  • 7:00~21:59は通常料金、それ以外(深夜・早朝)は割増

これをデシジョンテーブルの形で表すと、以下のようになります。

hyou1.png

★記号の説明

条件

Y:その条件に該当する。真(True)※Tや1と記述することもある

N:その条件に該当しない。偽(False)※Nや0と記述することもある

-:条件が動作に影響しない ※N/Aと記述することもある

動作

X:その動作を行う ※YやT、1、○などと記述することもある

-:その動作を行わない ※N、F、0、空白などと記述することもある

このように、デシジョンテーブルを用いると、曜日と時間という条件の組み合わせごとに、料金が通常料金なのか割増料金なのかが明確に分かるようになります。

2.デシジョンテーブルの作り方3ステップ

デシジョンテーブルの構造を整理すると、以下のようになります。

デシジョンテーブル表2.png

デシジョンテーブルは、一般的には以下の手順を踏んで作成します。

ステップ1.条件とアクションをまとめる

まずは分析対象のシステムで起こりうる条件とアクションを抜き出していきます。

アクションとは、条件の組合せによって発生する動作結果のことです。

条件を「条件記述部」に、取りうるアクションを「動作記述部」に記入します。

ステップ1.png

例:タクシーの割増料金の仕様の場合

・月曜~金曜は通常料金、土日および祝祭日は割増料金

・7:00~21:59は通常料金、それ以外(深夜・早朝)は割増

条件:平日、7:00~21:59 →条件記述部に記入

動作(アクション):通常料金・割増料金 →動作記述部に記入

ステップ2.条件の組み合わせを記入する

続いて、条件指定部とルールを記入していきます。

ステップ2.png

上記の例のように条件が2つの場合は、22条でルールは全部で4つになるので、4列に記入していきます。

★条件組合せパターンの記入法則にのっとって条件指定部に「Y(Yes)」・「N(No)」を記入しましょう。※「T(True)」「F (False)」の場合もあります。

★条件組合せパターンの記入法則

スクリーンショット 2022-11-14 135110.png

条件の1行目は左半分に「Y」、右半分に「N」を記入。

条件の2行目は表の4分の1に「Y」、同じ長さで「N」を交互に記入。

条件の3行目は表の8分の1に「Y 」、同じ長さで「N」を交互に記入。

条件の4行目は表の16文の1に・・・

と記入していく。

ステップ3.動作指定部を記入する

ステップ2で記入した条件の組み合わせに対応して、どのようなアクションが起きるかを「動作指定部」に記入します。

ステップ3.png

ルール列を縦に見ながら「期待される結果」を「X:その動作を行う」「-:その動作を行わない」「N/(実現不可能)」等で記入していきます。

3.デシジョンテーブルを見やすくする3つの方法

デシジョンテーブルの目的の一つは「複雑な仕様を分かりやすく整理すること」です。

そのため、デジションテーブルが大きくなったら見やすくなるように工夫が必要になります。

デシジョンテーブルを見やすくする方法を3つご紹介します。

3-1 矛盾している条件を削除する

デシジョンテーブルを作成し、論理的に矛盾している条件の組み合わせが生じた場合、その条件を削除することで、テーブルの項目を減らすことができます。

例えば、ある携帯電話事業者は子供・シニア割引を実施しており、15歳以下または60歳以上の利用者には割引料金が適用されるとします。

このとき「15歳以下」「60歳以上」を条件、「割引料金が適用」をアクションとして、デシジョンテーブルを作成した場合、「15歳以下」「60歳以上」がともにYというケースはあり得ないため、この条件を省くことができます。

hyou3.png

3-2 表を簡略化する

デシジョンテーブルを見やすくするために、複数のルールをまとめて簡略化を図ることもできます。

例えば、ある遊園地ではゴーカートに乗るためには小学校3年生以上かつ身長140cm以上でなければならないという規則を設けているとします。

「小学校3年生以上」「身長140cm以上」を条件、「ゴーカート乗車」をアクションとして、デシジョンテーブルを作成した場合、

「小学校3年生以上」がN、「身長140cm以上」がY、「ゴーカート乗車」がNというルールと、

「小学校3年生以上」がN、「身長140cm以上」がN、「ゴーカート乗車」がNというルールを、

「小学校3年生以上」がN、「身長140cm以上」が「-」(Y/Nの意味)、「ゴーカート乗車」がNという1つのルールにまとめることができます。

hyou4.png

3-3 表を分割する

他の条件との関連性が低い条件(独立性の高い条件)がある場合、表の分割が効果的です。

元の表から独立性の高い条件を除いて作成した表と、独立性の高い条件のみで作成した表の2つに分割することによって、表が見やすくなります。

4.こんなに使える! デシジョンテーブルの活用術

【活用法1】発見した欠陥の原因を分析する

デシジョンテーブルテストを実施して欠陥が見つかった場合、その欠陥が発生する条件と類似の条件をデシジョンテーブルから探し出し、その差異を調べて欠陥のありそうな条件を特定できます。

条件とアクションの関係性が表に整理されていることで、不具合結果の出方からシステムのどのあたりに問題があるのかあたりをつけやすくなり、不具合の検知スピードや確実性が上がるというメリットがあります。

【活用法2】仕様の抜け漏れ・曖昧な箇所を見つける

8607-00013-03

ソフトウェアを動作させずに開発仕様書に誤りや不備がないことを確認することを静的テストと呼びますが、デシジョンテーブルはこの静的テストで活用できます。

デシジョンテーブルで条件の組み合わせを全て洗い出し、個々に期待されるアクションを割り振る作業をする中で、「この条件ではどのようにアクションすべきか、仕様書に書かれていない、又は曖昧である」箇所を見つけ出すことが可能です。

仕様に定義漏れや曖昧な箇所があれば、それは不具合に直結します。

このような不具合を、仕様定義や設計段階といったテスト実施前に見つけ出して対処することで、結果的にテストで見つけられるバグは少なくなり、テストの実施効率向上・テスト時間圧縮・品質の安定化に繋げることができます。

まとめ

デシジョンテーブルは、想定され得るさまざまな条件(入力)と、その結果のソフトウェアの動作(出力)を洗い出し、表形式で整理したものです。複雑な条件を整理してテスト漏れを予防したり、不具合の原因箇所を特定したりすることに役立ちます。

システムの品質向上やテストスケジュールの遅延を防ぐためにも、デシジョンテーブルを活用してみてはいかがでしょうか。

ソフトウェア開発・テスト用語
x hatenabookmark

監修: 布施 昌弘

バルテス・ホールディングス株式会社 R&C部 副部長

様々なテスト対象(組込み系、Web 系、金融系)の現場でテスト設計、テスト管理などを行う。現在は社内外のテスト関連教育セミナーの講師とコンテンツ制作、コンサルティングを担当する。JSTQB 認定 Advanced Level テストマネージャ。 著書は、『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』、『いちばんやさしいソフトウェアテストの本』。