また、遅れてしまっています。すみません。

開発が終わったら、絶対あるのが「テスト」。
格好良く、テスト駆動開発なんてやってみたいものですが、
まあ、小規模でやっているとテスト駆動開発っておいしいの？って感じで
ついつい、後回しになってしまいます。

テストについて主観で語ります。

テストって何？

テストっていろいろあるけど、開発側が行うのが、
・単体テスト
・ユニットテスト
・結合テスト
・納品前テスト

のテストが大雑把にいってこんな感じ

テストの種類

具体的に言うと

・単体テスト
　⇒開発者が仕様書の要求通りに動作するか確認するテスト
　⇒ソースコード単位か、機能単位で実施
　⇒バグというよりは、動作しないことが多い

・ユニットテスト
　⇒開発者もしくは管理者（ＰＬくらい？）が仕様書の要求通りに動作するか確認するテスト
　⇒機能のまとまり（登録から表示、編集、削除くらい）で確認
　⇒複数のソースコードのまとまりをまとめてテスト
　⇒結構、バグが大量発生する

・結合テスト
　⇒開発者、管理者、テスト担当者が仕様書の要求通りに動作するか確認するテスト
　⇒システム全体を確認
　⇒システムとしてのデータの整合性や機能の整合性も確認
　⇒手戻りややり直しが大量発生する

・納品前テスト
　⇒お客さんに納品もしくは、サービスリリース前に最終確認するテスト
　⇒最終確認なので、バグは出してはいけない
　⇒バグが出た時は大変な事になるよｗ

・検収テスト
　⇒受託開発の場合、お客さんが確認するテスト
　⇒まあ、ここで出てくる問題は、機能追加の要求だったり改修要求がほとんど
　⇒お金の話になるので、管理者や営業に任せようｗ

こんな感じ

よくやるテストの流れ

じゃあ実際どんなテストをやるのか？

１．単体テスト
　⇒コード開発者の責任です。

２．ユニットテスト
　⇒詳細仕様作成者の責任です。
　⇒機能矛盾を開発者は指摘してあげましょうｗ

３．結合テスト
　⇒プロジェクトメンバー全員でバグを見つけましょう。

４．モンキーテスト（フリーテスト）
　⇒プロジェクトメンバー以外もしくは仕様を理解していない人に、
　　とりあえず全部のリンクやボタン、メニューを使って貰って、エラーが出ないか確認
　⇒開発者だと、エラーが出やすい場所を無意識に避けていたりするので、仕様を知らない人に
　　全部触ってもらってエラー画面が出ないくらいかの確認はしましょう。
　⇒最近、これをやらないプロジェクトが多いね。。。

５．ブラックボックステスト
　⇒テスト仕様書通りに、テスト担当者が動作チェックを行う。
　⇒「○○ができる」とか「××を入力して、△△になる」なんていうテスト仕様書。
　⇒正常系とエラーをわざと発生させる異常系をやる。

６．ホワイトボックステスト
　⇒開発者とテスト担当者がペアになって、テスト仕様書通りに操作し、内部のデータ状態を確認する。
　⇒内部処理と外部処理が正しく行われているかをチェックする。
　⇒ここまでやれば、バグはほとんど潰れているはず。

７．納品前テスト
　⇒管理者（ＰＬ）とか営業にやらせましょう。
　⇒お客さんに納品するまたはサービスリリース前のテストなので、自分たちで最後は責任を取れって感じでｗ

８．検収テスト
　⇒これは、受入テストなので、まあどれくらいテストをやるかはお客さん次第。

こんな感じ。

テストって自動化したいよね

最近流行のジェンキンスおじさんとか、サークルＣＩとかテストを自動化するツールと言われているものは
あるけど、基本、コードを書いた人がきちんと単体テスト（デバッグとも言う）をすることが大切だと思う。

PHPだとPHPUnitやRuby on RailsだとRSpecがあったりするけど、InputとOutputの確認だけなので、
処理ロジックの正当性まではチェックしてくれない（と思っている）。
否定はしないよ。

自動化も結構だけど、自分でデバッグやスタックトレースを読める力を付けることが重要だよ。