MBTツールで実現する業務効率化

「モデルベースドテスト」（Model-Based Testing、以下MBT）とはテストモデルからテストケースを自動生成する技術や手法です。テストモデルには、デシジョンテーブルモデルやアクティビティモデルなどがあります。さらに、作成されたテストケースを自動でテストスクリプトに変換し、実行まで行うこともあります。

※MBTについての詳細は別の記事で詳しく説明していますので、こちらをご参照ください。
今さら聞けないQA技術：MBT（第1回） | HQW! (veriserve.co.jp)

私たちのテスト対象はWebサービスです。ユーザーや市場のニーズに迅速に対応するため、アジャイル開発で頻繁に機能改修が行われます。規模の大きなWebサービスのため、QA（Quality Assurance：品質保証）だけで数十名います。このような状況の中で私たちのプロジェクトでは次のようなことが起こっていました。

1. 仕様が未確定のまま設計を進めることが多く、修正が頻繁に発生していた
2. テスト条件のバリエーションが多く、組み合わせが複雑になっていた
3. 操作手順が複雑なため、テスト手順書が大規模になっていた

そこで、現場で発生した事例を用いて、課題の洗い出しを行いました。

■事例1■　お客様都合で発生した問題

仕様が未確定なままテスト設計・実装を進めていた際、テスト手順書の完成間近で大幅な仕様変更が入りました。「前提条件」「手順」「期待値」の全てを変更する必要があり、その修正カ所は100カ所以上に及びました。

■事例2■　設計者のヒューマンエラーで発生した問題

膨大な前提条件を組み合わせてテスト手順書を作成しました。しかし、納品後にお客様のレビューで誤字が発見され、修正が必要となりました。事例1と同様、修正に多くの工数がかかりました。

以上から、テスト実装工程の作業量が大きな課題であることが分かりました（図表1）。

次に、テスト実装の効率化を目的としたMBTの導入を検討しました。しかし、既存のテストモデル（デシジョンテーブルモデルやアクティビティモデルなど）を組み合わせたMBTでは、私たちの課題を十分に解決することができませんでした。導入できなかった要因は以下の2点です。特に、1つ目の要因が大きな問題でした。

1. テスト実行者にとって必要な情報を全てモデルに盛り込むと、テストモデルが非常に複雑になり、視認性が著しく低下すること
2. テストモデルを作成するために新たな教育が必要であること（既存の業務の遂行とメンバーの教育を同時に行うことが困難だった）

そこで、私たちは既存のテストモデルも活用しつつ、独自のテストモデルを考案してMBTを導入することにしました。

※既存のテストモデルを活用したMBTについての詳細は、こちらをご参照ください。
今さら聞けないQA技術：MBT（第2回） | HQW! (veriserve.co.jp)

私たちのMBTは3つのテストモデルで構成します（図表2）。

1. テスト手順モデル

テスト手順を自然言語で記載したモデル。条件によって変化する部分を変数として表記しており、最終成果物そのものを変更することなく、迅速にテスト手順を適応させることができます。これにより、修正が必要な場面でもスムーズに対応できるようにしました。

2. 期待値モデル

前提条件によって変化する期待値を定義したモデル。異なる条件下でどのような結果が期待されるかを明確にすることで、テストの正確性を向上させます。

3. テスト条件モデル

テストの前提条件を定義したモデル。テストを開始する前に必要な設定や条件を詳細に定義することができ、テスト実行の一貫性を保てます。

上記のモデルを変換してテスト手順書に出力するMBTツールを作成しました。

MBTツールの主な役割

1.条件/期待値の代入

テストシナリオ内の変数に特定の値を代入します。これにより、異なるテストケースを柔軟に生成することが可能です（図表3）。

2.階層化

前提条件に合わせてテストケースを階層化できる機能を提供します。この機能によって、複雑なテストケースを整理しやすくなり、全体の把握が容易になります。

図表4が導入したMBTの全体像です。このMBTの取り組みには大きな特徴が2つあります。

1.テスト実行者がそのまま使用できるテスト手順書の作成

テスト手順書には、前提条件と詳細な手順が正確に記載されており、実行者は追加の編集を行わず、そのまま使用できます。

2.当社のテスト設計ツール「GIHOZ」の活用

スムーズかつ効率的なテストモデルを作成できます。

ベリサーブが開発したクラウド型ツールで、IDを登録すれば誰でも利用できます。GIHOZではテスト観点ツリーを使ったテスト分析や、6種類のテスト技法を用いたテスト設計が行えます。さらに、ボタン一つで簡単にテストケースを作成できることも、大きな特徴です。作成されたテストケースは、MBTのテストモデルの一つとして活用しています。

※GIHOZについての詳細は、こちらをご参照ください。
テスト技法ツール「GIHOZ（ギホーズ）」とは何か？ | HQW! (veriserve.co.jp)

MBTツールを開発するに当たり、使いやすさを考慮し以下の3点を工夫しました。

1.  テスト実行者に優しいテスト手順書の作成

前提条件と詳細な手順をテスト手順書に記載することで、実行者がスムーズにテストを進められるようにしました。また、テスト手順書は前提条件に合わせて階層化されており、同じ前提条件の項目をまとめて実施できます。

2.テスト設計者に快適なテスト実装環境を提供

GIHOZを使って容易にテストモデルを作成できる環境を整えました。これにより、誰が書いても同じフォーマットでテストモデルを作成できるようにしました。

3. テスト設計者に優しいユーザビリティの実現

MBTツールはコマンド操作ではなくGUIを採用しました。さらに、入力するテストモデルに誤りがある場合、そのエラー文を自然言語で明確に記述することで、非エンジニアでもエラー内容を簡単に理解できるようにしました（図表5）。

最後に、私たちのプロジェクトでMBTを導入した結果について説明します。テスト設計およびテスト実装にかかっていた工数を30%も削減することができました（図表6）。削減した工数は、お客様のタスクの巻き取りやテスト実行など、他のタスクに有効活用しています。

主な効果

1.  効率的なテスト手順書の作成

これまで人手で行っていたテスト実装を自動化したことで、工数が大幅に削減されました。MBTの利点は、単に作成だけでなく修正時にも発揮されます。修正が必要な場合でも、テストモデルの一部を修正するだけで済むため、メンテナンスの効率化も実現できました。

2. 設計者ごとのテストケースのブレを解消

テストモデルを使用することで、設計者ごとの設計ブレが解消されました。また、コピー・アンド・ペーストなどのヒューマンエラーも自動化によって防止できるようになりました。この結果、レビューも行いやすくなったという意見が寄せられています。

このように、MBTは効率化と品質向上の両方において、非常に有効なアプローチであると言えます。

ベリサーブでは、今回の取り組み以外にもMBT関連の取り組みを多くのプロジェクトで行っています。具体的には、主要なモデリングツールである、たとえばEA（Enterprise Architect）やPlantUMLで作成した状態遷移図やアクティビティ図からテストケースを生成するツールの開発を進めています。