テストの自動化

KDDI、相次いだLTE通信障害の原因はソフトウェアバグ

社長が謝罪した舌の根が乾かない内に問題が再発したというか新たな障害が発生してトップの面目丸つぶれという感じですので、再発防止に向けて強力なプレッシャーが現場にかかることは想像にかたくないです。

しかし、こういうトラブルが発生するたびに私が思うのは、日本のITのテストに関する旧態依然とした考え方がこういうトラブルの遠因ではないかという点です。

簡単に言うとテストの自動化が全く行われていないあるいは極めて限定的な適用に限られているという点です。

テストというのはどうしても地味で泥臭い作業なので、なかなか日が当たらないというかほかのことより軽視されて結局後回しにされ、最後に切羽詰った状態で行われるというのが常と思います。

しかし何かを変更したときに影響がないかどうか全てを再確認しなければならない局面というのは多々あり、そういう繰り返しテストが必要な部分はテストの自動化が望ましいわけです。

OSやミドルウェアのバージョンアップを避けたがる傾向も結局同じテストを手動で繰り返すのが大変というところに原因があると思います。

結果現場には想像を絶するプレッシャーがかかるなか大抵は現場の努力というか根性で乗り切っているのが大半の現状ではないでしょうか？

しかし、根性で乗り切れるのも結局は程度問題

システマチックな対応が必要です。

今回の事例がそういう結論にたどり着いたかどうか定かではありませんが、日本のIT全体として取り組まなければならない問題です。

全てが自動化できるかどうかは置いといて容易に自動化できるものは自動化しておけば、ほかの自動化できないテストにより集中することも可能になると思います。