今さら聞けないQA技術：MBT（第1回）

SysML EA テストケース自動生成モデルベースドテスト MBT

MBTとは

「モデルベースドテスト」（Model-Based Testing：以下、MBT）は、モデルをテストに使う有用なテストアプローチです。MBTは同値分割、境界値分析やデシジョンテーブルなどの従来から使われているテスト設計技法を拡張・支援します。

基本的にMBTは、テスト設計活動およびテスト実装活動の品質と効率を改善するために使われます。テストケースを自動的に生成するのに十分な情報を含み、かつ形式的または準形式的なMBTモデルをテスト設計仕様として作成します[1]。

簡単に言うと、MBTはモデルを入力してテスト設計を自動化できる技術です（図表1）。一方で、上記の定義に照らして、自動的にテストケースを生成するのに必要な情報を含み、かつ十分形式的なMBTモデルから、手動でテストケースを生成したとしても、それはMBTと言えます。手動でテストケースを生成する意味はないように思われますが、現場では自動でテストケースを生成するためのツールをリードタイムやコストの問題で開発できなかったり、複数のモデルを入力としてテストケースを設計したりする場合に、手動のMBTが採用されることがあります。

世の中で使われている「MBT」という言葉の意味には、微妙に差異があります。発展途上の分野であるため、いずれの定義が正しい、間違っているわけではありません。ただし、どんな意味であるかは理解した上で解釈をする必要があるでしょう。主な差異が発生する点は以下です。

テストプロセス：テスト設計のみか、テスト分析の一部を含むか。また、テスト実装やテスト実行を含むか
自動化の有無
モデルの形式度合い：自然言語をモデルに含むか、など

本稿では、MBTは「モデルを使ったテスト設計で、必ずしも自動化されている必要はない。また、モデルには必要なテストケースを生成するために十分な形式度合いが確保されていればよい」という立場を取ります。

MBTに使われるモデル

では、MBTにはどんなモデルが使われるのでしょうか。

一般的には、「構造的」または「振る舞い」、あるいはそれらの組み合わせです。構造的なモデルの代表例は、クラス図、インターフェース図、データモデリングのためのクラシフィケーションツリーが挙げられます。振る舞いモデルは、アクティビティ図やビジネスプロセスモデル、状態遷移図が代表的です[2]。

筆者が経験するほとんどの現場では、いずれかのモデルのみで完結することはなく、一部であるとしても両モデルを組み合わせてMBTを実現しています。それは、たとえ振る舞いを確認することがテスト目的で、アクティビティ図からテストケースに使われるパスを生成したとしても、その中で使われるデータ抽出のためにはデータモデル等が必要になるからです。

実際にモデルを記述する際には、通常、モデリング言語が使われます（言語でないケースもあります）。モデリング言語は、モデリングのコンセプト、形式度合い、表現形式を考慮して、目的に応じて選定すべきでしょう[3]。代表的なものはUML、SysML、UTP、BPMNなどです。また、それぞれの言語を実装するプログラミング言語やツールもいくつか公開されていて、PlantUMLやmermaidがよく使われています（図表2）。

自然言語で書かれた要件一覧はMBTにおけるモデルとみなせるのか、という疑問がしばしば寄せられます。 JaSST「モデルベースドテスト入門」[4]では、機能一覧表も立派なモデルである、との記述があります。筆者も同じ意見で、自然言語で書かれた要件一覧は（特定のテストの目的を設定すれば）モデルであると解釈できると考えます。

特定のテストの目的を設定すれば、と条件を付けましたが、それはどのモデルでも同じことです。特定のテストの目的を達成するために、モデルの形式度合いと必要な情報が定まると言えます。例えば、テスト目的を「要件一覧のそれぞれに対応するテストケースを作る」と設定した場合、自然言語で書かれた要件一覧をモデルとして入力し（図表3）、そのまま同数のテストケースを生成すれば（図表4）、自動化可能なテスト設計となります。当然、テストケースに自然言語が含まれるため、その後のテスト実装以降を自動化することは、そのままでは難しいです。しかし、テスト設計を自動化可能にしているという意味では、MBTだと考えられます。

MBTを使うメリット

CT-MBT （Certified Tester Model-Based Tester）シラバスによると、MBTには以下のようなメリットが挙げられています。

モデリングによりステークホルダー同士のコミュニケーションが改善される
テストにより問題を見つけやすいシステムの部分を、MBTモデルにより特定しやすくなる
実際のシステムが作られるより前にテストケースの生成や分析が可能になる
開発プロセスの初期に発生する欠陥を取り除ける
自動化を支援し、手動作業によるミスを防げる
単一のメンテナンスポイントを提供し、要件変更時のメンテナンスコストを下げる

これらのメリットは、モデリングそのものが持つメリットも含まれているため、純粋にMBTならではのメリットであるかは考慮が必要です。また、これらのメリットを大まかに分類すると、以下の通りです。

シフトレフト
自動化による成果物品質の向上
単純作業の機械化による効率化

一般的にいわれるメリットは上記の通りですが、筆者の所属する組織では別の理由でMBTを推進しています。それは、「テストプロセスの整流化」です。

職人技であり、形式知化されていなかったテストプロセスをMBTによって機械化可能にし、機械化に必要な知識をあぶりだすことを目的にしています。その知識とは、テスト対象が持つ性質に応じてどんなテストを作るかという知識であり、それを「MBTパターン」と呼んでいます。

テスト対象がどんな性質を持っているのかはMBTモデルにより記述されます。従って、MBTモデルがあれば、MBTパターンを適用することでテストケースが生成できます。

広く一般的に知られる「テスト設計技法」は、MBTパターンの代表と言えます。しかし、実際の現場ではテスト設計技法だけでテスト設計が完結することはほとんどなく、より複雑なテストケースの生成を行っています。これは、現場で独自のテスト設計技法を定義していることに他ならないです。筆者の組織ではそれをMBTパターンと識別し、組織的に使える“テーラリングした”テスト設計技法を収集することで、組織としてのテストケース生成ロジックを蓄積しようとしている、ということになります。

「テストプロセスのDX」を目指す

ここまでMBTの基本的な解説をしてきました。本稿の最後に、筆者の組織がMBTをどのように利用しようとしているかを紹介します。それは、ありふれた言葉になってしまいますが、「テストプロセスのDX」です。

MBTを導入することで、テスト開発プロセスの中心であるテスト設計プロセスが機械化されます。それによってテスト設計に入力されるデータ、テスト設計から出力される後プロセスのデータが蓄積可能になります。例えば、それぞれのMBTパターンにひも付く欠陥がどの程度発生したか、あるテスト対象にはどのMBTパターンが適用されやすいか、といったデータです。これらは従来、ベテランのテストエンジニアが経験ベースで行っていた作業です。それを一部機械によって代替可能になると考えています。

これまで蓄積してきた経験を基に、さらなる付加価値を提供するための礎となるのがMBTだと確信しています。