また、遅れてしまっています。すみません。
開発が終わったら、絶対あるのが「テスト」。
格好良く、テスト駆動開発なんてやってみたいものですが、
まあ、小規模でやっているとテスト駆動開発っておいしいの？って感じで
ついつい、後回しになってしまいます。
テストについて主観で語ります。
テストって何？
テストっていろいろあるけど、開発側が行うのが、
・単体テスト
・ユニットテスト
・結合テスト
・納品前テスト
のテストが大雑把にいってこんな感じ
テストの種類
具体的に言うと
・単体テスト
⇒開発者が仕様書の要求通りに動作するか確認するテスト
⇒ソースコード単位か、機能単位で実施
⇒バグというよりは、動作しないことが多い
・ユニットテスト
⇒開発者もしくは管理者（ＰＬくらい？）が仕様書の要求通りに動作するか確認するテスト
⇒機能のまとまり（登録から表示、編集、削除くらい）で確認
⇒複数のソースコードのまとまりをまとめてテスト
⇒結構、バグが大量発生する
・結合テスト
⇒開発者、管理者、テスト担当者が仕様書の要求通りに動作するか確認するテスト
⇒システム全体を確認
⇒システムとしてのデータの整合性や機能の整合性も確認
⇒手戻りややり直しが大量発生する
・納品前テスト
⇒お客さんに納品もしくは、サービスリリース前に最終確認するテスト
⇒最終確認なので、バグは出してはいけない
⇒バグが出た時は大変な事になるよｗ
・検収テスト
⇒受託開発の場合、お客さんが確認するテスト
⇒まあ、ここで出てくる問題は、機能追加の要求だったり改修要求がほとんど
⇒お金の話になるので、管理者や営業に任せようｗ
こんな感じ
よくやるテストの流れ
じゃあ実際どんなテストをやるのか？
１．単体テスト
⇒コード開発者の責任です。
２．ユニットテスト
⇒詳細仕様作成者の責任です。
⇒機能矛盾を開発者は指摘してあげましょうｗ
３．結合テスト
⇒プロジェクトメンバー全員でバグを見つけましょう。
４．モンキーテスト（フリーテスト）
⇒プロジェクトメンバー以外もしくは仕様を理解していない人に、
とりあえず全部のリンクやボタン、メニューを使って貰って、エラーが出ないか確認
⇒開発者だと、エラーが出やすい場所を無意識に避けていたりするので、仕様を知らない人に
全部触ってもらってエラー画面が出ないくらいかの確認はしましょう。
⇒最近、これをやらないプロジェクトが多いね。。。
５．ブラックボックステスト
⇒テスト仕様書通りに、テスト担当者が動作チェックを行う。
⇒「○○ができる」とか「××を入力して、△△になる」なんていうテスト仕様書。
⇒正常系とエラーをわざと発生させる異常系をやる。
６．ホワイトボックステスト
⇒開発者とテスト担当者がペアになって、テスト仕様書通りに操作し、内部のデータ状態を確認する。
⇒内部処理と外部処理が正しく行われているかをチェックする。
⇒ここまでやれば、バグはほとんど潰れているはず。
７．納品前テスト
⇒管理者（ＰＬ）とか営業にやらせましょう。
⇒お客さんに納品するまたはサービスリリース前のテストなので、自分たちで最後は責任を取れって感じでｗ
８．検収テスト
⇒これは、受入テストなので、まあどれくらいテストをやるかはお客さん次第。
こんな感じ。
テストって自動化したいよね
最近流行のジェンキンスおじさんとか、サークルＣＩとかテストを自動化するツールと言われているものは
あるけど、基本、コードを書いた人がきちんと単体テスト（デバッグとも言う）をすることが大切だと思う。
PHPだとPHPUnitやRuby on RailsだとRSpecがあったりするけど、InputとOutputの確認だけなので、
処理ロジックの正当性まではチェックしてくれない（と思っている）。
否定はしないよ。
自動化も結構だけど、自分でデバッグやスタックトレースを読める力を付けることが重要だよ。