テストケースの作り方

ITソリューション事業部 第1開発部の塚本です。

秋。。。秋といえば枯葉ということで
「枯葉」が入った名盤を引っ張り出して聞いています
秋の夜長にウィスキーでも飲みながらどうぞ。（私はエビスですが）
Miles Davisの名盤です（個人の感想です）
Walkin’ – A Jazz Hour With The Miles Davis Quintet

さて、ここ最近、テストケースの作り方で思うところがありました
なので、自分なりのテストケースの作り方をまとめてみました（個人の偏見です）

1.仕様を理解する
　これが意外とできていない
　理解と記憶するは違います
　仕様を理解してください、理解しようとしてください。
　わからないことは開発者や、お客様に聞いてください。（鬱陶しいくらいでいいです）
　ただし、よくわからないときに、よくわからないですと聞かないほうがいいと思います。
　（仕様書に書かれていることをそのまま回答されるだけです）
　わからないところは自分なりに埋めてみてください
　そのうえで、こういう理解したけどあってる？みたいな質問のほうが相手も答えやすいと思います

2.テストで確認すべき大枠を考える
　どんなことを確認しないといけないかを大枠で考えます
　大枠です、細かいことは考えずに大枠です
　ここで詳細に考えちゃってる人がいると思いました
　ここで詳細に考えると、たいていテストケースになっちゃってて、
　漏れてるかどうかがわかりにくいと思います

3.詳細を考える
　あくまで、これ以上大枠でわけられない場合です。
　詳細を考えてください。
　思いつく限りのパラメータを出してみましょう（細かい自分がキモイと思うくらいでいいです）
　思いつく限りの運用パターンを考えてみましょう（自分がユーザーになりきってみましょう）
　ちょっとあり得ないことも考えてみましょう（自分のあり得ないは他人にはあり得る場合がある）

4.テストケースにしましょう
　あらゆる手段を講じてテストケースにしましょう。
　この時、ズブの素人がやっても、
　テストに慣れている人がやっても同じ結果になるように手順はわかりやすく書きましょう
　けっこう作ってる人だけがわかるテストケースを見ます
　自分で作って自分でやるからいいとか言わないで、だれでもわかるように作るくせをつけてください
　（誰に見られるかわからないから）
　また、ここで手順や期待結果を作るときに、新たに不明点が出ると思います
　（出ないときはちょっと3が甘い可能性があります）
　出た質問は開発者やお客様に聞いてください（やはり鬱陶しいくらいでいいです）

5.思い切って削除してください
　テストを作りすぎてる可能性があると思いますので削除してください
　削除できずにテスト工数を無茶苦茶取る場合がありますが、あまりよくないです。
　（バグの出ない不毛なテストを延々とやることに）
　意味のあるテストをしましょう。
　ただし、削除する理由は自分なりに考えたり、次のレビュー時にレビュー観点としてお願いしましょう
　そうして、説明できそうなら削除してください
　理由もなく（なんとなくで）削除はダメです

6.レビューしてもらってください
　いろんな人にレビューしてもらってください
　レビューを受けて漏れを減らしたり
　わかりやすいテストケースにしたりしましょう
　レビューでどういうところを見てほしいかは明確につたえましょう

おまけ.臨機黄変に行きましょう
　固定概念はよくないです、必要に応じて変化させましょう
　たとえば過去に作成されたテストケースがある場合、それを参考にするのはいいですが
　わかりにくいところまで踏襲することはありません、テストケースがわかりにくくなったり
　やりたいことができないなら、変更する動きを取りましょう

自分自身への戒め的にグダグダ書いてみました
参考になれば幸いです。
チャンスがあれば、いっぱいテストケースを書いてみてください（習うより慣れろです）