はじめに

複雑な仕様を整理する。テスト担当者の仕事の1つはこれです。

ソフトウェアが仕様通りに動くかどうかを確かめるのがテストの役目です。ですが、複雑な条件が絡み合った仕様をテストする場合には、まず仕様を把握し、理解しなければなりません。これがなかなか骨の折れる作業です。

もちろん、この悩みはテスト担当者に限ったことではなく、開発設計者にとっても同じように悩ましい問題でしょう。次から次へとクライアントから降ってくる、追加の要求を、すっきりと仕様に整理して、不具合のないシステムを作ることは決して簡単な仕事ではありません。

とりわけ、やってくる要求は既存のシステムの仕様とは無関係にやってきます。追加の仕様を設計、実装する際には、既存の仕様と整合性をとらなくてはなりません。「⁠とりあえず⁠」⁠、で修正してみたものの、テストをしてみると、不具合が発覚。再度修正したら今度は別のところで不具合が発生…。こんな経験はないでしょうか。

そんなとき、仕様の整理にデシジョンテーブルを使ってみませんか。

これが今回のテーマです。

デシジョンテーブルを作成する

テスト担当者としてお客様と接していると、「⁠デシジョンテーブルを作ってますか？」という質問に「はい」と答える開発設計者の方は、前回このコラムで取り上げた「状態遷移図、表」に比べても、決して多いとは言えないようです。テスト担当者でも、決して多いとは言えないかもしれません。名前は聞いたことがあるけれど、どのように使ったらいいのか、よくわからない、という答えが多いようです。

そこで今回は、デシジョンテーブルを使った仕様の整理方法の一例をご紹介したいと思います。

デシジョンテーブルとはさまざまな条件（入力）に対して、どのようにソフトウェアが動作（出力）するのかを決定する表のことです。…と言っても文章ではわかりにくいので、例を見ていきましょう。

ここでは、健康ランドの精算システムにおける「割引サービス」に関する仕様を例にして、皆さんと一緒に考えていきましょう。ではさっそくデシジョンテーブルを使って仕様を整理してみましょう。

今回「土日祝ジュニア割引」が新たな新企画の割引サービスとして、仕様に追加されました。

こうしたキャンペーンにおける割引サービスなどの仕様の追加は、そのつど営業の企画として上がってくることが多く、既存のサービスとの整合性はあまり考慮されずに、そのまま「追加仕様」として持ち込まれる傾向があります。ですから、これまでの割引サービスの仕様と、追加された新しい仕様を、整理する必要があります。

割引の条件が追加されたことによって、当然、条件の組み合わせによる、割引率の設定も、追加前より複雑になります。これが未整理ですと、後々トラブルの種になりかねません。テストで仕様の不備や不具合が発見できればいいですが、修正の手戻りで工数がかさんでしまいがちです。できるだけ、上流工程で整理しておいたほうがよいでしょう。

まず、仕様が追加される前の割引サービスの仕様をデシジョンテーブルで表してみましょう。

デシジョンテーブルでは、基本として、まず、「⁠条件」の部分に「Y」と「N」の組み合わせをすべて書き出します。

まず「ルール1」を見てみましょう。3つの条件が全て「Y」ですね。この場合、クーポン持参割引10％と、平日シニア割引50％の条件に該当します。割引率が高いほうが優先されます。「⁠適用割引」の部分の「50％OFF」のところに「Y」を記入し、それ以外には「－」を記入します。

このようにして、すべての条件の組み合わせを、見通し良く整理することができるのがデシジョンテーブルです。文字で書かれた仕様よりもデシジョンテーブルで表現することにより、随分すっきりしました。

では、「⁠土日祝ジュニア割引」の仕様を追加した場合はどうなるでしょうか。やはり、この場合もデシジョンテーブルで表してみましょう。まず、条件部に「15歳以下」が追加されたので、条件の組み合わせをすべて書き出します。

ではまた改めて「ルール1」を見てみましょう。4つの条件が全て「Y」です。ここで、「⁠あれ？」と手が止まります。「⁠15歳以下」と「65歳以上」が同時に「Y」となることはあり得ないからです。

この場合、このルール1は「あり得ない組み合わせ」として処理されるよう、適用割引の部分にすべて「N/A」と記入します（同じ理由でルール5、ルール9、ルール13も「N/A」となります⁠）⁠。

このようにデシジョンテーブルで表すことにより、仕様に含まれるあり得ない組み合わせに気が付きやすくなるという効果が期待できます。

クライアントとの打ち合わせなどでも、受け取った要求をこうしたデシジョンテーブルで表現してお互いに確認を取ることで、後の工程における修正や手戻りをより少なくすることが期待できます。また、プログラムの実装時においてもミスを減らせますし、テスト担当者も仕様をイメージしやすくなります。さらにそのデシジョンテーブルを利用して、テストケースに展開することも容易になります。

以上、ごく簡単なケースで説明しましたが、このように上流工程でデシジョンテーブルを作っておけば、開発に携わる多くのステークホルダーと仕様の認識を合わせることができます。「⁠すでに作っているよ」という方もいらっしゃると思いますが、まだデシジョンテーブルを作ったことが無い方で、本稿を読んで、少しでも、仕様の整理に使えそうだ、と思われたら、是非、一度試していただければと思います。

さいごに

5回にわたってお贈りしてきた、この『上流工程に効く、「⁠テストの考え方⁠」⁠』も今回で、無事、最終回を迎えることができました。最後までお読みいただき、ありがとうございました。この場を借りてお礼申し上げます。

皆様の日々の業務の改善に、ひとつでもお役にたてれば望外の喜びです。またどこかでお会いしましょう。