テストケースのひな形

基本的なテストケースのひな形を書いておく

ID	テスト内容	前提条件	インプット/手順	期待結果	実施日	テスト結果
1	ユーザの新規登録	特になし	step1:ユーザ登録画面を起動する step2:ユーザ情報を入力する step3:登録ボタンをクリックする	ユーザ一覧に登録したユーザが表示されること	2010-06-11	OK,NG,NT(not test:廃止)

テストケースの上げ方について

今日はテストケースのデータを上げる際に気をつけていることを簡単に書きます。

１．数値のゼロ、文字のブランク
　　これらの値はプログラマが考慮していない場合が多いのでケースに上げています。

２．境界値
　有効な範囲の境界となる値です。例えば３～6が有効な値だった場合、

• 正常ケースで３と６
• 異常ケースで２と７

　を上げるようにしています。

３．意地悪な値
　「１．」と同じような考え方ですが、何とかしてバグを見つけてやる、こんな値は考慮してないだろう、どうだー！？っていう値を考えますｗ。
　
以上です。（たった３つかよ！何か忘れている気がしなくもないですが・・・
箇条書きにするとたった３つですが、この３つが頭に入っていれば十分な品質が確保出来るんじゃないでしょうか？

テスト駆動型開発の基本的な考え方について

今日はテスト駆動型開発の基本的な考え方について書きます。(間違ってたらすいません）
テスト駆動型開発って聞くとすごく難しい感じがしますが、

コードを書く前にテストケースを上げる

ただそれだけのことです。
テスト駆動型開発によって得られるメリットは

• 仕様を把握していないとテストケースが作れない、つまり仕様の理解を深めることが出来る、あいまいな部分をなくすことが出来る。
• 仕様の理解を深めることによってバグが少ない、かつ拡張性が高い、かつメンテナンスしやすい設計が出来る可能性が高くなる。
• 仕様に矛盾や問題があるとテストケースが作れない、つまり仕様書レベルでバグをつぶすことが出来る。

などです。
私が以前関わっていたプロジェクトではテストを自動化し、

1. 仕様書を確認する。
2. テストケースを上げる。
3.  「１.叉は２.」で仕様書に矛盾や問題が有った場合は仕様書を差し戻す。
4. 自動化の為のテストケースコードを記述する。
5. 設計＆実装
6. テストケースを通す。

のような手順で開発して、毎朝その日の最新ソースで全てのテストコードを実行し常に品質を確保していました。