ユニットテスト

1.3 一か八かの勝負 1.4 なぜウォーターフォールは機能しないのか？ 1.4.1 レシピと公式 1.4.2 開発とテストの分離 内容 ウォーターフォールで最後に統合するのは一か八かの賭けに似ている。 多くのバグは統合フェーズで見つかる。これがコストが高くなる理由。 再テストとコードの再統合に多くの人手が必要になる。ある領域で加えた変更が、ほかの多数の領域に影響を与える可能性がある。そのため、システムのいかなる箇所にいかなる変更が加わった場合でも、再テストをするのが賢明ということになる。さらに、これが手動のプロセスのままだと、途方もないコストがかかる。 何かをものを作るとき、ものごとをまとめてやるというのは直感的には正しそうに見える。たとえば、家づくりであれば基礎を作るのに必要なものすべてを現場に渡したい。そうすれば追加のコンクリートや何かを待って止まることもないから。 しかし、ソフトウェアの場合はまとめてやろうとするのは上手くいかない。 ソフトウェアの場合、物理的なものと違い、設計が変わる可能性が高い。まとめて作業するということは、その分は変更しないで進めるということを意味する。 料理のレシピは、レシピ通りにやれば誰が作っても同じようなものができる。 ソフトウェア開発の場合、ある場面では正しいことがある場面では間違っていることが多く、実質他のレシピと同じようには作れない。 ウォーターフォールでは開発とテストのフェーズを分離し、最後のQAでリリース候補のテストを行う。そして出たバグをその時点から修正する。 バグはプロジェクトの終盤であればあるほど、修正にコストがかかる傾向があるので、リリースは遅れる。（もろもろの修正手続きだったり、密結合による難易度だったり） 開発とテストはもっと近くなければならない。 学び 最後に問題が出るのが一番コストがかかる 常に全統合で自動テストを行う環境にしておけば問題の先送りは防げる ウォーターフォールは設計と開発のフェーズを分けているため、設計変更の仕方に柔軟性がなくなる。ウォーターフォールの契約やプロセスに無理に当てはめて進めようとすると、設計変更しないと問題が出るような箇所に対応するタイミングが遅くなる可能性が高い。その遅さは、今の時代の変化についていくためのリスクになる場合がある。 ソフトウェア開発をレシピで例えるなら、１つ１つが料理自体が違うくらい違うと思う。 関連する人や業界が違えば、工程の順序も違ってきておかしくない。もちろん、ビジネスによって内容も違う。 開発とテストは近いほうがよい。間違いは速くに見つけられる方が、より根本的なプロセス改善につながる。 学びを活かすアイディア ウォーターフォールに頑なにこだわっているプロジェクトには入らない TDDの実践