ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

Veriserveのテスト設計サポートサービス、GIHOZを触ってみる - その1

 Veriserveさんが、テスト設計技法を使うためのWebサービスをリリースしたと聞いて!
 GIHOZ(ギホーズ)というそうです。

www.veriserve.co.jp

 さっそく触ってみましょう。
 推奨ブラウザがわからないので Edge 87.0.664.41 で試してみます*1

GIHOZを動かしてみる

 初期画面です。
 真っ白だと不安になりますが、そこに「+」ボタンがあると急に安心しますね。これを押せば何か始まるだろうという。

f:id:kz_suzuki:20201121201331p:plain

 「+」ボタンを押すと、現時点でサポートされている4つのテスト設計技法の選択画面に移ります。
 現時点では、以下の4つのテスト技法がサポートされているようです。

  • ペアワイズテスト
  • デシジョンテーブルテスト
  • 状態遷移テスト
  • 境界値分析

f:id:kz_suzuki:20201121201229p:plain

 今回は、境界値分析から行ってみましょう。
 題材として、ブログでも扱った『ソフトウェアテスト技法練習帳』の「1.12 配達便の料金体系」で適用してみることにします。

 問題の概要はこちらもご覧ください。

www.kzsuzuki.com

テスト設計モデルの作成

 境界値分析の初期画面はコチラ。

f:id:kz_suzuki:20201121201235p:plain

 まずテスト設計モデル*2の名前を入力します。
 「数直線」はプレースホルダーっぽく見えますが、キャプションです。

 一瞬、何から始めればいいか迷いますが、「変数の追加」でしょう。
 問題に合わせて、荷物の「大きさ」から入力していきます。

f:id:kz_suzuki:20201121201240p:plain

 「値の増減幅」で、立ち止まってしまうかもしれませんね。
 この問題では、大きさと重さという連続的な値を扱っており、精度を考える必要がありそう*3ですが、ひとまず「1」としています。

f:id:kz_suzuki:20201121201244p:plain

 いや、まだ入力途中だから怒らないでくれw

 「確定」すると、数直線が描かれます。
 この薄青の帯の上にカーソルを当てると、そこに境界値を打てる。

f:id:kz_suzuki:20201121200221p:plain

 なるほど、まず最小と最大を指定して*4範囲の全体を描いたうえで、その範囲内に境界値を刻んでいくという手順なのですね。
 わたし自身は、下から順に範囲を考えていくという手順をとっていることに気づきました。そうか、こういう手順もあるのか。

 仕様に沿って、「境界を追加」*5しています。

f:id:kz_suzuki:20201121213427p:plain f:id:kz_suzuki:20201121201256p:plain

 なお、帯の0と60の間を選択して、「80」を入れようとすると、エラーになります。

 どこをクリックしても、入力に合わせて適切な位置に絵を描くという仕様がいいか、あくまでも選択した領域に対応した値のみを受け付けるという仕様がいいか。
 前者の方が便利そうですが、入力ミスを防ぐという意味では後者の方がいいのかも。何せ境界値分析は、「境界でバグりやすい」という傾向を前提にした技法なのですから、入力ミスによる誤った設計も予防できるとよさげです。

 荷物の「重さ」の方も入力して、パーティションの名前も編集すると、以下のようになります。
 パーティションの有効無効も切り替えられます。グレーの帯部分が、無効パーティションです。

f:id:kz_suzuki:20201121201300p:plain

 なお、境界を修正する方法がわかりません。

f:id:kz_suzuki:20201121201328p:plain

 「境界を削除」したうえで、再度追加する仕様でしょうか。
 最小値と最大値は削除もできなさそうなので、変数追加の最初の時点で注意しておく必要があるかも。

テストケースの導出

 ともあれ、これでテスト設計モデルができました。
 「同値パーティション一覧を表示」ボタンで、各パーティションと代表値が表形式で導出されます。

f:id:kz_suzuki:20201121201305p:plain

 さらに「テストケースを生成」ボタンで、同値分割と境界値分析のテストケースが生成されます。

f:id:kz_suzuki:20201121201309p:plain f:id:kz_suzuki:20201121201313p:plain

 一見編集不可のテーブルに見えますが・・・、

f:id:kz_suzuki:20201121201318p:plain

 編集できます*6
 モデルから導出できない部分は手動で埋めて、テストケースとする *7わけですね。

 なお、導出&編集したこのテーブルは、CSVで出力することができます。

f:id:kz_suzuki:20201121201323p:plain

所感

 GIHOZの「境界値分析」機能を使ってみました。

 テスト設計モデルからテストケースを導出するこのようなツールを使うことで、テスト設計のモデルとテストケースを常に同期させることができます。そこから得られるメリットは、たとえば以下です。

  1. プロダクトの仕様変更を、モデルを通してテストケースに反映することができる
  2. テストの十分性を、個々のテストケースではなく、モデルから検証することができる

 状態遷移表、ペアワイズ法、原因結果グラフなど、各技法に特化したツールもありますが、GIHOZのように複数のテスト設計技法を扱えれば、テスト設計モデルを1つのツールで管理することができます。  モデルのバージョン管理他システムとの連携など、期待が広がるサービスですね!

 他の3つの技法についても、触ってみたいと思います。

*1:Firefox 82.0.3でアクセスすると、

ご使用のブラウザでは正常に動作しない可能性がございます。推奨ブラウザは こちら

となりました。

*2:GIHOZでは「テスト設計モデル」という言葉は出てこないのですが、わかりやすさのために以降、テストケースを導出するためのモデルのことをこう呼びます。

*3:『ソフトウェアテスト技法ドリル』ではこのような場合、幅を仮に「d」(differenceのことでしょう)と置いて、具体的な値は別途記述する、という方法を紹介しています。

*4:最大と最小は未入力にすることも可能です。

*5:「境界値」ではないところに、コダワリがありそう・・。

*6:モデルから導出した情報と、ユーザが補完した情報は、色分けした方がわかりやすい気がします。

*7:『練習帳』のこの問題では、大きさと重さを合わせて「サイズ」を判定しているので、テストケースと同値分割・境界値分析結果をマージしていくことになります。