SEA関西プロセス分科会「自動改札機ソフトウェアの品質向上の取組み」に参加した
一昨日(2013/4/19)はSEA関西プロセス分科会に参加してきた。講演は、オムロンソーシアルソリューションズ(株)幡山五郎氏による、自動改札機のテストの話だ。既に昨年の講演を取り上げた記事も出まわっており概要は知っていたが、今回は直接話しを聞くことができた。
講演は自動改札機の歴史から始まり、内部構造や機能の紹介、切符を扱うハードの検証から運賃計算（ソフト）の検証に重点が移ったことが紹介され、本題の検証の話題に入った。以下、講演メモより抜粋。
- テストパターンはまず全体を定義して、条件を絞り込むという考え方が有効。昔は個別のケースを積み上げていたが、それではキリが無いし重要なポイントを外している危険もある。仮に検証漏れが発生しても、それは絞り込みのルールが間違っていただけなので、そもそもの考慮漏れとは異なる。
- 100万件のテストを行うために100台のパソコンを用意して、実機用ソフトと検証用のソフトを走らせて2週間から3ヶ月かかる。テストそのものは容易だが、差異が発生した時にその原因を調査、分析するのが大変。
- 鉄道会社の受け入れテストでは、異なる会社から納入されたシステムを互いに検証させて、問題がないか確認している。各社ともそれぞれ異なるアプローチで検証しているので、その結果に差異が出ることもある。
- 鉄道会社から提示される仕様はややこしい。基本ルールは単純でも、その後に続く特殊ルールや例外規定などが延々と続くため理解が難しく、経験が必須。そのため新人がなかなか入り込めない開発体制になってしまっている。
- 仕様書には暗黙知や前提条件、記載対象が異なるものが多数有る。その辺りの仕様アーキテクチャを考える上で、文章で記述された仕様書をVDMに変換したところ、仕様の翻訳8000行、暗黙知の記載1400行という結果になった。仕様不備を指摘することは出来たが、むしろ仕様書のアーキテクチャを考えるという意味で効果があった。
- 仕様の検証を夢見てVDMによる検証も試みたが、既存の仕様書をVDMに変換する限り記述ミスが避けられず効果が得られなかった。新規の仕様を作るのなら、最初からVDMを使えば有効かも知れない。
開発現場で苦労した人でなければ分からないような話が続き、興味深く聞くことが出来た。膨大なテストケースを捌くのは大変だし、手間も時間もかかってしまう作業ではあるけれど、それなりの戦略と知恵を働かせることで、少しだけ賢く進めることが出来るのかも知れない。
講演の中で一番参考になったのは「トップダウンによる全体像の把握」という考え方だ。テストケースを幾ら積み上げてもゴールが見えないという意味で不安になってしまうことが多いが、そこから合理的な理由でテスト数を削減していけば、決して考慮漏れという自体は起こり得ない。自分のドメインでテストケースの全体像とは一体何なのか考えてみたいと思った。
たとえば、ICカードを改札機にタッチしたときの乗車駅・降車駅・定期券の経路などの組合せのパターンは10の40乗を超えますが、運賃計算ソフトウェアのテストではそこから「不具合は漏らさないが実行可能な規模のテストパターン」への絞り込みを自動的に行っています。また、形式仕様記述言語を利用して、現状の仕様書の問題点を明らかにしました。 本講演では、自動改札機の概要およびこれらのソフトウェアの信頼性を高めるための取組みを紹介いたします。
4月19日 第51回 SEA関西プロセス分科会(大阪府)
