テストケースの書き方コツ

はじめに

これを書いている今日は5月6日(金)です。
7連休明けで明日からまた土日になるので今日1日はあまり力を入れずに自己研鑽をして過ごそうと思いQiitaを読んでいました。
QA的な新しい記事があまり無いなーと思いつつ「じゃあ自分が書くか」くらいなノリで書いていこうと思います。
この執筆はサボリではなく「スナバ」と呼ばれる業務時間内で認められている自由時間を使用しています。

文章としての体裁を整える

私も日本語は上手ではありませんが、まずテストケースをどう書くという話の前に日本語のドキュメントとしての質を意識しましょう。
設計者（設計と実装を区別している現場もありますが、本ページでは設計者を実装者、作成者の意味で記載します）以外の人が読むと
　それらしいけど適切なのかよくワカラナイ
　読みにくい
　手順や期待値が変だな
というものがしばしば爆誕します。

日本語のドキュメントとしての全体の構成やまとまりが適切でなく、さらに誤字脱字が含まれていると全体の構成が把握できないうえに読みにくいと感じる可能性が高いです。
全体の構成については正解があるものではありませんが、同じ会社やチームなどの組織内では、ある程度ルールを整えておいた方が良いでしょう。

ルールが全く整備されていないならソートをイメージすると良いかもしれません。

第1ソート：画面を基準に表示や機能を順次確認をしていく
第2ソート：OSを基準に順次確認をしていく
第3ソート：正常系、準正常系を順次確認していく

のようなイメージです。
テストケースをExcelやスプレッドシートで作っているなら第1ソートの画面名をシート名にしてシート内では第2、第3の順でまとまりを作っていく、ツールで作っているなら第1シートの画面名をテストスイート名にする・・・などが具体的な落としどころにすることが出来そうです。

他にはですます調や能動態と受動態も揃えておくとリズムが崩れなくて良いと思います。
手順の悪い例

1.ログインWebページを開き、新規登録ボタンを押下する
2.ユーザー名を入力する
3.パスワードを入力しろ
4.パスワード(確認)に入力
5.保存ボタンをクリックする

手順の良い例

1.ログインWebページを開き、新規登録ボタンを押下する
2.ユーザー名を入力する
3.パスワードを入力する
4.パスワード(確認)に入力する
5.保存ボタンを押下する

ボタンを押す操作は「押下」に揃えて、末尾は「する」で揃えてみました。
「クリック」に揃えても良いですし、「する」をすべて削除する形で揃えるのもOKです。

期待値の悪い例

・ユーザーを登録すること
・ユーザーが登録されないこと
・トップページが表示されること

期待値の良い例

・ユーザーを登録すること
・ユーザーを登録しないこと
・トップページを表示すること

期待値は能動態と受動態が混ざっているので能動態に揃えてみました。
期待値は受動態で書かれていることも多くありますが、一個人の意見としてはテスト対象は人ではなくシステムなのでシステムの振る舞いを期待値として書いています。つまり、能動態です。

・(システムが)ユーザーを登録すること
・(システムが)ユーザーを登録しないこと
・(システムが)トップページを表示すること

なお、所説あると思うのでこれは各組織で認識が揃っていればどちらでも良いと思います。
（噂では手順は能動態、期待値は受動態で書くように教わっている会社もあるとのこと。理由があってこれで教えているのであれば是非理由を教えて欲しいです！）

日本語の勉強ではないのでここでは混在さえしていなければOKとします。

誤字脱字

そもそもミスなので注意をしてもしてしまう人はしてしまうと思います。残念ながらうまく防ぐ術を心得ていません。
タイポ系を拾えるツール(Wordの校閲などでも可)の導入や、タイポは気が付いた人が直すというルールにするなどにしてしまったほうが良いかもしれません。
自分が書いた内容を読み直すことは最低限した方が良いと思いますが、徹底します！ という気合の元で何度も読み返したり周りの人にお願いをしてみてもらうことによる対処は費用対効果が低いので個人的にはオススメしません。

手順には手順のみを書く

1.XXXボタンを押下する
2.画面右上の〇〇を確認する
3.YYYボタンを押下する

上記の例の手順1~3には仲間外れがあります。
答えは手順の2です。
理由は1と3は操作手順なので名実共に手順で間違いありませんが、2は目視による確認で手順ではありません。仮に2を飛ばしても3の実行が出来るのであれば手順として順序に組み込むことが不適切です。
不要な条件や手順の指定は正しいテストにならない可能性があるので必要な内容を必要なだけ記載するようにしましょう。
この場合の書き換えとしては

1.XXXボタンを押下する
2.YYYボタンを押下する
※手順1実行後の期待値として「画面右上の〇〇が△△であること」という期待値にする

（どうしても必要であれば）
1.XXXボタンを押下する
2.画面右上の〇〇の確認後、YYYボタンを押下する

という形にすると手順をすべて操作手順に落とし込めます。

大なり小なりは揃える

< > ≦ のような記号や以上/以下、より大きい/より小さいの表現方法についてです。

これはQAよりもプログラムを書く方のほうが意識が強いかもしれません。
ちなみに私は新卒の頃に右側が大きくなるように書くよう教わりました。
if(0 <= i) がOKでif(i >= 0) がNGです。

テスト界隈では初歩的な教育で以下と未満の違いなどは教わる機会があるので区別はできていると思いますが、例えば年齢を19歳以下と20歳未満など同じ範囲を示す場合に書き方がずれることがあるので揃えるようにしましょう。

終わり

他にも書こうと思えば書けますが、夜になったので終了です。
生産性を重視していますが、すでにいろいろな事に取り組んでいて何かをやったりやめたりすることでグーーーンと生産性が上がるというようなものは残っていない気がしています。
なので、この記事に書いたような地味で微妙な事の積み重ねで気が付くと生産性が上がっている状態になったら良いなと思っています。

自分が書いた内容を読み直すことは最低限した方が良いと思いますが

お腹がすいたので最低限のこともしないで投稿したいと思います！（こーゆーのがしくじる原因）