テスト仕様書をもっと使いやすくて、メンテしやすいものにできないだろうか?
これまでテスト仕様書と言えば、Excelなどのスプレッドシートで書くことが多かったけど、 実は、HTMLで書いた方が楽だったりしないかな・・・なんて妄想してます。
まっさらなところからテスト仕様書を書くのは、Excelの方が書きやすいんだけど、 テンプレート化されたhtmlがあるならhtmlでも書けるし、htmlの方がメリット多いんじゃないだろうか?
ただ、さすがにhtmlタグを書きながら仕様書を書くのは思考の邪魔になるので、変換ツールでhtml化するのが妥当です。 テストの手順や検証内容などは、yamlやjsonで書いておいて、変換ツールでhtml化するイメージです。
ツールを介することのメリットは、たくさんあって、たとえば、パッと思いつくところをいくつか上げてみます。
- 小さいところでテスト仕様書の内部リンクを張れる
- ツールチップの表示ができる
- 手順を見やすい形でガイドするようなギミックを加えることができる
- lintingできる
このように、変換ツールは、 "工夫" を注入できるレイヤーになるので、あえて作業を多層化することでウマミを加えようというわけです。
ツール化するためには、"テスト仕様書" をデータモデルとして設計する必要があります。 やり始めてみると、これが大変なのだけど、上手く設計できると視点と粒度を制御できるようになるので、 テスト仕様書のメンテナンスが楽になるだろうと思います。
テスト仕様書は、テスト手順が増えてくると、テストの組み合わせに抜け漏れがないかをチェックするのが大変になります。
一般的な開発で作られている多くのテスト仕様書は、1つのテスト手順の中で、入力データのバリエーションを変えながら、 業務シナリオの流れをテストします。 これが、ときどき頭を混乱させます。
業務シナリオのすべての分岐フローが網羅されているのか?入力データのバリエーションは、全部網羅できているのか? とくに、前任者の仕様書を引き継いで、追加機能のテストケースを追加するときなどは、なかなかの苦行で生産性は悪くなります。
いったん、こんがらがってるところを、"テスト仕様書をデータモデル化する" という視点で整理してみるのは、それだけでも意味がありそうです。
前述のとおり、テストには、大きく2つの目的があります。
- 業務シナリオの流れをテストする
- 入力データのすべてのバリエーションでテストをする
データモデルも、この2つに分けた方が良さそうです。
テストフロー
ユースケースか業務フローを元にして、業務シナリオの流れをフローとして、以下のように洗い出します。- 基本フロー …… ベースとなる典型的な正常系のフローを1つ
分岐フロー …… 基本フローからから分岐するフローの全パターン
ユースケース記述があると基本フロー、代替フロー、例外フローがありますが、その要領で、基本フローと分岐フローを洗い出します。
データパターン
フローの全パターンができたら、そのフローに流し込む入力データを作ります。
たとえば、基本フローに流し込むデータは、基本フローの流れが成立しうる組み合わせを網羅します。基本フローに例外が発生する入力データを流すと、基本フローが成立しないので、そのデータバリエーションは考えないことにします。
このように、フローとデータパターンを分けて考えることで、思考の範囲を小さくできます。 よくあるテスト仕様書の作り方よりも、見通しがよくなって、生産性があがりそうです。
テスト仕様書を書く局面と、それを見てテストするとき局面では、テスト仕様書の見え方を違えてほしかったりします。
テスト設計時には、いったん細かいテスト手順は考えないで(見ないで)、フローだけを見たいときがあるし、データパターンだけに集中したい場合もあります。
テスト実施のときには、手順が見えないといけません。ちなみに、"どこまでテストしたんだっけ?" 状態になった経験はないでしょうか?手順を見間違えることがないように、今やっているテストの手順だけが見えた方がよいです。
変換ツールを使ってテスト仕様書をhtml化すると、このような局面にあわせた多面的な見せ方を演出できて、作業効率もあがるんじゃないでしょうか?
これは、テストそのものをシステム化することでもあり、今よりもテストが楽になって、品質も生産性もあがることが期待できます。
システム開発という仕事は、それ自体がシステム化されてそうな言葉の響きなんだけど、全然システム化されてない手仕事なので、この仕事こそDX化すべきことがたくさんありそうです。