私は、テストに入る前に、ゲリラテスト(モンキーテスト)をしています。
なぜ、そのようなことをしているかというと、作成したソフトウェアをあまり考えず(多少は考えます)動作させることで、バグをある程度出しておきたいと考えているからです。
ある程度は、TDD(テスト駆動開発)で進めて、自動化できる部分はしておきますが、どうしてもViewの部分は、目視で確認しないとならないために、制御できていない箇所などを見つけるためにこのテストを取り入れています。
よくテストの本には、あまりよくないことであるとか、してはならないみたいなことが書かれています。
確かに私もバグを狙ってテストケースを作成しているので、よくないことだとは思います。
しかしこのテストをするおかげで、終盤になって見つかるようなバグが発見されたり、頭の中を切り替えて、バグを出して後になって自分が楽できるようになるからと思い、頭の中ではある程度、バグを狙って動作はさせています。
やはりこのように常識だけにはとらわれないで、テストすることも必要ではないかと最近感じます。
なぜ、そのようなことをしているかというと、作成したソフトウェアをあまり考えず(多少は考えます)動作させることで、バグをある程度出しておきたいと考えているからです。
ある程度は、TDD(テスト駆動開発)で進めて、自動化できる部分はしておきますが、どうしてもViewの部分は、目視で確認しないとならないために、制御できていない箇所などを見つけるためにこのテストを取り入れています。
よくテストの本には、あまりよくないことであるとか、してはならないみたいなことが書かれています。
確かに私もバグを狙ってテストケースを作成しているので、よくないことだとは思います。
しかしこのテストをするおかげで、終盤になって見つかるようなバグが発見されたり、頭の中を切り替えて、バグを出して後になって自分が楽できるようになるからと思い、頭の中ではある程度、バグを狙って動作はさせています。
やはりこのように常識だけにはとらわれないで、テストすることも必要ではないかと最近感じます。
参考になるかわかりませんが、私なりの方法です。
モンキーテストですので、テストケースがないものになりますので、今までの経験と実装した個所で、このパターンはどうだろうと試して行います。
基本的には頭のなかで、同値分割・境界値分析を行いながら、行います。
View周りは特に今までの経験に左右されるかもしれません。
具体的には、ある入力するテキストボックスがあった場合に、最大入力文字数を設定した場合に、その制御がされているか?や数値入力の個所に、文字が入らないかなどです。