テストケース作成で明確に仕様が決まっていない場合の「期待値」作成について- [ソフトウエアテスト技術ブログヴァンプ]

QA・テスト
271 view

テストケース作成で明確に仕様が決まっていない場合の「期待値」作成について

【見出し】

・はじめに
 ・そもそも期待値とは
 ・開発者レビューで「よしなに判断していただいているところがあり助かります！」との言葉をいただいた話し
 ・期待値は具体的であるべき？抽象的でもいい？
・最後に

はじめに

テストケースにおける期待値は「具体的であること」が基本的な考えです。
ですが客先にて少し前に担当プロダクトの一部機能変更があり、その際に仕様が明確に決まっていない、仕様書として細かく記載されていないものがあり、
テストケースの期待値を「〇〇または〇〇」、「〇〇画面と同じ挙動なこと」という期待値にして開発者へレビューをお願いしたことがありました。
それに対して開発のレビュー担当者から「よしなに判断してくれて助かります！」との言葉をいただきました。今回はその事について書きたいと思います。

そもそもテストケースにおける期待値とは？

そもそもテストケースにおける期待値とはどのようなものなのでしょうか？
結論を言うと「どのような状態になっていれば合格なのかを記載したもの」です。
その際に「処理に問題がないこと」など読み手や実施者により異なる解釈を与えてしまう可能性がある抽象的な書き方ではなく、誰が読んでも、誰が実施しても同じ挙動、同じ認識となるように具体的に書く事が好ましいです。
例を上げると、ショッピングサイトで商品の合計金額をテストする際に期待値で「合計金額が正しいこと」とすると実施者によっては計算が間違っていたり、何をもって合計金額が正しいのかというのが曖昧ですが、「¥〇〇◯と表示されていること」とすれば必ずそのような状態になっていないといけないので、誰が実施しても同じテスト結果になり、何をもって正しいと判断できるのかが明確です。
またバリデーションのテストで「エラーメッセージが表示されること」と書いてしまうと、エラーメッセージは表示されたが何を指しているかわからなく、テスト結果を「OK」としてもユーザー目線では使いにくく、品質としては好ましくないものが出来上がってしまうかもしれません。

抽象的に書いたが開発者レビューで「よしなに判断していただいているところがあり助かります！」との言葉をいただいた話し

前述した内容で期待値は具体的に書くということを述べましたが、以前作成したテストケースの期待値で「〇〇または〇〇（～と～に差異がないこと）」、「〇〇であること（～画面と同様の挙動であること）」と抽象的で期待値も２つ書いたことがあります。
そして開発担当者にレビューをお願いしたところ
「ざっと確認しました！内容よさそうです（よしなに判断していただいているところがあって助かります🙏他の画面と同じ挙動として判断しているところとか）」
との返答をいただくことができました。

ではなぜそのように作成したのかと言いますと、
アジャイル開発の場合、全てが細かく仕様決めされていないことや、仕様書に細かく記載されていないことがあり、今回の場合は特に一部機能の仕様変更だったため最低限の仕様しか共有されていなく、開発側も忙しかったため、下記の理由から一旦ケース作成を進めることを優先しました。

・他の画面でも同様な機能、または似たような機能があった
・「ここがはっきりしないと進まない」というものではなかった

もちろん一番良いのは「この場合はどんな挙動ですか？」と聞くことですが、この時は「どうしてもはっきりしないと進まない」「ここの期待値は明確にしたい」ではなかったため一旦ケース作成する事を優先して、
似たような機能が既に他画面でも実装されていればその挙動を基準としたり、「サービスの性質上、ユーザー的にこうあった方がいい」というユーザビリティを考慮したりして一旦作成しました。

でも今回のような書き方はしたことがなかったので、正直なところ「ちゃんと質問して明確な期待値にした方が良かったかな」とレビューを求める際に思いました。

ですが結果的にその書き方をしたことで助かりますとの言葉をいただけました。

期待値は具体的であるべき？抽象的でもいい？

前提として「問題がないこと」など抽象的過ぎるものは好ましくないですが、対象サービスの内容や開発チームのスタイルに合わせて期待値の解像度を柔軟に作成するのもありかと思います。
その際にただ抽象的にというわけではなく、
・他の画面の挙動と統一感があるか
・ユーザーにとって業務が止まるなど支障がないか
ということが前提となります。
またどのような状況でも具体的であった方がいい場合もあります。例としては、
・労務など法律が絡み、誤解や認識のズレ、解釈のズレが生じてはいけない場合
・医療系など命に関わるサービスの場合
があります。これらは経済的損失や命に関わることなので明確にして作成した方がよいと思われます。