テストケースをどのように作成したら効率的なものが作成できるか日々勉強しているときに、色々な書籍を読んだりしているといつも疑問に感じることがあります。
例えば、入力Editがあるときに、仮に最大入力文字数が半角で50文字まで入力できるものがあったとします。
そうしたときの最大入力文字数の確認として、半角で50文字・51文字、全角で25文字、全角で26文字といったことをあげている場合があります。
仮に、Windowsアプリを作成したときに、これらの半角・全角といった場合わけが必要かといわれると、私は必要ないのではないかと思います。
なぜなら、これは使用する言語にもよると思いますが、使用する言語のコンポーネント側で制御しているからです。変な実装で、キーの入力をしている場合を除いてですが...
単純な例でありますが、これらを考えると本当に必要なテストケースというのはなんだろうという疑問が湧いてきます。
境界値分析の例としてはこれらを抽出するのはいいと思います。
まだまだ勉強不足なので、いつも戸惑いながらテストケースを作成しています。
こんな疑問を持つ人は少ないと思いますが、私はいつも疑問に感じていることです。
例えば、入力Editがあるときに、仮に最大入力文字数が半角で50文字まで入力できるものがあったとします。
そうしたときの最大入力文字数の確認として、半角で50文字・51文字、全角で25文字、全角で26文字といったことをあげている場合があります。
仮に、Windowsアプリを作成したときに、これらの半角・全角といった場合わけが必要かといわれると、私は必要ないのではないかと思います。
なぜなら、これは使用する言語にもよると思いますが、使用する言語のコンポーネント側で制御しているからです。変な実装で、キーの入力をしている場合を除いてですが...
単純な例でありますが、これらを考えると本当に必要なテストケースというのはなんだろうという疑問が湧いてきます。
境界値分析の例としてはこれらを抽出するのはいいと思います。
まだまだ勉強不足なので、いつも戸惑いながらテストケースを作成しています。
こんな疑問を持つ人は少ないと思いますが、私はいつも疑問に感じていることです。
次の画面で入力データが表示される場合などは、
ブラックボックス的な観点で「泣き別れ」しない
ことがチェックされるようなテスト設計がベター
じゃないでしょうか。
# どちらかというとエラー推測になりそうですね
ありがとうございます。
確かに「泣き別れ処理」には必要ですね。
このあたりがテスト設計の難しいところですね。
どこまで含めるかなどを考えると、ケースが爆発的に増えてしまうし、含めないと足りなさそうだし。
僕の場合は、そうなっちゃったときはテストケース設計はまじめにして、あとから実施するケースを選択するとか、優先順位をきちんと決めておくとかする方法をとったりします。
（実施カバレッジが100%にはならなくなっちゃいますが）
未実施テストケースも、レビューチェック用とか、リスクとして頭の隅に入れておくとか、いろいろ使えたりするかも？
# 僕の我流なので一般的ではないかもしれません
確かに、テストって、やってみるまでわかない場合がコーディングよりも多いと思います。だから、工数がこれくらいだろうと経験と勘で判断してしまうのだと思います。
テスト実施するケースを選択するのはいい手ですね。
前に一度だけ行ったのが、どうしても工数が足りなくて、優先順位をつけて、優先順位の高い順に虫食い的にテストを実施しました。