■テスト項目をコーディング前に作成して、テスト項目にそって実装及び動作確認（単体テストじゃない）を行うのは、かなり効果的。 テスト項目自体の漏れはどうにもならないが、テスト項目の実装漏れは防げるし、 進捗具合がかなり詳細なレベルで把握できる（テスト項目の全項目中、何項目まで作業終了してるかがわかるので）。 基本的に詳細設計、テスト仕様書とコーディングを同じ人が行って、最終的な単体テストを他の人が行う進め方が効果的な気がする。 詳細設計、テスト仕様書、コーディング、単体テストをそれぞれ別の人がやったりすると、 プラス面よりも仕様の理解不足などによるマイナス面のほうが相当大きいと思う。 単体テストに限っては、コーディングした人がテストするのはできるかぎり止めた方が良い。 厳しくテストしなくちゃいけないのは分かっているけど、結局どこかしら手を抜いてしまう可能性大。 と言うか、無意識のうちに無茶なテストは避けてしまうので、実装を知らない人がテストした方が絶対に良い。 テストする人が事前に仕様を理解する時間が必要となるけど、これは仕方ない。
■テスト項目の追加、削除が簡単にできるようにテスト仕様書のフォーマットを設計する。 テスト項目を追加したり削除したりして既存の項番がずれた結果、 その項番を参照している別のドキュメントも修正しなくてはならないようなフォーマットだと、 テスト項目をメンテナンスしたくなくなる（リンク元ドキュメントの項番も自動で変わるとかだったら別に問題ないとは思うけど）。 できれば、項番は自動で採番されるのが良いと思う。 項目を挿入したり削除したりした後にそれ以降の項目の項番を手動で変更するのは、結構手間。 でも、本格的なテストに入った後だと、逆に既存の項番が変わっちゃうのはまずいかも。状況にもよるだろうけど。
■不具合の管理には、できればバグトラッキングシステム（BTS）を使う。 エクセルなどで簡単に管理するのも良いが、ある程度の量になると色々と大変になってくる。 ステータスの正確な管理、ステータス別の件数や担当者別の不具合件数などなど便利な機能はたくさんある。 利用するまではかなりめんどくさいかもしれないけど、一度利用しだせばExcelなんかの管理には戻れないはず。
■プログラムの単体テスト期間（テスト、デバッグ作業。もちろんテスト仕様書作成は含まない）は、 今までの経験から言って最低でもコーディング期間の4割、できれば5割欲しい。 ただ、先にテスト仕様書を作成して、テスト仕様書に沿ったコーディング（実装）を行っているのであれば、 4割とれれば十分かもしれない（その分コーディングに時間がかかってるかもしれないけど）。
■境界値テスト
境界値テストはその境界値の2つの値をテストするのはもちろんだが、さらに外側に1つずつ余分にテストした方が良いかも。
例えば、10と11で処理が変わるのであれば、9,10,11,12をテストする。
そうすることで、等号で判定している時のバグを発見できる可能性が高くなる。例えば、
If XXX = 10 Then 〜 Else 〜 End If
のような感じで判定処理を行っていると、10と11の境界値テストでは問題ないかもしれないが、
もしかしたら9の時も10と同じ処理をしなくてはいけないかもしれない。
そういうバグを見つけるためにも、境界値付近の4つの値は境界値テストに入れた方が良いかも（もちろん場合にもよるが）。
■ファイルがロックされている状況を作りたい場合
ファイル削除時に対象ファイルが他プロセスによってロックされている状況を作りたい場合（テスト時など）、Excelで開くとロックするみたい。
メモ帳とか秀丸とかのエディタで開いただけではロックされなかった。
登録画面とかでは、必要最小限の入力データも試してみる。 意外と駄目だったりする（入力必須じゃないフィールドに値が入っていないとエラーになったり・・・）。
また、画面表示項目についても最小限のデータを試してみる。 こっちの動きについても、適切なNULL処理が行われていなければNULLを読み込んだ時点で駄目だったりする。