前説

普通のウォータフォールの開発工程で、テストケースを作るときにどうゆうところに気をつければいいのか、って記事です。

観点

スタートとなるのは、そのテストで何を確認したいのかを意識すること。
黙々とマトリクスを作ったりしてると、これを忘れがちです。
ケースの作成は手段であって目的ではありません。
工数との兼ね合いかと思いますが、思考迷子になったら初心に立ち返りましょう。
単体、結合、総合、って感じで規模が大きくなっていくので、その規模に合わせてケースを考えます。
その場合、テストの単位が小さいほど人間性を排して網羅的な思考が必要となり、大きくなるほど業務的なユースケースを想定した思考が必要になります。

単体

ここでいう単体は、一番小さい単位のテストを指しています。
単位テストは基本的に処理の分岐が確認したいです。

if (varNumber < 100)

↑こうゆうのが出てきたらvarNumberが100より下のパターンと100以上のパターンをやろう、ってことです。
また、その場合境界値でチェックするのが基本です。

if (varNumber < 100 || varNumber2 < 50 ) 

↑条件が二つ出てきた場合、真偽値がそれぞれ「true:true」「true:false」「false:true」「false:false」のパターンはやっておくべきかと思います。

if (varNumber < 100 || varNumber2 < 50 ) 
  if (varChar == "hoge" || varChar2 == "hogee") {
    // いろいろ処理
  }
}

↑これは条件が4つあるので本来は2の4乗のパターンでやるのが理想かと思います。
ただ、処理のところでも分岐があったりすると膨大な数になるので、Numberの4パターン、Charの4パターン、という風に似た意味の分岐でわけて実施するのが現実的です。

multiNumber = varNumber * varNumber2;

↑四則演算が出てくるところは注意が必要で、上限値がいくつになるのか、小数点はどこまで許容するのか、など考慮しつつケースを作成する必要があります。

ここらへんは機能のことを考えつつ取捨選択の必要がありますし、プロジェクトの方針に沿ってよしなにやりましょう。

結合

結合は機能と機能をくっつけて行うテストなので、機能同士の連携とデータの受け渡しの確認が主です。
機能Aで作ったデータを利用して、機能Bがちゃんと処理してくれるかを見ます。
ありえるエラーパターンとしては、機能Aで作ったデータの型や値の範囲が機能Bで許容できないものだった、などです。

・APIとの結合
この場合、エラーコードのパターンを見ておく必要があります。
WebAPIを呼ぶ際、不正な値を渡してるつもりなのにHttpStatusCode500を返してくるのはおかしいよね、って話です。

・Web画面での結合
フロントエンドだと画面遷移が観点に入ってくるので、起こりうる遷移パターンを網羅するケースを考えます。

総合

呼び名は色々あるかと思いますが、システム全体を通してのテストを指しています。
システムとしてのテストなので、要件を満たしているか、がすべてです。
実際に運用するときのことを想定し、存分にユースケースを考えましょう。
結合まで行っているのであれば機能としての繋がりは保証されているはずなので、このフェーズでエラーが出ることはそうありません。
無いと信じたい。

おわり

もともとテストケースのわかりやすい書き方の記事のつもりだったのに観点の話だけで終わってしまった。