2008年10月05日
不具合の修正
Tweet発見、起票された不具合は、機能の担当者が設けてあればその人に、そうでない場合は不具合を作ったと思われる人に回される。
担当者は、まず解析を行う。
解析は、不具合の発生原因の調査を行うこと。
発生原因がわかったら、修正方法を考え、影響範囲を出す。
もしくは、不具合ではなく、元々意図した動作(仕様通り)だった場合は、そのまま起票者に仕様通りとして戻す。
(場合によっては仕様の記載された資料も添付する)
修正方法はひとつとは限らず、複数ある場合もある。
その場合は、後のメンテナンス性、設計的な美しさ、影響範囲から総合的に判断して修正方法を決定する。
軽微な不具合で影響範囲も少ない場合は、解析した瞬間に修正もついでにしてしまうこともあるが、基本は発生原因と修正方法、影響範囲を不具合票に追加する。
そして、開発の進行状況から上長と相談して進める。
特に開発終盤になってくればくるほど、修正方針は重要になってくる。
修正するかどうかは、不具合の影響の大きさと修正した場合の影響範囲の大きさから判断される。
例えば、一瞬画面がちらつくなどの不具合があった場合、ソフトウェアの動作的には問題はない。
ただ、見た目が少し悪いだけ。
このような不具合は軽微なものとして扱われるので、開発終盤になってくると無視するか次期検討として取り扱われる。
開発序盤の場合は、軽微なものでも修正することが多いが、その影響範囲が大きく、その開発やテストを行うと開発期間内で終了しないような場合は、序盤であっても無視や次期検討にすることもある。
(ちなみにちらつき系は往々にして根が深く、影響範囲が大きいことが多い)
修正方針が確定したら、実際に修正を行う。
修正が終わったら、直っていることを確認する。
直っていない場合は、再度解析に入り、上述のプロセスを再度追う。
場合によっては、この後類件調査を行う。
類件調査とは、同じような原因で発生する不具合がないか探すことを言う。
プログラムは同じような原因で発生する不具合が多い。
特定の状況を考慮していなかった場合などは特にその傾向は顕著。
なぜなら、そのような操作や状態になった場合、どうするか考えていないので、どのように動作するかわからないから。
このことから、類件調査を行うことで、一気に多くの不具合をつぶすことが出来ることも多い。
逆に、まったく見付からないこともある。
テストの方法によるが、修正後、影響範囲を割り出し、試験書を作成することもある。
影響範囲とは、その修正によって動作が変わる恐れのある機能全てで、それらの動作が変わっていないことを確認する必要がある。
この試験範囲が大きい(量が多く時間がかかる)ことを、影響範囲が大きいと言っている。
試験書を作成したら、試験を行い、問題なのないことを確認する。
問題が発生した場合は、再度解析に入り、上述のプロセスを再度追う。
以上のプロセスを得て不具合を修正した後は、不具合票を発見者に回す。
発見者は戻ってきた不具合票の再現手順を繰り返し、直っていることを確認する。
なぜわざわざ発見者に戻すかと言うと、発見者と修正者の認識が異なっている場合があるから。
発見者の見つけた不具合と異なる不具合を修正していることもありうるために、発見者が最終確認を行う。
この時、認識の相違や直したつもりだけど直っていなかった場合などは、再度解析に回され、同じ手順を再度追う。
発見者が直っていると判断した場合は、不具合票は close される。
(現場によっては上長が最終判断して close する)
以上が不具合の発見から修正までだけど、意外と複雑なプロセスを得ている気もする。
フローチャートなどがないと少しわかり辛いかも。
投稿者 Takenori : 2008年10月05日 11:50
トラックバック
このエントリーのトラックバックURL:
http://kaede-software.com/mt/tb-ping.cgi/1727