ソフトウェアテスト Advent Calendar 2023 の15日目としての投稿です。
めっちゃ久しぶりのエントリーです。小ネタも2019年が最後だった。。。
先日、久しぶりにガチ目にテストケース作成しました。割と複雑な処理のところでデグレードを起こしていたため、複数の状態遷移にともなう処理を確認するためのテストを考える必要があり、しかしテストの意図を丁寧にわかりやすくケースにすると、いとも簡単に爆発するため、ケース組みの時点で複数のことを考えて圧縮する必要がありました。それでも「え？こんなにやるの？マジめんどくさーい」と開発メンバーに思わせたらしいです・・・開発メンバーどころか受け入れ担当者にまで面倒くさがられたよ・・・そんなの、ケース組むあたしだってめんどくさいのだ！
本題に入りましょう。なんでこんな前置きを書いたかというと、この手のテストを考えるときに、こんな手順を踏んでいます、という紹介をしようと思っているからです。
いきなりテストケースを書き出す人、けっこういると思っています。今年関わった案件でも、まずパラメータリスト作ってね、と言ったら、みんないきなりテストケース作りまして・・・レビューも大変じゃねーかー・・・
もちろん、それで問題ない単純なテストもあるので、まったくダメではないのですが、入力項目がたくさんあって、影響しあう項目もあって、バリデーションも複雑で・・・なーんて画面を相手に、いきなりテストケースを作ろうとするのはちょっと危険。
だけど、期待値がセットになったテストケースしか考えたことがないと、パラメータリストを作れと言われても、どうしてよいのかわからないみたいです。そういうことが「技法を学んでも使いどころがわからない」につながるのかもしれません。
テスト設計の過程
- テストパラメータを列挙する
- 今回実施する（設計する）テストの意図に影響するパラメータを選ぶ（開発者と確認しながら選ぶ）
- 必要なパラメータに対して、同値パーティションの確認をする（何をもって同値とするか、開発者と認識合わせをする）
- テストケースの構成を決める（どの技法を適用するかを決める）
- テストケースを作成する
上記のように書くと、テスト技法を使うのは手順5のように見えますが、手順1の時点からおそらくテスト技法は使っています。
そうです。同値分割法です。
今回私が一番言いたいことは、タイトルにあるように、この、同値分割をちゃんと意識しましょう！ここから丁寧にやりましょう！（テスト設計があまり上手くできないかも・・・と思っているならば、まずこの段階をしっかり踏みましょう。）ということです。手順1から3までが該当します。
もう一つ大事なこととして、テストの意図を明確にして、テストの意図に影響するパラメータでテストを構成しましょう。（影響しないパラメータを混ぜるのはテスト実装時にしましょう。）ということがあります。これは手順2が該当します。
テストパラメータを列挙する
いきなりテストケースにしないで、パラメータとしてなにがある？具体的にどんな値が必要？・・・ということを書き出しましょう。表でもよいですし、マインドマップのようなツリー構造を使ってもよいと思います。付箋でもよいと思います。この時点では、関係しそうなものは挙げてみる、なんか気になる値はすべて挙げてみる、という、発散型でよいと思います。考慮が漏れるほうが困るので、気になることはなんでも出してみます。
この作業は現場で行なっているかたも多いと思います。しかしながら、その後の作業（成果物）とつながらないケースもよく見ます。背景として、提示した過程の2と3の作業を雑にしてしまう、あるいは省いてしまうことで、上手く組み込めなかったり、余計なものまで組み込んでしまったり、ということが起こっている、というのが、いまのところの私の勝手な推察です。
テストの意図に影響するパラメータを選ぶ
テストの意図に影響するパラメータを用いてケースを構成しましょう。テストフレームを作ってみるとよさそうです。
テスト実行に対しては必要なパラメータではあるが、テストの意図を確認するためには必要ではないこと（影響しないパラメータ）は、テスト設計の段階で考慮してしまうと、よくわからないテストケースが出来上がります。
もちろん、本当に影響しないのか？という疑問を抱くことも大事です。ただ、「影響しないはずなんだけど影響しているかもしれないことを気にしたテスト」は、意図が異なるため、分けて考えましょう。たいていの場合、怪我します。（よくわからないけれどもパラメータいっぱいあるので組み合わせテスト技法を使って圧縮しました！なんていうパターンをかつてよく見かけたことがあります・・・テストの意図・・・orz）
同値パーティションの認識合わせをする
例えば、申し込みステータスごとに編集可否やボタンの活性具合が変わる、というふるまいをするシステムに対して、申し込みステータスのパラメータに対して分割するとしたら、ステータスなのか？編集可否の状態なのか？はたまた別のなにかなのか？という、分割の方針を明確にしましょう。開発者がどのように作ったのか？を確認したうえで、テストの意図に合った同値分割をしていくことを超絶お勧めします。テストの意図を考慮せずパラメータに対して列挙した値をそのまま使ったり、思い込みで同値パーティションを決めたりしないように・・・
JSTQB テスト技術者資格制度 Foundation Levelシラバス Version 2023V4.0.J01 でも、同値分割法について、このような記述があります。
単純なテスト対象であればEPは簡単だが、実際には、異なる値をテスト対象がどのように扱うのかを理解することは、困難なことが多い。そのため、パーティションに分割するのは慎重に行うべきである。
（4.2.1 同値分割法 の記述より）
・・・具体例がないとわかんないんですけど？
・・・そうですよねごめんなさい・・・
今回、現物をそのまんまというわけいにもいかず、簡略的な例を用意・・・と思ったのですがっ・・・
お題を考えていたら結構果てしなくなってしまって、まずはお題の解説から始まっちゃいそうだったので、具体例はいったん諦めます。ただ、お仕事の都合もあって、演習できるネタを作ろうかなぁと思っているので、また例が見せられるようになったら続きを書こうかな、と思っています。
