バグ退治はいつやるべきか - PART1 |
||
|
バグって何? |
||
|
バグを完全に排除するにはどうすれば良いでしょうか?つまり、バグを全く埋め込まずにソフトウェアを開発することができるでしょうか?答えは明らかですね。そんなことはできません。開発工程の大部分に人間が介在する以上、誤りを100%なくすことは不可能です。そこで、ソフトウェアの出荷までに可能な限り多くの(願わくば全ての)バグを発見・修正するためにどうすれば良いのかを考えることになります。 |
||
|
バグ退治はいつやったらいいでしょう?テストの時でしょうか?実際、テストでデバッグしているプロジェクトチームは多いかもしれません。でもそれは正しいでしょうか?テストでデバッグをするチームでは、暗黙のうちに次のような定義をしていないでしょうか: バグとは、プログラムの挙動が仕様と一致しないことがユーザーの目にとまる現象のことである この定義は正しくないと思います。ユーザーの目に触れるかどうかに関わらず、また挙動が正しく見えるかどうかに関わらず、作り手の思惑と違った動作をするプログラムは誤りを含んでいると考えるべきです。つまり: バグとは、プログラムの挙動がその作成者の想定と異なる現象のことである |
||
|
従って、たまたま仕様通りでもプログラマが想定した動作をしていなければバグです。また、プログラマの想定通りに動いているのに仕様と食い違っているというのは別の問題です(人間同士のコミュニケーションの問題ですね)。バグがユーザーの目に触れるかどうかというのも別の問題です。 |
||
バグ退治はいつできるか |
||
|
ソフトウェア会社の管理職やソフトウェアのユーザーにとって、バグが発生するのはバグが発見された時でしょう。しかしそれは、厳密に言えば、「バグが発生した」のではなく「バグの存在が問題として認識された」ということです。実際には、バグは見つけたときに発生するのではなく、見つけるよりずっと前から存在しているのです。そして、発見されたバグのうちのほとんどはコーディングの段階でまぎれこんだものです。 |
||
|
だとすると、バグを退治できるのはいつからいつまでの間でしょうか?当然、バグが作り込まれた後でなければ、バグを修正することはできません。そしてテストが完了するまでになんとかしたいわけです。ですからバグ退治はコーディングの開始時点からテストの終了時点までの間に行うことができます。この期間内で、もっとも効率よくバグを発見・修正するにはどうしたら良いかというのが問題です。 |
||
|
|
|
|
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)