HEXA BLOG

いいモノづくり道

HEXA BLOGいいモノづくり道2010.9.24

いつ、どのくらいテストするか

気が付けば、東京ゲームショウに行ってからもう1週間が過ぎてました。
月日の流れは、なかなかの超特急です新幹線
もうちょいブレーキを踏んで欲しいと思う今日この頃。
こんにちは、ハラです。
ここ最近、ちょっとしたツールを作っていた絡みもあり、
テストについて少し書いてみたいと思いますひらめき
1つの例として、下のような流れで処理や作業が行われるケースで
考えたいと思います左斜め下
1.データ作成&コンバート
2.プログラムがコンバートされたデータを読み込む
3.読み込んだデータを使って色々な計算を行う
4.計算結果を使って描画する
ちなみに、私がプログラムを始めた頃(懐かしの学生時代・・・)は、
どんな時でも、全てが出来上がった後にまとめてテストすれば良いと思っていましたexclamation&question
この例なら、4の段階で正しく描画されていれば大丈夫だろうるんるん、と。
今の私には、この考え方だと2つの問題がある気がします。
1つ目は、テストで不具合が見つかった際、14のどの段階に原因があるのか、
すぐに見つからない事exclamation
2つ目は、14の段階で複数の問題があり、その影響で結果的に4が正しく動いてしまい、
不具合を見つけられない可能性がある事exclamation×2
1つ目の問題は、原因を見つけるために時間が多くかかってしまう、
というものなので、そこまで致命的ではないかもしれません。
(急いでいる時は、大きな問題になりそうですが……)
2つ目の問題は、致命的になる可能性を秘めていますがく〜(落胆した顔)
後々になって問題が表面化する可能性が残るからです。
表面化するのが、作品を志望する会社に提出した後、
実際に見て貰うタイミングだったとしたら……もうやだ〜(悲しい顔)
と、想像するとちょっと怖くなってきませんか?
最も確実な対策としては、14の全ての段階で
それぞれテストを行う事ですよね。
正しくデータが読み込まれているか?正しく描画が行われているか?など、
全ての段階でテストすれば、不具合が隠れてしまう可能性が最も低くなります。
ただ、最も確実ですが、最も手間がかかる事にもなってしまいます。
時間が限られている時は、もう少し手間を省きたい所です新幹線
12なら、2の段階でテストをすればデータの不具合は見つけられるはず。
データの正しさが保証されれば、34をまとめてテストしても不具合を見つけられるはず。
と、実際の処理に合わせて、行うテストを吟味していけば、
より良いテスト方法が見つけられるかもしれませんねひらめき
提出する作品の質を高める時間も大切ですが、正しく動作するかをテストする時間も大切です。
そして、使える時間には限りがありますあせあせ(飛び散る汗)
十分なテストを行いたいが、必要な時間を出来る限り減らしたい……
作品を作る段階からどのようなテストを行えば確実かを、多少意識しておくと良いのかもしれませんねるんるん

RECRUIT

大阪・東京共にスタッフを募集しています。
特にキャリア採用のプログラマー・アーティストに興味がある方は下のボタンをクリックしてください

RECRUIT SITE