開発工程を知らないと大問題に！
過去のプロジェクトで製品の最終段階で基本的な機能にバグがあることに気づきました。
全員真っ青です。
なぜ？今さらこんなバグが見つかるんだ？？
基本機能だから十分にテストをしているはずですから、そんなバグが見つかるということは「テストの網羅性が足りないのか」「テストの実施方法が良くなかったのか」というようなことが取り沙汰されます。
ところが、そのバグが混入した原因を調べた結果、「直前のテストではその機能に全く問題がなかった」ということがわかりました。
ではなぜそのバグが今起きているのか？
その機能を担当しているプログラマーに話を聞いたところ、「ソースコードに気になることがあり、よかれと思って直した」、という発言をしました。
開発の初期の頃ならともかく、テストも積み重ねた終盤に不用意な修正をし、しかもその修正が既存機能に影響しないかを十分にテストしていませんでした。
彼はプロジェクトリーダーから大目玉を食らって、ソースコードを直前のバージョンに戻しました。
プロジェクトの終盤のバグ修正は慎重に
よかれと思って直した行為がなぜ叱られる羽目になったのか？
プロジェクトの終盤、特に市場に出す直前当たりではバグの修正は慎重に行わないといけないからです。
バグを直す、すなわちソースコードに手を入れるということは、その修正が影響する範囲のテストをやり直す必要があります。
プロジェクトの終盤までには綿密にテストを積み重ねてきているので、ソフトウエアの修正をするとなればその修正がどこにどんな影響があり、どの範囲のテストをやり直す必要があるかを洗い出すし、それらに問題がないということを確認する必要があります。
その影響範囲が大きければ、もしかすると市場に出す納期に間に合わないかもしれません。
何とか間に合わせるために、人手をかけて頑張るしかないかもしれません。
そういった大きな問題になりかねないのです。
だからこそ簡単には直せないのです。
100%動作するコードもテストで検証が必要
残念ながら、「プログラマが絶対大丈夫」という言葉をそのまま信用してもらうことはできません。プログラマが100%動作すると確信を持っているプログラムであっても、テストによって問題ないと確認されない限り、OKは出ないです。
プログラムの初学の頃は、コードを教科書通り書いても思ったように動作せず、バグの原因を見つけるのに四苦八苦することがあります。
小さいコードですら、そうです。
熟練になってある程度の規模のコードを書くようになると、その部分だけ正しくても、他の部分と連携したときに正常に動作しないことも起きてきます。
こういうことは、プログラムのコードを見ているだけではわからず、動作させて検証する必要があります。
簡単な修正のはずなのに、プログラマのテスト不足で一発では期待通り動作しなかったことは、僕の経験でも多々あります。
だからこそ、必ず動かして検証することが必ず必要です。僕も動かして検証することが当たり前になっています。
ましてやテストが不十分なコードほど信用できないものはありません。
コード修正していいとき・悪いときを知る
すごく雑な言い方をすれば、開発の初期であればコードの修正はどんどん行っても問題ないです。
ところが、一旦テスト工程が始まって以降は話は簡単ではなくなります。
企業によって違いはあれど、テスト工程に入ってからのバグの管理は厳密になります。
というより、バグは厳密に管理しなければなりません。
どんなバグが発見され、それはどのような問題で直すべきかどうかが判断され、修正すべきものはどのように修正され、最終的にテスト工程で修正が確認される必要があります。
そしてバグの収束状況などを判断の上、次工程に進んで良いかが決まっていく。
バグには「実装のバグ」というプログラマの実装による問題のものもあるし、「仕様の誤解」などの問題もあります。
これらはプログラマが原因のものですが、もっと別の「バグ」が見つかることもあります。
それは「仕様バグ」というようなもので、仕様の間違いや仕様の矛盾に起因するものです。
これらはソースコードの実装を直す前に、仕様を考える必要があります。
バグの管理はソフトウエアの品質を知る上で重要
ソフトを仕様通りに作ったのに、予期せぬ動作になることがあります。
ソフトとしては仕様通りに動作しているのに、あるケースでは期待通りではない、というような場合です。それは仕様の矛盾であったり、仕様の間違いなどが原因で「仕様バグ」と呼ばれるものです。
仕様バグの場合、仕様をどのようにすべきかをまず考える必要があるので、要求元に確認しないと決められないこともあり、かえって時間がかかることもあります。
仕様だからすぐに解決できるかと思いきや、ある仕様の矛盾を解決しようとすると、別の仕様との不整合の問題が発生するなど、一筋縄でいかないことが多いです。
そういう問題もあるので、テスト工程に入ってからのバグは要求者などの関係者を含めた議論が必要になることも多いので、きちんと管理していくことが必要になります。
こういうこともあり、バグを記録し、原因がどうで、どういう風に対処し、最終的にどうやって確認したか、ということを管理していくことが欠かせません。
これがソフトウエアの品質を上げるためにも欠かせない作業です。
そういったバグ管理が必要になり、後工程になるほど一つのバグが直って確認されるまでに時間がかかることになります。
ソフトウエアエンジニアとしては、早い段階でしっかりと品質を作り込む意識でやることが大事です。あとに回せば回すほど自分の首が絞まります。