本記事は ソフトウェアテストの小ネタ Advent Calendar 2023 の18日目の記事です。前日の記事は こちら から。
本日はタイトル通りのことがあったので、これについて軽く考察をします。
私とGIHOZ
タイトルのとおり、私は本職は株式会社ベリサーブにて、 GIHOZ や QualityForward といった、テスト業務支援ツールの開発マネージャーをしております。本記事はいわゆる宣伝記事ではなく、技術の話をメインとしたいため、細かい話は避けますが、GIHOZはいわゆるテスト設計技法の活用を支援するツールでして、いろんなテスト設計技法に対応しているのですが、その中のひとつに デシジョンテーブルテスト があります。
デシジョンテーブル
さて、デシジョンテーブル・決定表はテスト設計にのみ有益な整理法ではなく、むしろ複雑な入出力仕様を整理するのに有効な、仕様の整理法と呼ぶほうが個人的にはしっくりきます。たとえば、私は主に扱っているのがWeb系システムのため、以下のタイミングでよくデシジョンテーブルを書きます。
- WebAPIの入力パラメータパターンや事前条件に対するレスポンスのステータスコードやボディの仕様
- 入力フォームの項目数が多く、またそれらが相互に関連するバリデーションルールのあるような画面遷移処理の仕様
- SNSにおける「マイページ」のような、様々な事前条件によって画面状態が複雑に変わるような画面表示の仕様
Excelでデシジョンテーブルを書いた
最近社内でちょっと面倒をみているプロジェクトにて、けっこう複雑な画面表示仕様がありまして、ステークホルダー・開発ベンダーと口頭やJIRAチケット上での文章でのやりとりではどうも仕様の認識があわない、というシーンがありました。そんなときに、Web会議中にとっさにExcelを開いてデシジョンテーブルを書いて仕様を明文化する、ということを行いました。一部の人はそもそもデシジョンテーブル自体を見るのがはじめてだったので、様式の説明に少し時間はかかりましたが、その後はばっちり仕様の認識もあい、期待どおりの画面実装をしてもらえました。
めでたし、めでたし。
とはならず
数日後、上記の所業がGIHOZの開発チームにバレまして、なぜGIHOZを使わずにExcelでデシジョンテーブルを書いたのか、長時間監禁のうえ非常に厳しい尋問を受ける羽目になりました...
というのはもちろん冗談で、GIHOZのPO・開発メンバーから、GIHOZがどのような機能性だったらExcelではなくGIHOZを使っていたであろうか、という丁寧なユーザヒアリングを受けました。というわけで、せっかくなので本ヒアリングで話した内容を、小ネタとして公開しようと思います。
気づいたらExcelを開いていた
ただ、もともこもない話なのですが、実際問題、GIHOZにどんな機能があったらとか以前に、そのときは、デシジョンテーブルを書こうと思った次の瞬間には体が勝手にExcelを開いていた、というのが正直なところです。つまりGIHOZは選択肢にすら上がらなかったわけです。（立場的にはほんとにお恥ずかしい話ですが...）
考察するに、私自身、GIHOZを「テスト設計のためのツール」としてとらえていて（実際、現時点でのツールコンセプトはそのとおりのはず）、「仕様整理のためのツール」としては認識できていなかったように思いました。たとえばGIHOZは他にも状態遷移テストにも対応していますが、じゃいざ仕様として状態遷移図を書かなきゃとなったとき、おそらく私は同じように反射的にGIHOZではなくテキストエディタを開き、mermaid書式で状態遷移モデルを書いていると思います。
そんなわけで、これはけっこう大きな話というか、GIHOZの今後の進化の方向性として、あくまでテスト設計支援ツールという立場でいくのか、それともテスト設計補助機能もある設計支援ツールという道を歩むのか、ビジネスポテンシャルも考えて議論していかないとね、とGIHOZのプロダクトオーナーとは話ができました。
GIHOZでのデシジョンテーブル記述
とはいえ、大方針の話だけしてもアレなので、こまかい機能性の考察もいくつか
動作部も階層化したい
GIHOZのデシジョンテーブルは条件部は項目の階層化ができるのに対して、動作部はそれができません。JIS規格における決定表では条件部も動作部もどちらも階層表現は規定されてはおらず、きっと条件部は因子と水準の考え方を取り入れて階層化をサポートしたのかと思いますが、だったら動作部も同じにしてよ、といちユーザーとしては思うわけですね。たとえばWebAPIの仕様をかくときは前述のとおり、HTTPステータスとレスポンスヘッダ、ボディでグルーピングをしたいし、画面表示仕様にしても、HTMLのDOM構造しかり、画面表示要素というのも階層化されていることが一般的です。動作部も階層化できると、仕様ドキュメントとしての可読性をよりあげられるのではないかと思います。
特定の列やセルにコメントしたい
GIHOZはテストモデルに対してコメントを記述することができます。この機能自体も地味であまり知られていないのですが、どうせコメントを残すなら、もっとデシジョンテーブルの特定の部分を指定して書きたい、というニーズがあります。たとえば列については、今回テスト対象外にする理由があるのでそれを直接書きたいとか、動作部のセルに対して、なぜその結果・その動作になるのかの理由を直接書きたいとか、いろいろなユースケースが考えられます。これもサポートされれば、仕様ドキュメントとしての可読性向上に寄与すると思います。
Y/N/-/X/-より〇/×/-を使いたい
これはちょっと仕様モデルとしての本質的な話ではないのですが、JIS規格では条件の成り立つ・成り立たないはY/N/-、動作する・しないはX/-で表現する仕方が定義されていて、GIHOZもこのルールを採用しています。ただ、仕様ドキュメントは様々なバックグランドの人が目にすることがあるため、より直観的にその意味が想起できる〇/×/-でセルをうめるほうがわかりやすいんじゃないのかなー、と個人的には思ったりします。もちろんGIHOZはセルに自由なテキストを入れることもできるのですが、そうすると今度は「成り立つ」「動作する」セルを強調するカラーリングが機能しなくなるため、これもかゆいところに手が届かず、という感じです。
ぜひフィードバックをください
というわけで、テストエンジニアの皆さん、GIHOZを使っていてなんか気になること、こうだったらいいのになーという要望がありましたら、プロダクトオーナー・開発メンバーともに大歓迎ですので、ぜひとも遠慮なく言ってやってください！m(__)m