« WindowsでApache+MySQL+PHP+PostgreSQL環境を構築する | メイン | EC-CUBE 2.1.2インストールやってみた »

クリティカルなバグを残さないことの大切さ

テスター歴が長いと、バグゼロでシステムリリースにこぎ着けるなんてないですよというのはわかる。多少なりともバグは残っている。
どう考えてもバグじゃないのかっていうのを仕様と言い切る場合もあるというのも知っている。システム動作に致命的な影響が出ないのならそのままリリースしてしまえというのはある。修正は後でというパターン。
たとえば、携帯電話のソフトウェアだと、リセット・フリーズ・電源断・データ吹っ飛びはクリティカルなバグだ。これらがリリース直後に発覚すれば、発売開始直後に発売停止などの措置がとられることがある。

今日の三菱UFJ銀行みたいなクリティカルなバグはやばいよね。何がクリティカルかって。今回の場合だと銀行のシステムでATMでの取引ができないっていうのは。

障害の原因は、通帳未記帳の件数が10件以上ある顧客に、記帳を促すメッセージを送る際の文字コードが、セブン銀は「カタカナ」なのに、三菱東京UFJ銀の新システムは「漢字」だったという「初歩的なプログラムミス」(業界関係者)。ゆうちょ銀などの障害も誤ったデータ信号の送信が原因だった。

テストケースとしては比較的単純な部類になるかと思う。テストケース漏れと斬ってしまうのは簡単なのだけど、テストケースとして漏れてしまったのはどうしてなのかが明らかにならないと、同じような失敗は防げない。某MLでは「体系立てたテスト設計が行われていないのでは?」という指摘もあるし。

それにしても、

6000人が作ったシステムは必ず動く」の記事みて、ぶっちゃけありえねー!と思っていたけど。何人携わろうが、必ず動くモノがリリースされるとは限らないという見本になってしまいましたね。

テストエンジニアとしてできるのは、テスト設計の段階で仕様を洗い出して、体系的にテストケースに落とし込むことだろう。多数の設定組み合わせなどだと、テストケースとしなかったことでのリスクも織り込まなければならない。

ともあれ、テストやって、クリティカルなバグが検出できませんでしたではしゃれにならない。

テストに携わる者として、今回の件はテストをしなかったことによるリスクの大きさを感じさせられた。

トラックバック

このエントリーのトラックバックURL:
http://hpbuilder.net/weblog/tb-hpb.cgi/2569

コメントを投稿

書いている人

About

2008年05月13日 21:00に投稿されたエントリーのページです。

1つ前のエントリー:「WindowsでApache+MySQL+PHP+PostgreSQL環境を構築する

次のエントリー:「EC-CUBE 2.1.2インストールやってみた

おさんぽさんぽ・メインページへ