リーダブルコードから学ぶ、美しいテスト手順の書き方

※本記事は「ソフトウェアテスト Advent Calendar 2017 - Qiita」用の記事です。

どうも、6日目担当のオムそばです。
最近、@yoshikiitoさんのお勧めで、

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

という本(より良いコードを書くためのテクニックがまとめられている本)を読んでいるのですが、 ふと、「このテクニック、テストエンジニアがテストケースの手順(以下、テスト手順)を作る際にも使えるんじゃないか？」と思ったので、使えそうな部分をまとめてみました。
なお、本記事で取り扱う"テストケース"とは、大中小項目や、前提条件、手順、期待値、結果記載欄などがあるものという前提で話を進めます。その中の"手順"にフォーカスを当ててお話します。
また、ウォーターフォールでいうと主に結合テスト～システムテストあたりのフェーズのテストケースが対象になると考えていただければと思います。

■共通している大事な原則事項

まず、ソースコードとテスト手順、両方に共通している大事な原則について言及します。
リーダブルコードには、以下のような、ソースコードを読みやすくするための原則が記載されています。

　・コードは他の人が最短時間で理解できるように書かなければならない
　　- 例え1人プロジェクトだとしても必須。"他の人"とは他ならぬ未来の自分かも
         しれないからだ

これはまさしくテスト手順にもそのまま当てはまる原則です。多少テストPRJの経験のある人であれば思い当たる節があると思いますが、自分で書いたテスト手順ですら、「あれ、これ何のために書いたんだっけ」となることがありませんか？
(私は数えきれないくらい体験しています。。。)

■美しいテスト手順を書くために① 一貫性のあるレイアウトを使う

今回は、架空の炊飯器に対するテストケースを例にあげて、説明したいと思います。
以下の例を見て、どちらが美しいと思いますか？

感覚的に、Bの方が美しいと感じるのではないでしょうか。
(多少極端な例ですが)Aは1手順に対する粒度にバラつきがあるため、読みづらくなっています。
Bの方が手順の記載に一貫性があり、読みやすいはずです。
また、以下のような例もよく見るのではないでしょうか。

書いてある内容は、1も2も同じですが、手順の書き方が全く異なります。そのため、1をやった後に2を実施しても、同じくらい時間を書けて、テスト手順を読み込む必要があり、これもまた、読みづらいものとなっています。

テスト手順はできる限り均一で、一貫性のある記述を心がけることが望ましいでしょう。

■美しいテスト手順を書くために② 読み手の立場になって考える

リーダブルコードでは、ソースコード内のどこにコメントをつければいいかを判断するのに、表題のような技法を推奨しています。
テスト手順にも同じことがいえます。作成する際は、「このテスト手順を見てびっくりすることはなんだろう？どんなふうに間違えて使う可能性があるだろう？」と自分に問いかけながら書くとよいでしょう。

上記の例では、実行者が「6時間の設定はどこでするんだろう？」と疑問に思うと予測し、コメントを追記。

■美しいテスト手順を書くために③ テスト手順を小さく保つ

リーダブルコードには、様々な手法を用いてコードを小さく保つべきだと記述されています。テスト手順にも同様のことがいえます。

上記は不必要に手順が多いパターン。手順は最短で、必要最低限のことだけ記述することが望ましいでしょう。

また、繰り返し使われている手順は、一括りにまとめるのも効果的でしょう。その際は、詳細手順を別表でまとめておくことを推奨します。

いかがでしたでしょうか。「そんなこと言っても、テスト設計する時間が…」と思われた方も多くいるのではないでしょうか。そんな方々に、リーダブルコードの最初の方に記載されている言葉をお送り(多少アレンジ)し、本記事をしめたいと思います。

でもやるんだよ

この目標(美しいテスト手順を書くこと)を受け入れたら、君はきっと優秀なテストエンジニアになれるはずだ。自分の仕事に誇りを持ち、周囲の皆が喜んで使ってくれるようなテストケースを作り出せるようになる。さあ、始めよう！