レジュメに対してかなりタイムリーな感じの状況でした。
そう。
結合試験。
いやー、こいつは本当に奥が深いですね。
単体試験では出てこないバグがワンサカ発生しました。
何が起きたのかといいますと。
私の担当していた改修部品の修正は問題なく完了しました。
しかし、別会社が担当している機能からその部品が使われるんですが、
そちらの修正が必要というのが結合試験で分かったわけです。
うむ。
結合試験らしいバグだ。
これはいいバグってやつですね。
さて、バグが出たので修正依頼をしましょう。
依頼した別会社では、もちろん再度コーディング、単体試験の工程が行われます。
そして再度結合試験用の環境にリリースをしてもらい、再試験となるわけです。
教科書みたいな話になっていますねぇｗｗｗ
さぁ試験の結果です。
・・・
・・・
他にも影響範囲あったみたい。。。。
また修正依頼出さなきゃじゃん。。。
ってことで、リーダーに相談してみました。
「実データでは存在しないパターンだし、今回は修正見送りますっ！！」
・・・
・・・
・・・は？？
見送るの？？
そもそも最初の修正依頼も同じ条件なんですけど？？？
「実データでは存在しないパターン」なんですけど？？？？
何言っちゃってんの？
だったら最初のも修正しなくて良かったんでないか？
はいこれ、ダメな例です。
何がダメかというとですね。
影響範囲の調査漏れと対応方法のミスジャッジですね。
今回は私の実体験なので、いつもと趣向が違い、プロジェクト保守での結合試験となっていますが、新規プロジェクトでも同様に言えることです。
まず、影響範囲の調査漏れについて。
修正・製造対象の部品を利用している機能の洗い出し。
概要設計書、及び詳細設計をした際に、それらがどこで利用されているかをまとめておけば、
こんなものは一発でわかりますね。
【ダメポイント①】
各機能がどこで利用されているかがまとめられていない！
これじゃあ影響範囲の調査なんて、時間がかかってしょうがないですね。
見落としも出てくることでしょう。
現に今回見落としたのは他社さんが利用している機能への影響が見落とされたわけですね。
じゃあこんな時どうするのか！
もう以前からずっと言ってることですが、
情報共有をきちんとすること
ですね。
今回の場合、
「この部品をこうやって直すから、使ってるとこ・その修正で影響無いかみんな洗い出してね！」
って言えばいいわけですね。
・・・・はい。
今回これができていませんでした。。。
他社さんは知らん顔していましたからね。
皆さんはこうならないでくださいorz
次に、対応方法のミスジャッジです。
これはもう「必要な修正」かの判断をミスったってことです。
プログラムとしてのあり方を言えば、
「存在しないパターンであっても正しく動作すること」
はとても大事です。
ですが。
限りある時間とリソースを考えてみましょう。
そのパターンのためにコーディング・単体試験、結合試験を増やす理由はありますか？
必要ないことをやる必要はありますか？
私はジャッジできる立場にはいませんでしたので、このジャッジは上長に委ねるしかありませんでしたが、
私がその立場にいた場合、確実に「不要」と言ったでしょう。
一言で「無駄」ですからね。
ジャッジする立場の皆さん。
それ、本当に必要ですか？
本来「不要」であれば、「不要」としましょう。
きっともっと「必要」なことに力を費やすことができるでしょう。
今日も一発ポチッとな
