人間はミスをする生き物です。
そんな人間がプログラム書くのですから、そこには当然バグが混入します。
ITエンジニアが仕事の成果物としてプログラムを仕上げる際、バグをなくすために必ず「テスト」をします。
様々な入力や操作のバリエーションを想定し、作成したプログラムが正しく動くことを確認、バグがあればプログラムを修正し、再度「テスト」を行います。
この、「バグを出して修正を繰り返す」工程、プログラムの「品質向上」のためにとても重要なのですね。
最終的にすべてのテストにOKが出れば、プログラムの「品質が担保された」ことになります。
さて。
とても優秀なプログラマAさんと、あまり優秀でないプログラマBさんが、全く同じ機能をもつプログラムをそれぞれ作ったとします。
それぞれの完成品に対して同じテストを行った場合、どうなるでしょうか?
Aさんのプログラムはほとんどバグを出さずにテストを一発ですべて終了しました。
対してBさんのプログラムは「バグ-修正」を何度も繰り返し、ずいぶん時間をかけてテストを終了しました。
AさんのプログラムとBさんのプログラムは何が違うか?
Bさんのプログラムに「単純なミス」が多いわけではありません。
そもそもの「つくり」が違うのです。
Aさんのプログラムは、要求された機能を実現するために必要な処理を、極めて論理的に構造化し、モジュール内分岐のとても少ない、見ただけで「ああ、これは頑丈だ」というプログラムになっています。
Bさんのプログラムは行き当たりばったりというか、書きながら「あ、この処理も入れなきゃ…」とその場しのぎでステップ増やしていったようなつくりになっています。
おそらくAさんは最初から「バグなど混入する隙がない」ことを意識しながらプログラミングしていることでしょう。
テストのバリエーションなど、ハナから想定済みで。
そんなAさんにとって「テスト」とは、単に「品質担保」するためだけのものです。「品質向上」の必要がないので。
「我がプログラムにテストなど不要!」
そう豪語するような優秀な下流工程エンジニアが、この国にもっともっと増えることを、私は願っています。