QAのinomataです。
今回は開発者にオススメのテスト技法である、デシジョンテーブルを紹介します。
本日はSMPのバージョンアップ作業日だったり、ラピュタの放送日で世間はバルス祭りだったりしますが、個人的に時間があるのでブログを書いてます。ちなみにこれを書いてるのはAM04:00位です。
デシジョンテーブルとは入力値とその結果をまとめた表のことです。
特別なことは一切ないただの表です。しかしこれが結構な効果を発揮します。
たとえばフォーム1とフォーム2があり、その入力値に以下の仕様があったとします。
・フォーム1とフォーム2がともに有効値である場合、次の画面に進む
・フォーム1、またはフォーム2が無効値である場合、エラーメッセージを返す
・フォーム1の入力値が無効値である場合、フォーム2は入力できない
これを元にデシジョンテーブルを作ってみましょう。
作り方は簡単です。項目を縦に並べて、有効値と無効値の組み合わせをひたすら書いていくだけです。(HTML書くのが面倒なのでスプレッドシートで作成して画像をはっつけました。。)
純粋に組み合わせを出しただけなので、項目数数や入力値のバリエーションが増えれば多くなります。
ただ、今回は開発者向けです。全部テストする必要はありません。
なんだったらテストする必要もありません。ただ表を作って眺めるだけでもいいです。
しかしこうやって整理すると、ヤバいパターンが見えてきませんか?見えてきませんか。そうですか。
ではテストエンジニアはこれをどうやって見ているのでしょうか?
開発というのは建設的な作業で、開発者はものを作るということに意識が向きます。
対してテストというのは破壊的で、テストエンジニアはエラーを起こすこと(いかにバグを見つけること)に意識を向けています。
例えば3つ目の仕様ですが、フォーム1とフォーム2の入力値に順番の依存関係があります。
こういう仕様がある場合、テストエンジニアはいかにしてフォーム2に入力値を入れるかを考えたりします。デシジョンテーブルのパターン2ですね。
弊社SMPにはユーザーが申込みを行う場合に、大きく分けてwebページからのフォーム入力、CSV経由、API経由の3つがあります。webページのフォームは順番の依存関係がありますが、CSVとAPIは一度に入力値を指定できるので依存関係がありません。
このように、パターン2が実現できる方法がある場合でも漏れなくテストをしなくてはなりませんが、webのフォームだけを目の前にしていると気づきにくいパターンです。
デシジョンテーブルは項目間の依存関係や制限等をフラットに見ることができ、気づきにくいパターンを見つける機会を与えてくれます。仕様考えるシーンで表を作成していれば、上記のような制限を検討する機会を与えてくれます。
私が思うに、デシジョンテーブルは簡単に作れる割に、もっともバグを検出できる高コスパな技法だと思っています。とりあえず実践してみればその効果は実感できると思います。ぜひお試しあれ。