バグを考える。。。

入力パターンが増えると全ての検証はなかなか出来ない。

入力項目が一つ増えると、入力、未入力の2通りは最低増える。
今まで4通りの入力パターンがあると仮定すると、一つ項目が増えたら最低8通りになる。

これはすごく単純な場合だが、いろんな操作方法が絡んだ場合、考えるのも嫌になるほどパターンが増える。入力の組み合わせパターンは検証しなくてもさほど問題は出ないが操作に関しては問題が出ることは多いし、操作方法自体思い付かないパターンが存在する。

全てのパターンを検証することは、すっごく簡単なプログラムでないと不可能だ。すごく簡単なものでも出来ないかもしれない。

そのために、総当りでは無く、どのようなパターンがまずいかを考えなければいけない。

バグを発見するのではなく、どういうパターンでバグが発生するかを考えることが必要だ。

うむぅ、かなりバグを考えて潰していっているのだが。。。というよりバグが発生すると考えられるパターンに制限を加えていっていると言うべきか。。。

一件、絶対、バグというよりデータに不整合が生じるため、制限を加えた入力項目があるのだが。。。制限を加えると不便かもしれない。

今回、計算した結果をいったんレコードに保存する処理が結構入っている。

いったん入力した後、変更すると計算結果に矛盾が生じる部分は全て制限を加えたのだが。。。

制限の撤廃を要請されたら、人の判断が必要な部分もあるので結構きつい。。。つーより満足する物を作るのは理論的に不可能かもしれない。でもある程度ならなんとか出来てしまうのが弱点か。。。絶対出来ないと言えたら良いのだが。。。

こういう部分が仕様変更や追加になるかはグレーである。

細かいこういう仕様が積み重なっていくんだよな。。。

まぁ、グレーゾーンを全て請けていては永遠に終わらないのは確かだ。。。

テストパターンは画面が増えたり項目が増えるごとに指数的に増えていくのだが、これもまじめに見積もりすると、1項目1円から始めてもすごい金額になるだろうな。

もしその見積もりが認められても、困るのだが。。。人を雇っても全ては検証しきれないし、全ての考えられるパターンを検証したとしてもバグは存在する。。。

デバッグをもしまじめにやることを要求されたら、まじ数千万でも足りないんだよな。。。
何故ならば一人では全てのパターンは検証できないし、全てのパターンを考え付かない。
人海戦術でやるしかないし、指数的に増えるパターンを潰すには何百人と必要だろう。。。。

数千人投入しても何故見つからなかったの?って簡単なバグが発見されたどこかのシステムも存在する。

完璧には不可能だけど、やらないよりははるかに良いし、そこまで本格的にやらなくても一人で数日時間を掛ければ、なかなか分からない範囲には出来る。デバッグはまだ見積もりよりは、はるかに可能な範疇だろう。理論的に不可能と思われる見積もりと違いバグ件数は時間を掛ければ限りなく0に近づけることが出来る。

特定の人に向けたシステムならば、その特定の人が悪意を持って操作することは無いだろうし、その人がやらないだろうと思われる突飛なパターンも考えなくても良い。

この規模でまじめに現実的にデバッグするとしたら2、3人で1週間と言うところか。。。そこまでやれば完璧レベルに近くなるかも?一般的には作成日数と同じ日数を掛けると良いと言われている。

いつも作成だけでぎりぎりの時間でそこまで掛けたことは無いし、そこまでやったら赤字だ。何も残らないどころか借金だ(汗

今作っている程度の規模のデバッグでも本当は作成者一人の力だけで全て出来るものではない。

ただやりすぎてもコストがかさむだけ、バランス感覚が必要だ。。。

うむぅ、既に操作パターンが自分の把握している以上に大量にあるかも。。。やはりデバッグにも時間が掛かりそうじゃ。。。(汗

規模が小さいシステムではあるけれど入力項目や操作パターンが当初見積もり時よりいっぱい増えているんだよな。。。
ふっくんのブログっぽいサイト: バグを考える。。。
http://web.fpso.jp/article.php/20080914193313865