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

前回の記事では、モデルベースドテスト（Model-Based Testing：以下、MBT）の概要や利点などを紹介しました。今回はMBT活動について、もう少し深く考察します。

ISTQBのシラバス[1] では、従来のテスト分析・設計で通常行われないMBT特有の活動として以下の点を挙げています。

• MBTモデリング活動
• MBTアプローチと選択基準に基づいたテストウェアの生成

本稿では「MBTモデリング活動」に焦点を当て、具体的にどのようなことを行うのか、どのような点に注意する必要があるのか、どのようなことが課題になってくるのかなどを説明します。

前回の記事でも触れた通り、MBTモデルはさまざまな表現形式のモデルを使用することが可能です。

構造的なモデルとして「クラス図」や「インターフェース図」、データモデルとして「クラシフィケーションツリー」、振る舞い的なモデルとして「アクティビティ図」や「ビジネスプロセスモデル」「状態遷移図」などです（図表1）。

また、それらを表現する言語にはUML、SysML、UTP、BPMNなどがあります。そのため、モデリングをするにはまず、MBTモデルを何によって記述するかを決める必要があります。

では、どのような視点で決めていくと良いでしょうか。実際にはさまざまな視点があると思いますが、筆者が経験したケースとして3点紹介します。

1点目は、開発側が作成したモデルと一致させるケースです（図表2）。

例えば、開発側でSysMLによるステートマシン図（状態遷移図）を作成していたとします。このステートマシン図をMBTのテストベースとして流用可能と判断した場合に、MBTモデルもSysMLのステートマシン図で作成すると決めるというものです。これは判断として容易なケースに当たります（開発のモデルとMBTモデルの異なる点については後述します）。

2点目は、プロジェクトの制約から判断するケースです（図表3）。

引用元：ISTQB® Foundation Level Certified Model-Based TesterSyllabus Version 2015

例えば、モデリングツール、MBTツールがUMLのアクティビティ図のみをサポートしていたとします。この制約を考慮してMBTモデルをUMLのアクティビティ図で作成すると決めるというものです。

別の方法では、プロジェクトメンバーのスキルを考慮して決めることもあります。例えば、テスト設計者やプロジェクトリーダーにモデルの知見があまりなく、UMLの状態遷移図であれば理解できる状況だった場合に、MBTモデルをUMLの状態遷移図で作成します。取りあえずMBTを試してみるという段階では使いやすい視点ですが、制約に依存してしまっているため最適な表現方法とは言えません。

3点目は、作りたいテストから判断するケースです。

例えば、ロジックと処理の流れの正しさをテストしたいからMBTモデルにアクティビティ図を使ったり、さまざまなデータやパラメータの組み合わせをテストしたいからMBTモデルにクラシフィケーションツリーを選択したりする方法です。これは従来のテスト設計においてテスト設計技法を選択する場面と似ています。テスト設計技法を選ぶのが難しいという話はよく聞きますし、MBTでもモデルを選ぶことは難しく、苦労すると感じています。ここをうまくサポートできるかどうかがMBTにおけるハードルだと筆者は認識しています。

MBTモデルの記述形式が決まった後は、MBTモデルの記述を開始します。以下では記述する際に意識すべき点を紹介します。

大前提として、開発モデルが流用できるかどうかでMBTモデリングの作業内容は変わってきます。流用できない場合でも自然言語の仕様書の内容をいったんモデルに変換し、開発のモデルを作り出していると考えることで、MBTモデリングとして意識できるようになります。ただ、ここでは開発モデルの流用可否は区別しないでおきます。

さて、MBTモデルを記述するに当たって意識することですが、そもそもなぜモデルで表現したいのかを振り返ってみると、それは、テスト設計仕様を形式的に表現したいからです。そのためには、独自な表現を含めないようにMBTモデルを記述することが求められます。これを実現するには以下の優先度でMBTモデルを記述する必要があると考えています。

（1）UML/SysMLなどの標準記法を適切に使用する

（2）モデリングツールの機能を適切に使用する

（3）MBTツールに従った記述にする

（1）は、既に公開され、標準とされている記法を使用することを最優先に意識します。当然と言えばその通りなのですが、知らなかったり、見逃していたりする書き方があるかもしれません。例えば、UMLの状態遷移図であれば、履歴状態、内部遷移を表現する方法が決められています（図表4）。この点を意識することで、ステークホルダー間でモデルに対する共通認識を持ちやすくなりますし、MBTモデルも再利用性や可読性、保守性を高めることにつながります。

