テストケースが仕様書という感覚
そもそもテストケースもテストを指定（Specify)しているので仕様書です。JSTQBの用語集を見ても、「テスト仕様書」や「テストケース仕様」という用語が見つかります。ですが、私個人としてはこれまであまり仕様書という感覚はなく、仕様書だという意識も薄かったです。
しかし、今の現場でテストコードを実装している人と会話すると彼らは仕様書という言葉を使い、そして仕様書という認識していることが強いことが分かりました。テスト実行者にはあまりない感覚かなとも思いました。また、『テストも開発なのだ！』と言われることもありますが、これをより実感できるようになりました。テストケースにおいて、しっかり指定すべき、明確にすべきなのだという意識が高まりました。
それは、自動テストの場合、手動テストのようにテスターが色々考えて補ってくれないからです。実装した通りにしかテストは実行されません。テスト実装者が気をきかせて盛り込んでくれるということも無くは無いですが、それを期待してテスト設計するのはあまりにも愚かです。
さて、テストケースには様々な要素がありますが、その中でも前提条件、手順、期待結果の３つの指定について触れたいと思います。
前提条件のこと
まずは前提条件ですが、ここにはテストケースの手順を実施する際のテスト対象の状態や環境を指定することになります。「初期状態であること」「ｘｘが登録済みであること」「xxxでログインしていること」「テスト対象内にｘｘｘというデータが複数存在すること」「テストサーバーに接続されていること」などです。
実現したいテストを実施するうえで必要になるものを指定します。これは前提条件と言うくらいなので、テストそのものではなく、あくまで前提の内容になります。ただし、これを誤ってしまうと、いくらその後の手順が正しくても期待する結果にならなくなります。そして何よりやりたいテストが実現されないことになります。そのため、当たり前だからといって記載を省くようなことはせず、正確な情報をしっかりと指定する必要があります。ある程度パターン化されているなら状態Aとか環境Bとかにして情報量を減らす、伝えやすくするという工夫はあるかなと思います。
手順のこと
手順を明確に書くことは当たり前ですが、それ以外にも気をつけた方が良い点がいくつかあります。これは私が実際にテスト実装者（自動化エンジニア）とやりとりする中で気づかされたことです。
まず一つ目はある画面内の要素のフォーカスの仕方です。例えばある画面に「30秒」、「1分」、「なし」と言う項目が上から順に並んでいるとします。「30秒」の項目確認後、「1分」の項目を確認したいので、「1分にフォーカスする」という手順を書きます。私は↓キーを押すことによって「1分」にフォーカスして欲しいと思っていましたが、それは明記せず、無意識にそうするものだと思い込んでいました。しかし、自動化ツールによる操作の場合↓キーを押すことなく、「1分」という項目を探して直接フォーカスすることも可能だったりします。（今回の場合は実際にそうでした）もしその内容で実装されてしまった場合、↓キー操作によるフォーカスの切り替えは確認されないことになります。キー操作のテストが不要だった場合はこの内容でも問題ないですが、↓キー操作によるテストも必要だった場合はテスト漏れになります。そのため、キー操作が必要なのであればしっかりと明記する、もしくはテスト設計者、実装者間で、このようにテストケースに書いてある場合はこう実装して欲しいなどのルールを作り、共有することが大事です。
また、もう一つ気をつけた方が良いと感じたのは、初回だけに表示されるチュートリアルの画面の扱いです。つまりある操作を行った際に表示される画面が初回と2回目以降で変わってしまうと言うことです。これをあまり意識せず手順に書いてしまうと実装する時に困る、もしくは自動テストの実行で失敗する可能性がでてきます。この点をしっかり手順に盛り込む、もしくは前提条件で指定することにより回避するなどの対策が必要です。
期待結果のこと
期待結果で気をつけた方がよいのは、まずは何をもってそれを確認するかということだと思います。「xx画面が表示されること」「xx画面に遷移すること」などの場合、画面タイトル、もしくはその他の画面内要素で判断することになることが多いです。
「xxが開始すること」「xxの登録が成功すること」などであれば変化が生じるポイントがあります。ステータスやボタンの名称や色が変わる、何かメッセージが表示されるなどです。このようなポイントをしっかりと伝える必要があります。これをその都度テストケースに明記するのでもいいですが、ある程度パターン化されたものであればテスト設計者と実装者で共通認識をもてる記述ルールを設けるのもありだと思います。
あとは記述が漏れがちなのは、「表示されない要素」についてです。例えば、ある状態では「A,B,C」の3項目が表示され、状態が変わると「B,C」が表示されるとします。この時、状態が変わったあとの期待結果を「B,Cが表示されること」と記述したとします。そして実装もBとCの存在有無を確認して判断していた場合、もしB,C以外に表示されてはいけないAが表示されていたとしてもこのテストコードではその不具合を検出することはできません。「B,Cが表示されること」というのが、暗黙的に「Aが表示されてないこと」を含んでいたのであればしっかりと明記することが必要です。手動テストであれば、「B,Cが表示されること」というテストケースにたいしてAも表示されていればテスターは変だなと感じアクションを起こす可能性が高いと思います。ただし自動テストで要素の有無によって判断する場合は検出できる可能性はゼロです。その場合は、画像比較などによって判断するなど自動化の実現方法を検討する必要があります。テストケースだけみると細かな点なのですが、不具合検出漏れにもつながるので非常に重要なポイントになります。
まとめ
テストケースはテスト実装者にとっては仕様書で、テスト開発における重要なものであることを書きました。自動テストのことで気づかされたことではあるのですが、もちろん手動テストを実施する場合でも同様に重要となるものです。上記で紹介した事例も手動テストでも起きうるものです。自動テストの場合、よりそれが厳しく、悪い方向に影響してしまうのです。手動テストでは補ってもらえることを期待できるのですけどね。自動テストを考えていると、テスターの気づきに甘えていていたことに気づかされることが多いです。