みずほ証券はバグの原因を東証の重過失とする根拠をいくつか挙げているが、中でも準備書面で多くのページを割いたのが、「簡単なテストを行えばバグは必ず発見できていた」という主張だ。
みずほ証券は、東証から提出を受けたソースコードを解析。バグの原因となった修正プログラムについて、修正部分を直接的に確かめるテストか、修正が他のプログラムに影響を及ぼさないことを確認する「回帰テスト」のいずれかを実施していれば、今回のバグは容易に発見できたはず、という意見書を提出した。今回東証は、修正プログラムのテストについての資料は「既に存在しない」として開示していない。
みずほ証券によれば、テストで想定すべきケースは「たかだか二つ」だったという。「テストケースは無限に想定され得るから、今回のバグを見つけるのは困難」という一般論は、今回のケースでは当てはまらない、という主張である。
二つのケースとは、ある特定の条件下で出された注文が「最初の付合せ処理（他注文とのマッチング）をしているケース」と、「（最初の付合せで全てが約定せずに）2回目以降の付合せ処理をしているケース」だ。後者の場合に限って、付合せ処理後に取引関係のデータベースがゼロクリアされる仕様上の問題から、バグが表面化する（図3）。
図3●誤発注を取り消せないバグの原因となったソースコードと分岐条件
みずほ証券はテストでバグは容易に見つかったはずと主張する。
[画像のクリックで拡大表示]
東証は「システム提供者に、バグをゼロにする義務はない」という前提のもと、東証のバグ管理には問題がないと主張した。東証によれば、2000年に東証がシステムを稼働させた際には、「取引参加者（証券会社）の参加の下、実際の運用に最も近い状況を想定して実施した総合テストおよびリハーサルにおける障害件数の収束状況を基礎に」稼働開始を決定したという。
