単体テスト不具合発生の原因と対応

最近、オフショア大學に寄せられた質問より。

【問】単体テストで不備等が発生した際、円滑に対応してもらうためのオフショアならではの工夫はありますか？

【答】委託先が中国ならば、単体テストまでは全てオフショア先が責任を全うすべきです。もし、単体テストで不備が多発するなら、明らかな実力不足か、あるいは、前工程を疑います。

ご質問はオフショアならではの「工夫」についてですが、同時に、オフショアならではの「原因」に着目するとよいでしょう。

例１＞言葉に不安がある現場であれば、画面やUIに関する箇所に不安が残ります。HTMLデザインや帳票出力システムでよくある「ミリ単位の罫線のズレ」は、国民文化の違いが原因です。この種の問題の原因を「品質意識不足」だと定義すると、途端に対策が難しくなります。

例２＞入社1－2年目の若手プログラマが主体のオフショア委託先では、ときどき応答速度などの性能要件に関する不具合が発生します。OJT指導なき若手プログラマの人海戦術は、いかにもオフショアならではの問題を引き起こす原因となります。

性能要件の未達でよくあるのはコピペの多用。

for文を何重にも繰り返す、SQLでリソースを食う処理を大量にコピペ生産、莫大なメモリ空間を一時的に確保し処理した後にメモリ開放を繰り返す（C/C++）、ときどきメモリ解放忘れやセッションクローズ忘れのまま複数コピペ、など。

上記の症状がいくつか組み合わり、かつ、複製されて大量の場面で用いられると、皆さん予想通りの結末となります。

こうした症状があるにも関わらず、たまたま、オフショア委託先の極めて限定的な条件下で「うまく試験を通った！」ことが災いし、単体テスト合格と誤判断して、粗悪品が日本に納品されます。

いや、もしかしたら、オフショア委託先のモジュール単体テストですら、性能要件を満たしていない恐れがあります。

例えば、性能要件が「反応速度３秒以内」だったとしても、「８秒くらいなら許容範囲」と勝手に合格基準が捏造されているかもしれません。日本企業では、極めて悪質な倫理違反ですが、業務経験の浅い外国人若手プログラマの一部は、信じられないほど幼稚な言動をとることがあります。

繰り返しますが、オフショアならではの「工夫」よりも、オフショアならではの「原因」に着目してください。

最後に、「工夫」について。

あるオフショア大學講師は、自身の経験談として、次の障害管理プロセスを紹介してくれました。

障害発生から修正、フィードバック、確認完了までの手順をRedmineのチケットを使って、バグトラッカーのステータスで既定し、その手順どおり対応する。

・・・なるほど。上記は、極めてオーソドックスな障害管理のプロセスだと思います。いわゆるオフショアならではの工夫の跡は、どこにも感じられません。

ですが、前述したように、オフショア大學講師は、オフショアならではの「原因」を正確に把握できているからこそ、このような基本的なプロセスが有効に機能するのです。

■ 問いかけ

＜問１＞あなたのオフショア開発では、どのようなToolを使って障害管理していますか？

◆Excel
◆市販Tool
◆一般公開される無料Tool（Redmineなど）
◆社内で内製したTool（有償無償問わず）
◆その他

○結果を見る

締切：2014年10月11日18時00分
協力：クリックアンケート http://clickenquete.com/

＜問２＞オフショア開発でよくある単体テストの不具合を挙げなさい。

＜問３＞オフショア開発の単体テストで発生する不具合の原因を頻度順に挙げなさい。