スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか
https://qiita.com/aimof/items/d68bdb347283ee2dbccf
この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。
に触発された記事です。
試験(test)について、プログラマに限定して、どれくらい立場の違いがあるかを記載します。
1. 装置運転(device driver)
どういう試験をしたら、IC, 装置(device)が機能したかを確かめる試験プログラムから書き始めることがあります。
監視(monitor)という機能の場合もあります。
類似の装置のプログラムを作ったことがある場合で、今回新たな想定していない機能はない場合には、すでに必要な試験の道具が揃っていて、試験プログラムを書く必要がないかもしれません。
2. OS, Kernel
POSIX Test Suiteのような仕様に対する試験があらかじめ用意されていて、それに通ればよい。
また、通らない項目は、顧客がOKすればよい。
すべてのOS, Kernelの機能が必要とは限らない。
試験をするのは、ほぼ自動でできる。
どの試験は、今回通らなくてもいいかどうかの判断が必要になることがある。
ここに判断するのが面倒だから、すべて通しておけという選択肢は好ましくない。
すべての機能を組み込むと、メモリの消費と時間の消費が増える可能性があり、
今回のシステムのメモリ消費と時間消費の目標値を達成しないかもしれない。
3. Package Soft
出荷の判定は、出荷側が決めることができる。
実際には、市場調査し、どのような試験を実施したものが、
受けがいいか、出荷後の反応がいいかなどに基づいて試験する事項を決める。
細かい点は、アルファ出荷期間、ベータ出荷期間の間の利用者からの報告などに基づいて修正してもよい。
細かい試験は、利用者にお願いするものである。
利用OSの種類、対応版の数、対応言語の数が多いと、出荷側での試験は至難の技である。
同時に動いているソフトウェアによる挙動の違いなど出荷側よりも、実際に利用側で試験してもらった方が楽なこともある。
4. 請負
請負仕事の場合に、顧客から受け入れ仕様が提示されていなかったり、顧客側が受け入れ試験をしない場合に、試験をせずに出荷する選択肢はありうる。
顧客側から受け入れ試験ソフトを渡され、請負側で試験をすることもある。
顧客側から受け入れ試験ソフトの開発を委託され、請負側で試験をすることもある。
試験をせずに出荷するのは、顧客側が受け入れ試験ソフトの開発を委託していないことが悪いのかもしれない。