テストが甘いのよ

おそらく多くのブロガーさんが話題にしておられるであろう、三菱東京UFJ銀行のシステム障害。その原因は、「本来カタカナを使うべきとことに、漢字を使ってしまったから」だそうで。

そもそも、「三菱東京UFJ銀行でシステム障害」という第一報を見たときは、「ああ、案の定」と思ったんです。マタカ、という感じ。でも、あれだけ注意を払って、お金も時間もかけてやっていたのに。実際にシステム移行に携わった方には申し訳ないんですけどね。

次のこの記事を読んだときの最初の感想は、「テストが甘いなぁ」でした。

おそらく、要件定義とか、実際のプログラミングとかはものすごく計画をたててやっていたのではないでしょうか（想像）。また、「うまくいくパターンのテスト」とか「ネットワーク遮断とかシステムのダウンとか過負荷とか、想定される範囲での障害テスト」はさんざんやったんでしょうね（こっちも想像）。問題は、「ありそうもないヒューマンエラーのテストをどれだけやったか」ということだと思うんです。

私は、テスト計画はシステム構築に携わっていない人がすべきだ、と考えています。システム構築に携わっていない人はシステムのルールを知らないわけですから。システム構築に携わった方は、「システムはこういうつくりになっていてこう動く」ということを知っています。そういう方が考えるテスト計画は、無意識のうちに「想定された動き」をなぞってしまうんです。

昔勤めていた某外資系メーカーでは、取り扱い説明書を作成する専門のチームがいました。彼らには製品の仕様書をあえて渡さずに、製品開発担当者が行う説明だけで取り扱い説明書を書かせていました。確かに効率は悪いです。説明書作成チームは、開発担当者が想定していない使い方をして開発担当者をビックリさせます。また、開発担当者が想像もしていなかったような疑問が出てきてすったもんだします。時にはシッチャカメッチャカになることもあります。しかしそのおかげで、ものすごくわかりやすい取り扱い説明書ができていくのです。

不具合は絶対にある、という感覚でテストをすることが肝心なんですけどね。

私は普段、ITIL や COBIT といったIT運用の標準フレームワークを使った仕事をしています。テストプロセスにだってそれなりの標準フレームワークがあります。私が知っているのは TMap（Test Management approach for structured testing）と呼ばれるものです。「TMap テスト」というようなキーワードでググると色々出てきますので、興味のある方はお試しあれ。