システム発に置いて一番大変な工程とは？という問いには、人によって様々な答えがあると思います。要件定義だと言う人もいれば、製造工程だと答える人もいるでしょうし、設計だと主張する人もいることでしょう。
もちろんどれも非常に重要であることは間違いないのですが、筆者はその中で最も大変なのは、テスト工程ではないかと考えています。
膨大なテストケースをこなし、不具合を炙り出す作業が、どれほど難しいことか。それは時には有名なツールでさえ不具合を遺していることからも、明白だと思います。
今回は、そんな有名ツールに残されていた、あるいは残されたままの不具合について、その一例をご紹介しましょう。

Excel2003のCsv保存

Csvはデータの取り込みなどで大活躍のデータ形式ですが、過去のエクセルのバージョンにおいて、正常に保存できないバグがあったのをご存知でしょうか。それはExcel2003で、17行以上のデータをカンマ区切りで保存した場合に発生する現象でした。
データを保存すると、項目ごとにカンマが入り、それによってデータの切れ目を判別するわけですが、16行目までは行末にカンマが入り、17行目以降は行末のカンマが消えてしまうのです。
データ取込のプログラムを作る際、この現象を知っていないと、読み込むデータの区切り範囲が狂ってしまうため、影響の大きい不具合でした。

log4netの2重ローテーション

VisualStudioのNuGetパッケージで配布されるログ出力ライブラリ、log4netには、ログローテーション機能が標準搭載されています。これはコンフィグ設定を行うことで、ログ出力時にサイズや日時判定を行い、自動でログファイルに別名を付けることができるというものです。
サイズの肥大化を防ぐためにも非常に便利な機能なのですが、2つ以上のアプリケーションで同じログファイルへ書き込む設定にしていると、このローテーションに不具合が発生してしまうのです。
2つのアプリケーションが、同時にログ出力を行ったとしましょう。この時、先行するアプリケーションをA、後から実行されるアプリケーションをBとし、どちらもローテーション処理を行うと……何と、Aがローテーションした後のファイルを、Bが再び同名でローテーションし、既存のログファイルを上書きしてしまうのです。
大切なログファイルが2重のローテーション処理によって上書きされ消滅してしまう、かなり厄介なバグと言えるでしょう。

OracleのOra600エラー

OracleではSQLを発行した際にエラーがあると、専用のエラーコードが出力され、原因の特定と解決方法をすぐ検索することができますが、この「Ora-600」エラーだけは別物です。これは内部的なシステムエラーを表すコードで、開発者がここから原因を探ることはほぼ不可能です。
複雑なSQLを組んだ時や、同時に大量データを扱うSQLを発行した際に起こりやすいので、恐らくはメモリ不足や実行計画の構築エラーによるケースが多いものと思われますが、解決するにはOracleのサポートを使うしかないので、非常に厄介です。

テストはやり過ぎでちょうど良い

名だたる企業の有名ツールでさえ、解決しきれない不具合が存在することをご理解頂けたでしょうか。テストは確かに面倒な工程ですが、しかし、不具合を無くすためには必ずやらなくてはならない作業です。
やり過ぎなくらいでちょうど良い、どんなにやってもふそくするよりは良いということを念頭におき、入念にテストを行うよう、気を付けましょう。