はじめに
テスト技法を勉強していた際に表題の技法のことを勉強したので、今回はこれを記事にしてみたいと思います。
いつ使うのか
この手法は主に、
- 受け入れ基準作成時
- テストケース設計時
- 探索的テストなどを実施する時
こう言ったシーンで使用することが出来るかと思われます。
開発エンジニアであれQAエンジニアであれ、または別の職種であっても仕様書は読むかと思われます。
その仕様書が完璧であれば言う事無しですが、実際は粗があったり矛盾を含んだ不整合なものであったりすることもあり、
それが手戻りの発生やプロダクトの品質の悪化にも繋がったりします。
このテスト技法はこういったユースケースに対して有効なテスト分析手法であり、
テスト観点(テスト条件)をより良く発散・想像することで仕様書をMECEに近づけることに寄与します。
このテスト技法それそのものがテストの網羅性のためにある訳ではなく、その仕様書を読む人が「怪しいと思うところ」を導出することで素早いフィードバックと効率的な欠陥発見を行えるという部分がこのテスト技法の肝かと思われますが、それは結果論としてはテスト観点や受け入れ基準などをMECEにしていけるという意味です。
アジャイル開発と組み合わせればより効果的かとも思われます。
それを応用すれば、BDDと言った受け入れ基準ベースで開発をする際やテストケースを設計する際も、先ずは前段階でこの技法を適用することでより効率良く開発・テストをすることが出来る訳です。
加えてテストケースが設計された後でもテストケースの行間を読んでテストを行うなど、探索的テストなどの経験ベースのテスト技法を用いるシーンでも使用することが出来る手法であり、クリエイティブにテストを実行する際の思考のフレームワークを提供してくれもします。
受け入れ基準の明確化やテスト観点の抽出といったシフトレフトとしての使い方もでき、かつ探索的テストなどのシーンでも使用することが出来る応用範囲の広い手法なので、プロダクトの品質を保証する上でも非常に効果的です。
『いや、仕様書なんて無くて』といったユースケースも実際はあったりするかと思います。
そういった受け入れ基準が不全の場合においてはまた別の手法を用いて改善することが出来ますので、そちらについてはまた別の機会に記事にしてみたいと思います。
またテスト観点の発散・想像においては今回の手法以外にもVSTePでしたりマインドマップを用いた手法などもありますので、そちらについても別記事でご紹介したいと思います。
フレームワークの構成要素
上記を踏まえた上でこのテスト技法を構成する諸要素について解説してみたいと思います。
このテスト技法は
- ソ（外側）
- レ（例示）
- は（破壊）
- ア（間）
- タ（対称）
- ル（類推）
『ソレはアタル』という頭文字から構成されます。
それぞれについて見てみましょう。
破壊の「は」については、このテスト技法の語呂合わせを考案された鈴木三紀夫さんが付け加えられたとのことであり、具体的にどのような観点で見るのかについては分かりませんでした。
そのためこの記事では「破壊の「は」」以外の観点についてご説明いたします。
例題
そのためにも以下のように例題を設けてみました。
例題:
とあるソフトウェアのプログラムには以下のような仕様があるとする。
・ユーザーは任意の整数を入力できる
・その出力は上記整数の階乗である
例示のレ
上記例題を踏まえ、まずは例示の「レ」からです。
このテスト技法はピンポイントテストを効率良く実施するための手法なのですが、その始まりが「例示」からなので、「レ」から説明します。
例示とはその名の通り、具体的に列挙してみることです。
上記の例題に置き換えると、ユーザーが入力した任意の整数と言ってもイメージが湧きづらいですよね。
なにせ抽象的です。
そこで具体にするために、その入力数を『1』『5』『100』みたいにイメージします。
こうすることで上記の仕様がより輪郭を帯びてきて、以降の仕様分析における違和感の発散に繋がったりします。
間のア
次は間の『ア』です。
これは例示でイメージした具体例の間を考えることです。
上記の例示で『1』や『5』と出ましたよね。
とするとその間の『2.5』を導出することが出来ます。
するとこんなことが気になってきます。
小数点の階乗って結構数字が膨らむよな。
一体何桁目まで出力で返すんだ？
それは切り捨て？切り上げ？四捨五入？
オーバーフローとかは大丈夫？
いい感じに疑問が湧いてきましたね。
対象のタ
次は対象の『タ』です。
さっきの具体例で『5』と出ましたよね。
するとそこから『-5』が導き出されますね。
または『1/5』が出てくるかも知れません。
すると、、、
ユーザー入力では負の数も許すの？許さないの？
分数はどうするの？
またまた疑問が湧いてきましたね。
類推のル
次は類推の『ル』です。
類推とは類似しているものをイメージすることです。
さっき『100』と出ましたよね。
するとそこから『0』がイメージされそうですよね。
または、『00』みたいなものや、『00.0』みたいなものも思いつくかも知れません。
すると、、、
0の階乗って1だけど、それを踏まえてプログラムは実装されているの？
0が入力されたら続けて0の入力も許すの？それって良いの？
『0.00』みたいなものも許すの？
何桁目まで？その最後が0でも良いの？
階乗のプログラムはちゃんと組まれているのだろうか。。。
この辺りPOに聞いてみよう。
おっ、どんどんイメージが湧いてきて、POが気付いていなさそうなことも考え出せましたね。
外側のソ
最後は外側のソです。
これまでは数字を思い浮かべてきましたよね？
でもユーザーは数字だけを入力するでしょうか？
キーボード上には『文字』や『記号』も表示されていますよね？
ここで言う外側とは、こういった今まで列挙してきたものとはそもそも異なることを想像することを指しているのです。
すると、、、
数字以外を入れるとどうなるんだ？
ちゃんとバリデーションは効いているのだろうか？
ん、ちょっと待てよ、数字の場合でも実は境界値があるのではないか？
同値分割や2値境界値分析、3値境界値分析をやっておいた方が良いのでは？
実装をよく見てみよう！
早目にテストをしてみよう！
おっ、ここでも色んなことを考え付きましたね。
アプリケーションのクラッシュに繋がりそうなことだったので、これは良い兆候ですね。
仕様を深く確認しつつ、早目にテストを行い、実装の欠陥を探そうとする、という早期テストに繋がっており、これは良さそうです。
しかもこれは開発の早期(いわゆる上流と呼ばれるフェーズ)から実践できる静的テストの手法なので、より後半に生まれ得る欠陥を無くしていくことが出来ます。
このテスト技法を使って検証をしていくと開発工程やテストプロセス上に実は問題があること、
例えば開発環境上の問題や組織風土などの根本原因が見つかるかも知れませんし、
それが人間のエラーに繋がっていることが判明するかも知れません。
品質保証とは開発プロセス上の全体をより良くしていくことでプロダクトの品質を保証していくといったプロセス指向の予防アプローチをとり、プロセスの改善と実装を行っていく働き方を指すものと思われます。
POも開発エンジニアもQAエンジニアも使うことが出来るテスト技法なので、
皆でスクラムを組んでプロダクトをプロセス面からもより良くしていきたいですね。
参考