続いて、（2）についてです。これは、モデル要素の属性や関連性を定義できる機能等のことです。例えば、商用のモデリングツールである「Enterprise Architect」では、拡張要素として「時系列チャート」や「表要素」などを使用できたり、状態遷移のトリガとして「シグナル」や「時間」などの種類を選択できたりします。これらの機能を使うことにより、MBTモデルをよりシンプルに表現できたり、他のモデルとの関連性、トレーサビリティーを高められたりします。

ここまではMBTモデルと開発モデル共通の内容でした。

最後に、（3）についてはMBTモデル固有の内容が含まれます。MBTツールに従った記述を検討するわけですが、MBTツールはMBTモデルに基づいてテストケースを生成するため、実現可能な情報を明示的にMBTモデルに盛り込む必要があります。それにより、テストケースで指定される条件が導出可能になります。

例えば、状態遷移図からある状態にて同時にトリガ（イベント）が発生するテストケースを作るとします（図表5）。このとき同時に発生するトリガの組み合わせを生成、導出する必要がありますので、そのトリガが識別可能になるようにMBTモデルに情報を盛り込みます。

具体的には、該当のトリガにフラグを付与するなどです。また、テストケースには前提条件、期待動作などの情報も必要になりますので、これらも導出できるようにしておきます。特に期待動作は開発モデルや仕様書から変換したモデルでは明示的になっていない場合があるため、テストとして確認したい振る舞いもMBTモデルに盛り込みます。

一例を挙げると、状態遷移において、遷移できない時のエラーポップアップ表示を期待動作としてテストしたい場合、その振る舞いを状態遷移図に盛り込みます（図表6）。このような暗黙的な仕様もMBTモデルに盛り込むことが大事です。また、この情報は開発モデルにも反映した方が良い場合もあります。

この3つ以外にも、テストチームやプロジェクト内で定義した記述ルールに従う必要があるかもしれません。いずれにしても、これらの記述ルール、モデリングの注意点はモデリングガイドラインによって明確化する必要があります。これにより関係者間の認識ズレを防ぐことが期待できます。

MBTモデルの品質は生成される成果物、つまりテストケースに直接影響してきます。そのため、MBTツールに従った記述以外にも意識した方がいいことがあります。例えば、以下です。

• 理解しやすいMBTモデルかどうか
• MBTモデルを変更しやすいかどうか
• MBTモデルを再利用しやすいかどうか

従来のテスト設計においてテスト設計仕様書をレビューするように、MBTでもMBTモデルのレビューが不可欠です（図表7）。記述ルール違反、必要な情報の欠落などは、MBTツールなどにより機械的なチェックでカバーできます。一方でMBTモデルが妥当な内容なのかは人間によるレビューが必要です。その際、理解しやすいMBTモデルであるかは重要な点です。

注意点を4点挙げます。

1点目は、テストの目的に対して適切な抽象度でMBTモデルを表現することです。例えば、ユーザーが認識可能なレベルの状態を使用した状態遷移図（高い抽象度）では、内部状態まで意識した詳細な遷移動作を確認するテストケースは生成できません。また、内部状態まで考慮して表現した状態遷移図（低い抽象度）では、システムテストにとっては必要以上に詳細な遷移動作を確認するテストケースが生成されることもあります。この点に気を付け、生成したいテストケースに対して抽象度を一致させることが大事になります。

2点目は、無理に1つのモデルでさまざまな側面のテストをカバーしようとしてしまう点です。場合によっては、すべてを状態遷移図で表現するのではなく、一部はアクティビティ図による別のモデルで表現した方がすっきりすることがあります。複雑になればMBTモデルに誤りを埋め込む可能性も高くなります。効率良くMBTツールに入力でき、人間が理解可能なレベルでMBTモデルを作ることが大切です。

3点目は、MBTモデルは一度作成して終わりではなく、レビュー結果、または仕様変更などによりモデルを再構築することもあります。その際、モデルを変更しやすくしておけば効率的ですし、余計なミスが減ります。

4点目は、派生のプロジェクトや類似のプロジェクトが存在する場合は、MBTモデルが再利用しやすくなっていると、MBTモデリングの負荷軽減につながります。このような点も見据えてMBTモデルを作成することが肝要でしょう。

以上のように、本記事ではMBTモデルを設計するに当たって検討すべきこと、注意すべきことを中心に取り上げました。MBTモデリングを実践するには課題も多く、この点は継続的に取り組みながら解決していく必要があると感じます。連載コラムなどを通じて、引き続きMBTに関するノウハウや役に立つ情報をシェアできればと考えています。

■参考文献 ■

[1] CT-MBT Syllabus v1.0