普段の仕事で、開発者の書くテストケースをレビューしたり、開発チームのリーダーの方から「もうちょっとテストケースの書き方ってなんとかできないもんすかね」といった相談をうけたりすることがあります。
いずれも「もっとよいテストケースはできないか」という問いを立てたり立てられたりしている、と言えるでしょう。
じゃあ「よいテストケースって何？」という疑問が出てきます。
こんなのは嫌だ、はポコポコ思いつきます。
私がよく開発者に対して説明しているのは、「目的や意図がわかること」がよいテストケースの条件（のひとつ）ということです。
もちろんバグを見つけられるとか、重大な問題がないことを保証できるとか、なんらかの基準で網羅している、といった要素も大事です。 ただ、これらの要素はテストケースを作る人が単独でどうにかするものではなくて、チーム内でのレビューやナレッジの蓄積を通じて向上させていくものだと考えています。そうなると、よいテストケースにするためは「レビューのしやすさ」が大事だ、というのが私の意見です。
テストスイートもそうですし、個々のテストケースに関しても目的や意図（そのテストケースをPassしたら何が言えるのか、何を担保したいのか）が伝わると、レビュワーが「この観点が足りてなさそう」等の意味ある指摘ができます。逆に目的などがわからないテストは周囲もレビューしづらいです。とくにケース数が多かったりすると、なんとなく「数も多いし網羅出来ていそうな気がするな」と思われてしまうことも・・・
そのため、私は開発者に対して「意図が伝わるようにテストケースを書きましょう」と説明しています。
ここでツッコミを受けそうなので補足しておくと、テストケースの書き方を工夫してレビューのしやすさを高める、というのは充分ではないとも思っています。目的や意図が読み手に伝わるようなテストにするためには、そもそもいきなりテストケースを書き出すのではなくてテストプロセスというものがあってですね・・・という説明ももちろんしています。
が、イネイブリングQAとしては「QA／テストエンジニア的べき論」をいきなり伝えて実践してもらうのはデメリットも大きいと思っています。テストケースのフォーマットを変えて対応できるレベルのところからスタートして、だんだんとテスト分析や設計にあたる活動を浸透させていくようなアプローチをとっています。
さいごにふたこと。 ひとつは、意図がわかるテストケースを作ろうの話は、こちらのスライドをとにかく読むのがおすすめ。
JaSST'24 Tohoku基調講演/jasst24tohoku_keynote - Speaker Deck
もうひとつは、みなさんの思う「よいテストケース」も教えてください。