身近な制度からテスト設計を考えてみた(資格制度、デシジョンテーブル編)

テスト設計って面白いけど、どうやって勉強してみたらよいんだろう?そんなことを考えてみたら、身近にたくさん練習しがいのある議題があると気づきました。そこで、資格補助の制度についてデシジョンテーブルという技法を使ってテストケースを考えてみました。
2023.12.25

こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉(@bun76235104)です。

アジャイル開発では特に、開発者のロールの方がユニットテスト・統合テストくらいまで書くことが多いですよね。

また、QAエンジニアのような品質やテストに習熟したロールの方がチームに存在しないということもざらにあるのではないでしょうか?

私も開発寄りではあるものの、JSTQBという認定試験を受験したり、テスト技法について学習したりしています。(個人としてテスト担当者・QAエンジニアといったロールであったことはありません)

そんな中、テスト設計ってどうやって自力で学習すればよいんだろう?と考えていた所、以下のブログを発見し、身近にはテストの題材となるものが山程あることに気づきました。

そこで、今回はクラスメソッドの資格補助の制度について、外からわかる情報だけで推測し、テストケースを作成してみることにしました。

デシジョンテーブルを知らない方や、テストケースはセンスで書いている人には何らか気づきがあるかもしれませんので、興味があれば見てください。

なお、繰り返しにはなりますが、今回記載する内容は資格補助の制度を正しく広めることを目的とはしていないので、「外部からわかる情報」を根拠にテスト設計しています。

外部情報から読み取る資格制度の仕様について

ここから外部の情報を参考に制度の背景などを考えています。

長いので、さくっと前提条件を見たい方は飛ばされて構いません。

制度の背景や前提条件を考えてみる部分。長いので折りたたんでいます。

クラスメソッドといえば、やたら資格試験に合格している人が多いイメージですが、福利厚生のページを見てみると「資格取得支援」の教育制度があるようです。

また、「クラスメソッド 資格取得支援」の検索でヒットした、2020年のクラスメソッド人事ブログを見てみると、以下のように記載があります。

会社で定める資格について、取得のための費用を補助させていただいています。 クラスメソッドではAWS関連資格だけでも取得数900を突破しており、多くの方がこの制度を活用しています。

会社で定める資格について補助がある というのがポイントになりそうですね。

以下のブログでは「サウナ・スパプロフェッショナル」の資格を取得しても、自腹である旨が記載されています。

当然趣味資格に費用負担は無いので自腹です

さらに以下のブログ中の資料では、「AWS認定資格費用、合否に関わらず全額負担」と記載されています。

もう少し制度の目的や背景を深掘ってみる

さて、以下のようなことがなんとなくわかってきました。

  • 資格取得の支援がある
  • 会社で定める資格について補助がある
    • 趣味の資格は補助がでない
  • AWS認定資格費用は合否に関わらず全額負担っぽい

クラスメソッドといえば、AWSのイメージが強いと思います。

会社概要にも「AWS」という文字が出てくるため、力を入れている領域なのだろうと推測できますね。

一方で、以下のブログにはこのような記載があります。

昔からクラスメソッドにはAWS認定資格の受験費用を会社が負担してくれる制度があったのですが、1年と少し前からAzureとGCPの試験についても会社が費用を負担してくれるようになりました

このあたりが「会社が定める資格」に該当するのかもしれません。

しかし、どうしてそもそも資格について補助を出しているのでしょうか?

得てして制度というものは、ミッション・ビジョンや企業文化のようなものから作られているものが多いと思います。

そこで、公式サイトを調べてみると以下のようにCLPと呼ばれるカルチャーがあることがわかります。

このあたりを見てみると、「プロフェッショナル」や「やってみる」「楽しむ」のあたりが、資格取得について絡んでいるようにも見えます。

このあたりから制度に込められた思いや背景を推察してみると、以下のようなことが私の中で浮かび上がってきました。

  • 「AWS認定資格だから」ではなく、会社として「プロフェッショナル」や「やってみる」などのカルチャーの体現をしようとしている人はできるだけ補助してあげたいという考えがあるのかも
  • さらに、その中でも「特に会社としても取得を応援したい資格試験」については、合否に関わらず費用を負担しているのかな?

本来の開発チームであれば、制度や機能に込められた背景について深掘り、実際の例による仕様の明確化などをしていきたいところですが、今回はこれら推測をもとにテストケースを考えていこうと思います。

仕様を整理

