さらに続編です。
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）をネタに。
運賃計算のテストケースを絞り込んだとして、さてそのケースの「想定される結果」つまり正解はどうやって事前に求めておくのか？という問題が残ります。それに対いて、もう一つ別な運賃計算プログラムを実装してしまうのだと本文では述べています。もちろん別な運賃計算プログラムにバグがないという保証はできないので、テストケースの絞り込みと同様に、これもかなりの割り切りが必要な行為です。運賃計算プログラムをもっと多く作って多数決方式にすれば精度は多少なりともあがるのでしょうが、予算制約からそれも難しい様子。そこで、もう一つの運賃計算プログラムは別な言語で別なチームが別な技法で作ることで、妥当性を担保しているとのこと。非常に工夫されています。
最後には運賃計算プログラムの仕様について触れています。簡単そうに見える運賃計算も、首都圏の鉄道では非常に複雑です。乗り継ぎに対して割り引きがある区間もあれば、一度改札の外に出ての乗り換えが認められている（というかそうしないと乗り換えられない）こともあり、考慮すべきことが多くなります。さらに定期券が一体となっている場合は定期券の区間外運賃を自動的に計算するということにもなるのでさらに一歩複雑です。一応、各社の規則によって計算方法は定められているもの、鉄道オタクたちが規則談議で盛り上がれるほどいろいろと例外規定や解釈の仕方あるほどなので、仕事とはいえこれを計算するプログラムの仕様を作る方は大変でしょう。それに対する一つの解として、形式言語の利用があげられています。それが果たして一般的にどこまで効果を発揮するかは何とも言えないところですが、運賃計算のように規則という形式的なもので定められている今回のようなケースはかなり相性がよいようにも思います。
現実的にそして合理性のある割り切りと、日の目を見ぬもうひとつの運賃計算プログラムに人々の通勤・通学は日々支えられているのです。