品質保証なんて糞食らえ。職人による品質向上のためのテスト(1)

あー、まとまってきたら会社で使うネタ。今はバラバラと書いてく。

どれだけテストをしても、バグがない事は証明できない。
でも、バグが無いと自信を持つ事ならできる。次のプログラムを見て、バグが無いと自信を持てるだろう。

// VSyncで使う設定値
int display_setting_a;
int display_setting_b;

void set_display_setting(int isNtsc)
{
    if( isNtsc ){
        display_setting_a = DISPLAY_SETTING_A_FOR_NTSC;
        display_setting_b = DISPLAY_SETTING_B_FOR_NTSC;
    }
    else{
        display_setting_a = DISPLAY_SETTING_A_FOR_PAL;
        display_setting_b = DISPLAY_SETTING_B_FOR_PAL;
    }        
}

「見てバグが無いと判る」ほどシンプルなら、自信を持ってそのコードを出荷できる。そして、良いプログラマほどシンプルなプログラムを書く。プログラマの能力は品質に直結している。

さて、品質保証のために、「編集した関数はすべてテストすること」というルールがあるとする。この関数をテストする事で、品質は上がるだろうか?そんな事はない。むしろ、この関数をテストしたりテスト仕様を書いたりテスト報告書を書いている時間により、別のところにあるバグを見つける時間を失っている。不必要なテストは品質を下げる。納期が決まっている以上、効率こそが品質なのだ

じゃあ問題だ。クイックソートを実装してみて。実装できたら、そのコードがテスト無しに正しいと言い切れるか自問してみて。僕にはムリだ。複雑さはよーく分析すればシンプルに解決できる事が多いけど、本質的に難しいものはそれ以上簡単にはならないからね。
そして、難しい関数があるとき、それが本当にテストを必要としている関数だ。何が不安(=バグがありそう)なのかを考えて、不安がなくなるまでテストしよう。

このブログに乗せているコードは引用を除き CC0 1.0 で提供します。