さて、長くなりましたが、資格補助の制度について条件と、判定結果(動作)についてまとめると以下のような形になると思います。

  • 条件
    • 会社の定める資格であるか
      • 便宜的に「推奨資格」と命名します
    • 特に会社として取得を応援する資格であるか?
      • AWS認定資格のように合否に関わらず費用を負担してくれるっぽいもの
      • 便宜的に「特別応援資格」と命名します
    • 合格したか?
  • 動作(結果)
    • 自腹
    • 会社負担

この他にも「事前に申請したか?」などの条件があるかもしれませんが、今回は上のような条件と動作であると仮定して考えてみます。

このように条件や動作が複数存在して、条件によって動作が変わる機能の場合、デシジョンテーブルというのがテスト設計に役立つと思います。

実際にどんなものか見ていきましょう。

なお、今回はデシジョンテーブルやテストケース作成にあたってGIHOZというサービスを利用させていただいています。

デシジョンテーブルで整理してみる

実際に見てみると「あ。これか。」となるかもしれませんが、与えられた条件をもとにデシジョンテーブルを作成してみました。

20231225_sikaku_decision_1

デシジョンテーブルとはなにか?というものは、以下のサイトがわかりやすいと思います。

以下のように条件をまとめている部分を「条件記述部」、動作をまとめている部分を「動作記述部」と表現します。

20231225_sikaku_decision_table2

条件記述部の「Y」はその条件が該当していること、「N」は非該当であることを意味しています。

動作部の「X」はその動作が発生することを意味しています。

また、上の「1」「2」のような数値で表されている列を「ルール」と表現します。

このように表現すると、3つの条件に対してどのような動作となるべきか、分かりやすく整理できますね。

しかしながら、さっと作ってみたのはよいものの、いくつか疑問が湧いてきます。

疑問1:特別応募資格と推奨資格の関係性

私の感覚では「推奨資格」の中に「特別応援資格」というものが含まれている気がします。(会社が定める資格の内、「特に」なものを合否に関わらず全額を負担するような気がしています)

20231225_sikaku_benz_diagram1

そうなってくると、「推奨資格ではないが特別応援資格である」というルールは成り立たないかもしれません。

20231225_sikaku_desicion_table_1_2

となれば、以下のようにデシジョンテーブルを書き直してしまってもよいのかもしれません。

20231225_sikaku_desicion_table_2

上のデシジョンテーブルは「推奨資格ではないが特別応援資格である」というルールを除外したものです。

疑問2:判定ロジック(判定順序は?)

「全額会社負担」という判定をしているプログラムはどのような実装になっているのでしょうか?

もし、以下のような流れで判定するとしましょう。

20231225_sikaku_flow

すると、動作に影響を与えない部分を「-」とすると以下のように整理できるかもしれません。

20231225_sikaku_decision_table_3

テストケースを作成してみる

上で疑問が湧いたように、設計やユーザーストーリ作成時に具体例などを用いてコミュニケーションができていれば、簡単化したデシジョンテーブルからテストケースを作成できたかもしれませんが、今回の仕様は私が外に出ていた情報から勝手に推測しただけのものです。

そのため、勝手に簡単化できないと判断して最初に表示したこの図からテストケースを出力します。

20231225_sikaku_decision_1

出力したテストケースはこちらになります。

20231225_sikaku_testcase

こちらもGIHOZでテストケースを出力してくれて非常に便利です。

今回は出力したテストケースをそのまま記載していますが、例えば7はいわゆる趣味資格に該当すると考えられます。

このような実例とテストケースを追跡できるように紐づけたりすることも非常に有効だと思います。

なお、設計やユーザーストーリ作成時などの早い段階でテスト設計につながるような活動は、テストのシフトレフトなどと呼ばれたりします。(今回で言えば、ユーザーストーリや仕様の設計段階からテスト担当者も参加してバグをその時点で潰したりすることなど)

DevOpsなどの文脈で使用されがちな言葉ですが、私的には「アジャイルソフトウェア開発宣言」で記載されているような、「個人と対話」や「顧客との強調」などの部分にも当てはまるのではないかと考えています。

コミュニケーションとコラボレーションを大事したいですね。

と、余計なことを言いながらも、こんな形で仕様を整理しつつ、テストケースまで一通り作成することができました。

まとめ

  • 複数の条件、複数の動作が関わる機能のテストにはデシジョンテーブルが使えるかもしれません
  • デシジョンテーブルを作成しても「無駄なルールがないか?」「矛盾する条件はないか?」ということを考えるのは大事
    • 目的はツールでデシジョンテーブルを作ることではなく、「コストを少なく有用なテストを書く」「気づきをチームに与える」といったことのはず

以上、外部に出ている情報だけから資格支援の制度について、想像をはせてみました。

最後までご覧いただきましてありがとうございました。