はじめに
テストケースを見ることがあるが気になることが多いのでポイントを記載することにした、気の向くままに書いてみる
赤い糸で紐づける
テストケースは何を基に作成したのかをわかるように紐づけておく
そうすることで、仕様に記載されている内容のテストに漏れがないことが判断できるようにする
また、リリース後に問題が発覚したときに、関連する機能に対してどのようなテストをしたのかが確認しやすくなる
ついでにいうとほんまにこのテストケースあってるの？って疑われた時に調べやすいです(私はすぐに疑います、自分で作ったものすら疑います)
理想は、仕様⇔テストケースが相互に追いかけられること
例：仕様書ｘｘｘを基に作成しました
紐づくリンクを貼り付けておく
目的が大事
どのような目的・意図なのかを記載する(一目でわかるように)
記載されているとテストする人にやりたいことが伝わりやすいためです
手順と期待結果だけが記載されていても、ポイントが伝わらずに、流出につながることもある。
また、目的・意図が記載されていると、手順を読まずともやりたいことがわかるのでレビューしたり、テストケースを探しやすくなる
個人的には、仕様が変わったなどで、同じ手順でテストができないことが判明した場合に、目的・意図があれば、テスト手順を修正して残すべきなのか、テスト自体が不要なのかの判断がしやすいと思っている。
例：保存ボタンを2回押下するというテストがある、しかし目的の書き方を変えるとやりたいことが変わってくる。
目的：保存ボタンを連続で二回押下してもデータが二つ作られないことを確認したい
目的：保存ボタンを押下すると、ボタンが非活性に変わるので二回目の押下は無効であることを確認したい
誰がやっても同じがいいんです
極端な場合は、仕様だけ記載されていて、手順も何もない場合がある
これでは人によって手順がことなり、結果が変わる可能性がある
あと、別の人(または未来の自分)が再実施するときに苦労するだけなので、手順は丁寧に記載するべきだと思う。
正しくってなんですか？
期待結果に良くあるのが「正しく動くこと」
正しくって書くのは楽だけど、どうだったら正しいの？の「どう」の部分をしっかり記載する
しっかり記載しておかないとどっかで見落として、流出するから
例
・何が表示されていたら正しいの？
・どのようなデータが作られていたら正しいの？
・どこで挙動すれば正しいの？
・何秒で切り替われば正しいの？
・どれが動けばいいの？
終わりに
フォーマットなんかはいったん自由でいいと思うんですが
以下を満たすようなテストケースを作ることを意識してもらえればなーと思いました。
・何を基にしたのかがわかる
・何をしたいのかがわかる
・どうすればできるのかがわかる
・何を確認すればいいのかがわかる
異常ではなく以上