1.はじめに

　2022年はモデルベースドテスト(MBT)に取り組んできました。MBTはMBTモデルからテストケースを自動生成する技術です。ソフトウェアテストや品質保証に対して、ソフトウェアの品質を保ちつつもリリースのスピードを向上するための貢献（自動化など）が求められており、その要求に対応する技術としてMBTが重要になってきます。そして今年、MBTに関する発表をいくつか行いました。主だったのはInSTA 2022とソフトウェア品質シンポジウム 2022です。そこでこの記事ではそれぞれの発表の概説をして振り返ってみようと思います。本記事ではその2としてSQiPシンポジウムの発表を取り扱います。（その1はこちら)

2.発表概説

　タイトルは暗黙的になりがちな開発仕様パターンを活用してモデルベーステストを改善するです。(発表資料はこちら)

2.1.概要

　内容をざっくり説明していきます。まずMBTの性質上、テストすべきことは明示的にMBTモデルに盛り込む必要があります。またアジャイル開発では重要なところは仕様モデルを描くこともありますが、どうしても暗黙的な仕様は出てきてしまいます。そのような暗黙的な仕様をMBTモデルに盛り込めれば、自動テストでの動作保証範囲を広げることができるわけですが、暗黙的な仕様を捉えるには経験やスキルが必要になるため容易でありません。一方で仕様には書かれていないがテストケースには書かれているということがあります。それはテストエンジニアは暗黙的になりがちな仕様の共通的なパターンを知っているのではないかを考えました。そこで、WebAPI仕様を対象に過去に作成されたテストケースを分析し、暗黙的な仕様として捉えて抽出した中で共通性のあるものをパターンとして蓄積しました。そしてそのパターンを活用してMBTモデルを開発することができるか、新たなテストケースが生成できるかを試し、その成果を共有するという発表内容でした。蓄積したパターンとそれを活用した事例の一部を紹介します。

2.1.1.暗黙的になりがちな仕様に共通するパターン（パラメータ間の大小関係）

　テストケースを分析していると、WebAPIの２つのパラメータ間で値の大小関係の組合せを確認していることがいくつかありました。例えば、minPriceとmaxPriceという２つパラメータがあるとします。そして、maxPriceの値はminPriceの値より大きい値で指定する必要があるという暗黙的な仕様を捉え、以下の組合せを確認していました。

minPriceとmaxPriceの関係	意図
minPrice < maxPrice	仕様通りにmaxPriceをminPriceより大きな値で指定した場合
minPrice = maxPrice	minPriceとmaxPriceを同じ値で指定した場合
minPrice > maxPrice	minPriceをmaxPriceより大きな値で指定した場合

　このような暗黙的な仕様がいくつかあり、２つのパラメータの値において大小関係を持つ必要があるという制約を持つという共通性がありました。そこで、暗黙的になりがちな仕様に共通するパターンとしてパラメータ間の大小関係というパターンを蓄積しました。

　このパターンを活用した例を紹介します。テスト対象としたのは指定した範囲のスコアの値を取得するAPIで、複数あるパラメータの中でfromとtoの２つのパラメータがありました。仕様に定義された情報のみを使ってMBTモデルを作る場合（発表内では従来法と呼んでいます）は、それぞれのパラメータ単体で最小、最大の値の範囲を意識したものが作られました。ここで、パラメータ間の大小関係というパターンを使います。パターンを基に仕様を調査することで from < to という暗黙的な仕様（制約）を捉えられます。結果としてfromとtoのパラメータを組合せたMBTモデルを新たに開発できます。そのような事例でした。

3.発表補足

　当時を少し振り返りつつ、発表について補足したいと思います。

3.1.どのような経緯でこのテーマで発表することになったのか？

　仕様からMBTモデルを作ってテストケースを生成するところを自動化するにあたって、そのロジックを明らかにしようと取り組み始めました。そこで既存のテストケースとそのテストベースとなった仕様書を調査しました。その中で仕様書に明示的に表現していないこともテストケースにあることに気づきます。テスト設計者は仕様の行間を読んでテストを考えることがありますが、まさにそれが行われた結果に遭遇したわけです。そしてこれがテスト設計者が持つノウハウだなと思いました。これを暗黙的な仕様を捉えるノウハウだと位置づけ、この発表ではここに焦点をあてることにしたという経緯です。
　

3.2.何故WebAPIを対象にしたのか？

　まずは私が関わっていたプロジェクトでWebAPIテストをやられていたというのが大きいです。そして、そのチームではWebAPIテストの経験が浅いメンバーもいたので、ノウハウを蓄積し、活用していきたいという想いもありました。そして、WebAPIにおいてはSwaggerというRESTful APIの仕様を記述するための標準フォーマットがあります。これによりWebAPI仕様が形式的に表現されるのでパターンとして形式知化しやすいのではと考えたのも対象にした理由のひとつです。

3.3.どのような効果があったのか？

　発表内で示した効果としては、パターンを使うことでMBTモデル数、テストケース数が約11～18％増加する結果になったということでした。またパターンを使って仕様を調査することで検討漏れだった仕様に気づくこともあります。早い段階から仕様不備を開発者にフィードバックできるという面でも効果が期待できるかもしれません。

3.4.今後の課題はどんな点か？

　未経験者が理解しやすいパターンなのかと言われると現状はそうなっていないパターンもあります。結果的にパターン活用の難易度が高いパターンもあるので、そのあたりの改善は課題になってくると思います。またこの取り組みでは１つのシステムにおけるWebAPIテストに限定していたところもあるので、異なるシステムのWebAPIや、また別の仕様表現として状態遷移モデル、シーケンスモデルにおける暗黙的になりがちな仕様についてもパターンを検討していければと考えています。

3.5.発表してみてどうだったか？

　取り組みの一区切りになればと思い発表を決めました。結果的に、これまでの取り組みを纏めるだけというのに留まらず、考えが整理された点もあれば、新たな気づきを得ることもありました。そういう面でも凄く有効的に発表を使えたと思います。また最終的にSQiP Best Report Future Awardを受賞することができたことも、今後のモチベーションの意味で凄く意味があったなと感じています。

4.まとめ

　2022年にMBTに関して発表したことを紹介する記事でした。本記事ではその2としてSQiPシンポジウムを扱いました。MBTを改善するための暗黙的になりがちな仕様に共通するパターンという内容です。発表するまでの過程の中で様々な気づきがあり凄くいい経験になりました。2023年もMBTについて何か発表できたらと考えています。