アーカイブ動画
単なるソフトウェアテスト会社ではなく「品質創造企業」
株式会社ベリサーブ
研究企画開発部 技術戦略課 蛭田 恭章氏
ソフトウェアテスト会社として、40年以上にわたり幅広い業界のさまざまな製品のソフトウェア検証に取り組んできたベリサーブ。これまでに携わったプロジェクトは累計3万8000件以上、クライアント数も1100社以上に上る。名実共に、ソフトウェアテスト業界のパイオニアであり、リーディングカンパニーと言えるだろう。
一方で2006年に入社し、ソフトウェアテストやソフトウェア品質全般業務に長きにわたり携わった後、研究企画開発部にて新たな技術調査や技術開発に従事する蛭田恭章氏は、ベリサーブの本質を次のように語る。
「私が入社した頃は、確かにソフトウェアテスト会社だったかもしれません。ですが、今は違います。ベリサーブは“品質創造企業”なのです」（蛭田氏）
ソフトウェアの品質を創造するには、大きく3つの力が必要だと蛭田氏は言う。1つ目は、これからの商品やサービスに必要とされる品質の意味を説い続ける力であり、「常に新しい技術や知識を入力する姿勢が求められる」と、蛭田氏は続けた。
また、社会状況の変化により品質も変化するため、最適な基準を提示する力。そうして創造した品質を、社会に実装する力も求められると強調する。
「私たちは常にこのような意識で仕事に取り組んでいます」（蛭田氏）
そして、蛭田氏が現在モデルベースドテスト（以下、MBT）の技術開発や導入支援に携わっているのも、「まさしく新しい品質を創造するために必要な技術であり、今後ますます大事になるから」と、語った。
テスト設計業務の自動化を通じ、ソフトウェアテスト全体のデジタル化に貢献
MBTとは、ソフトウェアにおけるテスト設計業務を自動化する技術である。従来から概念自体はあったが、ベリサーブでは「MBTモデル」というさまざまなグラフィカルなモデルとツールを使うことで、テストケースを自動生成していく。
従来のテストプロセスは主に手動であったが、MBTを使うことで自動化される。
ただし、入力においては多くの人が使いこなせるExcelではなく、MBTモデルを使い、同ルールに従うことになる。そのため、入力の形式度は高くなる。
続いて蛭田氏は、MBTを導入する一般的なメリットを大きく3つ挙げた。例えば、時間の側面においては仕様変更が入った際など、従来では書き直す必要があったが、MBTであればモデルを書き直すことで修正対応時間が短くなる。
一方で、時間的側面のメリットを享受できるようになるのは、MBTを導入してからしばらく経った後になるという。
「初期段階にはモデル作成やツールの整備など、環境整備が必要になります。そのため実際には、標準化、信頼性、時間といった順番でメリットを感じることでしょう」（蛭田氏）
ベリサーブがMBTに注力しているのは、プロダクト開発における環境の変化も理由の1つだ。アジャイル、DevOps、CI/CDなどだ。
特にソフトウェア領域におけるプロダクト開発では、さらなる開発スピードの短縮や、各プロセスの自動・効率化を目指すべく、さまざまな開発環境や手法が取り入れられてきた。
このような開発環境や開発スタイルの変化は、完成したプロダクトを検証するソフトウェアテストや品質保証業務でも求められるものである。
実際、ソフトウェアテストにおいても、テスト実行フェーズの自動化は進んでおり、MBTはそのような流れをさらに加速する技術だと、蛭田氏は述べた。
なお現状では、MBTはMBTモデルからテストケースを自動生成するまでの領域に限られる。だが、いずれは「テストスクリプトの生成やテストの実行、結果報告などもすべて自動化したい」と、蛭田氏は語る。
実現に向けては、あらゆるフェーズにおけるデータのデジタル化が求められてくるため、MBTはテストプロセス全体のデジタル化にも貢献する。目指している世界観を改めて次のように語るとともに、そのキー技術となるのがMBTだと続けた。
「テストベースの変更はよく発生します。MBTであればモデルを変更するだけで、再実施が容易です。また、製品が市場に出た後も改善フィードバックのループが回せるようになる、そのような世界を目指しています」（蛭田氏）
MBTであれば、テスト技法だけでは生成できないテストケースも生成可能
従来からある、テストケースを効率よく作成するためのテスト技法とMBTはどこが違うのか。蛭田氏は、モデルからテストケースを生成する点では同じだと前置きしながらも、具体的に3つのテスト技法を紹介すると共に違いを述べた。
1つ目は「ペアワイズテスト」である。ペアワイズテストでは、パラメータのペアを網羅的に組み合わせることで、テストケースを自動生成していく。
デシジョンテーブルでは、条件の組み合わせと条件に応じた動作を、こちらもペアワイズテストと同じく、網羅的に自動で生成していく。
3つ目は「状態遷移テスト」である。左側の状態遷移図から変換ロジックツールを使い、右側で示されたようなテストケースを生成していく。「テスト技法の中では、この状態遷移テストがMBTに一番近いでしょう」（蛭田氏）
一方で改めて、テスト技法との違いをスライドで可視化すると共に、次のように語った。「テスト技法だけでは生成できないテストケースがあります。MBTはそのような場合でも、テストケースを生成することが可能になります」（蛭田氏）
実際、従来のテスト技法だけでは生成できない、どのようなテストケースがあるのか。蛭田氏は電源周りの状態遷移図を例に紹介した。
さらには、タイマーカウントの状態遷移についても紹介した。このテスト技法では生成が難しいテストケースは、これまで熟練のテスト設計者の知恵やノウハウにより、作成されてきた。
そのような暗黙知やノウハウを言語化することがMBTの役割であり、「このようなルールやロジックをわれわれはMBTパターンと呼んでいます」と、蛭田氏。なおMBTパターンは、ベリサーブならではの独自の呼び方である、と補足した。
ここからは実際に、MBTを使った2つの実践事例を紹介した。1つ目は、車載ドメインにおける、テスト設計の標準化に向けての取り組みだ。
同事例では、テスト設計はこれまで熟練担当者1～2名への依存度が高かった。そこで熟練者のノウハウを形式知化し、テスト設計の標準化を図った。まさにMBTの役割、意義にもつながる。
具体的な取り組みとしては、熟練者が作成した過去のテストケースから生成ロジックやルールを分析し、MBTモデルからテストケースを生成するためのMBTパターンを定義していった。なおMBTモデルは状態遷移図を、モデリングツールは一般的なEnterprise Architectを使用した。
実際に取り組んだ感想、苦労した点を蛭田氏は次のように述べた。
「熟練のテスト設計者のロジックやルールを分析していくと、開発者とのコミュニケーションから得たもの、別の箇所から得た情報、過去の不具合を参考にした、など。暗黙知を捉えることに苦労しました」（蛭田氏）
また、テスト設計段階で検討する内容なのか。それとも実装段階で行うべきものなのか。その区別、切り離しも苦労したと続け、「とにかく地道に取り組むことで、解決していきました」と、語った。
蛭田氏は成果も示した。以下スライドのとおり、今回のPoCでは42％が生成可能となったが、ツールなどを整備すれば、将来的に生成可能なテストケースは36％。つまりMBTを導入することで78％ものテストケースが自動生成、ならびに標準化されることが分かった。
また工数においても12％削減するという成果が得られた。なおイベントでは、実際に状態遷移図からテストケースが、PCのデスクトップ上で作成されるまでのデモ動画が流された。興味がある人は、アーカイブ動画で確認してみよう。
続いては、デジタルプロダクトでの実践事例である。こちらの取り組みでは説明性の向上、仕様変更への素早い対応を目指した。
MBTモデルは状態遷移図も候補に挙がったが、アクティビティ図を採用。現行のユーザーシナリオを意識したテストケースを生成するモデル図が、まさに今作成段階だと述べた。
事例2の取り組みでは、アクティビティ図だけでは満足するテストケースが生成することが難しいことが判明した。例えば、Wi-Fi接続では3通りの方法があるが、それぞれのシナリオを生成する必要があるからだ。
またシナリオの種類によってはテスト量の調整が必要となった。蛭田氏は次のように現在の課題と今後の展望を述べ、講演セッションをまとめた。
「MBTではモデルを書いておくことが必要かつ重要です。一方でモデルを書いたことがないケースもありますし、作成においては工数もかかります。そこで現在は生成AIなどを活用しモデルを作成できないか。そのようなことにも取り組んでいます」（蛭田氏）
【Q&A】参加者からの質問に回答
講演終了後は、参加者からの質問に答えるQ&Aセッションが実施された。QAセッションでは蛭田氏に加え、ベリサーブ以外の企業での取締役、大学講師、著書執筆など、さまざまな場所で幅広く活躍している松木晋祐氏も、ファシリテーター兼回答者として参加した。
株式会社ベリサーブ 執行役員
研究企画開発部長
AIQVE ONE株式会社 取締役CTO 松木 晋祐氏
Q&Aセッションというよりもディスカッションのような雰囲気となり、多くの質問が挙がるなど、大いに盛り上がった。抜粋して紹介する。
Q．現在、テスト実行の自動化にも着手していない。MBTに着手するのは非現実的か？
蛭田：テスト実行の自動化は、対象によっては難しいドメインがあります。そのため、テスト設計だけでもMBTで自動化することは有りだと思います。
松木：MBTには仕様書からテストケースを生成するもの、さらにテストケースから自動テストまで生成するもの、一部の機能的なMBTから、フルスペック的なものまでいくつかあります。従って、一部だけを利用するのは有りだと思いますし、むしろ先進的な取り組みだと思います。
Q．仕様書からテストケースを自動生成しようとしたところ、仕様書作成の負担が増え、結果として開発全体のスピードが遅くなってしまった。どのように改善すればよいか
蛭田：テストケースを自動生成するためには、確かに仕様書をしっかりと書き込んでおく必要がありますから、同工数が多くなるとは思います。
松木：一方で書き過ぎてしまっては形式手法になってしまいますから、開発側とテスト側でコミュニケーションを取り、どこまで書いてもらうのか。温度感を擦り合わせることが大事だと思います。
蛭田：開発側が示した仕様がテスト側に伝わっていない。ドキュメントに不備がある。このような課題を解決するために、MBTを導入した事例もあります。
松木：テストチームと開発チーム両者の共通言語がない場合などは、まさにMBTモデルを活用することで、乗り切ることができるかと思います。
蛭田：まずはテスト側がモデルを開発する。そのモデルを開発側にも持ち込み、最終的には開発側もモデルを開発する。そのような体制が理想だと考えていますし、MBTの使い方でもあるとも思っています。
Q．アジャイル開発におけるMBT導入のコツは？
蛭田：ドメインによりますが、Web系であればライトなモデリングを行い、そこからテストケースを作る、との流れで進めたら良いかと思います。フローを描くだけでも認識が深まることがありますし、デジタルで作成すればつなぐことができるからです。
松木：開発側と一緒にモデルを描いていくのは良いと思います。
Q．MBTモデルの生成は人力で行うしかないのか？
蛭田：まさにMBTの導入障壁はMBTモデルを作ることです。ただ実は、自然言語の仕様書からMBTモデルを生成AIが自動で生み出す。そのような取り組みが進んでいます。
松木：弊社でも特許出願中であり、近いうちに詳細をお伝えできるかと思います。
Q．自然言語で記載された仕様書と、UMLやSysMLで記述されたモデル、両者からMBTモデルを作成する際の難易度や効率性の違いはあるか
蛭田：一からモデルを作り出すのは時間もコストもかかりますし、自然言語からモデル化することは、難しいアプローチでもあります。そのため、すでにあるUMLなどから作成したほうが、取り組みやすいでしょう。
Q．自動・手動の線引きも含め、MBTは手動で行うべきテストをより簡単に行える技術、との理解で合っているか
松木：おっしゃるとおりです。テスト設計まで含めると、人が取り組むより説明性が向上したり、ロジカルであったりするからです。
蛭田：現在は取り組んでいませんが、MBTでモデル化しておけば、自動・手動と分けて吐き出すようなことができるかもしれないとも思っています。
Q．MBTで生成したテストケースだけでは、すべてのテストを実現するのは難しいのでは？
蛭田：完全を目指したいですが難しいのが現状です。機能テストや負荷テストはある程度カバーできそうですが、非機能系のテストは難しいと感じるからです。実際、MBTだけでは実現できないテストはあると思います。
松木：機能仕様書があれば、機能テストはすべて作成できると思われがちですが、後から足された機能と既存機能の組み合わせは、仕様書に書かれないことが大半です。そのためすべてを網羅することは難しい。だからこそモデルをメンテナンスし続けることで、カバーしていきたい。私たちはこのように考えています。
Q．テスト対象の製品理解は必要か？
松木：テスト対象の理解は必要です。
蛭田：テスト分析の深さは、対象をどれだけ知っているかによります。そのため私はめちゃくちゃ取り組みます。その際には製品理解はもちろん、開発者の思いも理解したいとも思っています。
Q．MBTのデメリットは？
蛭田：モデルがすべてであり、モデルが間違っていたら全部間違ってしまう点です。
Q．MBTモデルを変更した際、影響があるテストケースを明確にすることは可能か？
松木：モデルがデジタルデータで描かれていれば、diffを取ることでその差分にひも付くテストケースがどれかを、判断できるかと思います。トレーサビリティも取れますし、研究しがいのあるテーマだとも思います。
蛭田：できると思いますし、これからは必要になってくる、求められると考えています。管理ツールとの連携なども含め、これから取り組んでいきたいと思います。
Q．ソフトウェアの規模は考慮すべきか
蛭田：原理的には規模は問いません。ただし、規模が大きくなるとその分モデルも増えるので、管理や連携といった問題が発生してくるとは思います。
Q．仕様詳細とテストケース。最初から設計者と検証者が共同で設計すればよいのでは？
蛭田：できる状況であれば、むしろそのような状態に持っていくのがいいと思います。あくまでこれまでのテストの考えは残しつつ、一緒に設計する。このようなスタンスが良いかと思います。
松木：理想的な状況だとも思いますし、一緒に設計した後に改めてテスト側で検証する。このような流れも有りだと思います。
株式会社ベリサーブ
https://www.veriserve.co.jp/
株式会社ベリサーブの採用情報
https://www.veriserve.co.jp/recruit/
関連するイベント
