最低限の動作確認は必要

システム開発会社では、どんなに小さなプログラムでも、ソースコードを1文字直しただけでも、必ずレビューやテストを行い、何重にもチェックを行っています。「自分が設計し、自分で実装して、すべて把握できているものだから、大丈夫、テストなんて面倒！」と思われるかもしれません。もちろんここで開発するシステムでは、システム開発会社が行うような厳しいチェックをする必要はありません。しかし、最低限の動作確認は行う必要があります。後で必ず「やっておいて良かった」と思うはずです。

では、「最低限」とはどこまでか。いろいろ意見はあると思いますが、筆者が考える「最低限」とは、「正常に動作する1パターンが期待通りに動くこと」と言えるでしょう。これをIE操作の例で考えると以下のようになります。

1. ログインする。
2. 購入余力金額の確認を行う。
3. 買い注文を行う。
4. 売り注文を行う。
5. 買い注文訂正を行う。
6. 買い注文取消を行う。
7. 買い注文確認を行う。
8. 買い注文詳細確認を行う。

本当に最低限ですから、もっと詳細なテストを行っても全く構いません。
さて、これらをどのように試験したらよいでしょうか。1. 、2.はどのタイミングで行っても問題ありません。問題は、3.～8.で注文を出すと約定してしまう可能性があることです。動作確認が目的ですから、実際の取引（約定）は行われない方がよいわけです。ということは、ザラ場でない時間帯に注文の動作確認を行えばよいことが分かります。日中仕事があるサラリーマンでも、動作確認は可能です。

しかし、お気づきかもしれませんが、4.の売り注文だけは、約定して、保有株になったものを売る手順が必要になります。この動作確認だけは、一度株式を保有する必要があります。このような場合は、購入金額ができるだけ小さく、かつ、流動性のある銘柄を選択することで、システムが売り処理に失敗し、損失が発生しても、最小限に食い止めることができます。