2017年09月27日

検証システムのすすめ


初めての方はこちらを「はじめに

「検証システム」というのは個人的に付けた名前で一般的な用語がある訳ではありません。
今回はテストに関する話です。

ソフトウェア特有の事情


世の中の製品を見まわした時にソフトウェアにしかない固有の事柄というのは幾つかあると思いますが、その中の一つに品質があると思います。
なぜかというと世の中の製品で新品なのに正しく動かない事が前提で売られているものは無いのではないでしょうか?ソフトウェアの場合はユーザーの方もバグがあるのは当たり前という認識で使用している場合が多々あります。「ソフトウェアとはそういうものだ」と理解しているのです。良く考えれば不思議な事ではありますが...

それではソフトウェアの場合はどうして他の製品の様に完璧な状態で出荷できないのでしょうか?
それは基本的には全ての組み合わせをテスト出来ない為だと思われます。勿論作る時の仕様や設計等にも特有の事情は存在していると思います。しかしそうだとしても最後のテストが漏れなく全てのパターンを出来ていれば問題がすり抜けてそのまま出荷されるという事は無いはずです。

作る際の品質確保の課題というのは一般の製品でも新しい技術に取り組むような場合には様々な困難があるはずです。例えば燃料電池車などは今までにない革新的な製品ですから新規の技術が沢山取り入れられているはずです。しかしだからといって走っている最中に水素が漏れたりとか動かなくなったりとかはしない訳です。これは徹底してあらゆるパターンをテストしているからに他ならないのではないでしょうか?逆に言うとユーザーとして車に乗る側の立場から言えば、そのようにあらゆるパターンをテストしてくれていなかったら怖くて乗れません。つまり品質を確保するという事においてはテストの網羅率(カバレッジ)には相当大きな意味があるはずです。

検証システム


この様な視点に立てば如何にテストを行うかというのはかなり重要な要素に思えるはずです。なぜなら燃料電池車にはほとんど問題はありませんが我々の作るものは常に問題だらけな訳ですから...

その様な考えからある時テストを沢山行う(網羅率を上げる)為に基本的には自動化を行う方針としました。
それで市販のもので自動化を試みた事があります。しかし汎用的であるが故に個々のプロジェクトの固有の要件を満たすのが難しく部分的な活用にとどまりました。結局個々のプロジェクト毎に自前で作る事にしました。その様なものを内部的に「検証システム」と呼ぶ事にしました。

検証システムを一言で説明すると「テスト仕様をスペックとしてテストを実行するソフトウェア」という事になります。
単純にスペックに書かれた事を次々実行して結果を記録して行くというだけなのですが、スペックのポテンシャルがテスト対象のプログラムの機能仕様と同じという事がポイントです。つまりスペックに記述しさえすれば全ての機能をテスト出来るという訳です。またスペックの記述としてループや分岐などの制御文を書ける様にすればどんどん沢山のテストが出来る様になって行きます。いずれにせよプログラム的にはそれ程難しい話は無く、むしろ実行前にテスト環境を整えるのをどの様に自動化するのかに工夫が必要かもしれません。テストを開始する時にはその環境は常に同じ環境からスタートしなければならないからです。

プログラム的にはそれ程難しい話は無いと言いましたが一つ例外があってUIのテストを自動化するのは少しハードルが高いです。キーやマウスの動きをエミュレートするようにしてスペック化する事はできます。しかしテスト対象のソフトウェアがバージョンアップなどでUIの仕様が変わった時にスペックを如何に追随させるかが問題です。キーやマウスを物理的な情報としてスペック化するのではボタンの位置などがちょっと変わっただけでももう動かなくなってしまいます。論理的な情報としてスペック化する必要がありますが、その辺がハードルが高いと言えます。最近の市販の製品の事は詳しくないですが探せばこの辺をクリアしているものがあるのかもしれません。

ただ、検証システムというのは「より多くテストをする」のが目的ですので費用対効果を判断してUIは自動化しなくとも適切な設計をしていれば十二分に有用です。ここで「適切な設計」と言っているのは、「UI経由で実行できる機能は全てプログラムからも実行できる」という事です。
よくあるのはUIを処理する中にデータ処理等の機能がそのまま混ざり込んでいてUIと癒着してしまっているパターンです。これはちゃんと設計をしないで、ただ作り易いように作るとある意味自然にそうなってしまいます。
しかしUIというのは本来その名の通りUser Interfaceであってユーザー、つまり人間用のI/Fという事です。あくまで機械(プログラム)とやり取りする時にどんな形式(I/F)でやりとりするかというだけであって、その人間用という事なのです。プログラムの機能である本体とは何も関係が無いのです。ですから以下の図の様に人間ではなく機械(プログラム)とのやり取りをするI/F、言うなればMI(Machine Interface)を用意する事で外部のプログラムから本体の全機能が実行できるべきなのです。
53N030_001.jpg
これは例えれば日本人とやり取りする時は日本語を用いて、アメリカ人とやり取りする時は英語を用いる様なものです。やり取りの形式(I/F)はそれぞれありますが伝えたい事(本体)は両者で変わる訳では無いのです。あくまで形式だけの話なのです。

さて説明が少し長くなりましたが、もうお分かりだと思いますが、UIと本体が適切に分離されていて外部のプログラムから全機能を実行できるならば検証システムによって本体の全機能のテストが出来るという事になります。UI部分については構造的に独立していますからウィンドウのデザインなどUI固有の処理に関するテストのみを従来通りの手作業で行えば良い事になります。

開発と運用


検証システムはあれば便利というレベルのものではなく、これこそが品質の最後の砦なんだという思いで必ず用意しようという意志が必要です。プロジェクトの計画には他の開発項目と同様の位置づけで検証システムの開発も入れておく事が重要です。
53N030_002.jpg
ソフトウェアを開発するという事はその一部として検証システムを開発する事だという意識を持つ必要があります。

どういうレベルのものを開発する必要があるかというと、仕様として全機能をテストできるようにするのは当たり前ですが、もう一つ言わば性能的な要件としてテスト環境の構築等も含め全工程が数時間で済むようなものを目指す必要があります。目指すという意味はテスト項目を絞り込む等のレベルを下げての達成ではなく、テスト環境のハードスペックを上げて達成するような上向きの意味を表しています。

なぜ数時間かという事を説明したいと思います。
日常の業務の中で想定される最大級に緊急性の高い事態はユーザー先でトラブルが起きて、それをその日のうちに直さなければいけなくなったような事態です。この場合ユーザーが明日には業務を行わなければならない為に今夜中に直して明日の業務開始までにパッチを当てなければなりません。仮に残業時間から初めて夜中には対応できたとしても朝までには数時間しかありません。この数時間で検証システムを実行したいという事なのです。

こういう場合、直した部分に関連したところだけをテストしてパッチをリリースする事が良くあると思いますが、例えばISO9000では納品前に義務付けられている最終テストである妥当性確認は最終成果物(つまり納品物相当)で実施することが求められています。解釈の仕方はあるかもしれませんが少なくともこの要求の精神としては「ユーザーが使うそのものでちゃんと確認しろ」という事だと思います。だとすればパッチという部分に関するテストだけで済むはずは無くバッチをあてて現行版とは別バージョンとなる製品全体のテストをやり直す必要があるはずです。ここで検証システムが活躍する訳です。こういう差し迫った状況で部分的なテストだけでリリースしてしまうのは取りも直さず全てのテストをやるには時間も労力もかかり過ぎるからです。それが数時間で終わる検証システムが用意できれば可能になる訳です。

実際に何度か助けられた事があります。
まさしくこの様な状況で翌日はユーザーが決済か何かの締めの処理を行うタイミングで待ったなしの状態でした。担当者が取り組みなんとか原因と対応方法が分かり、一通り説明を聞いて全ての内容に納得が出来て、仮版でテストした結果も問題ないという報告だったのでその対応でOKを出しました。正式な対応が終わったのは時刻的には終電も間に合いそうなくらいの時間でしたが最後に検証システムの結果だけ見届けてすっきりとした気持ちで翌朝帰ろうと思い帰らずに検証システムの結果を待ちました。
結果はまさかのNG...
対応内容をレビューして一点の曇りもなく納得が行った状態なのに実際リリースしたら駄目だったという経験が無かったのでこの時は本当に驚きました。「まさか!?」という感じでした。検証システムのセッティングを間違えたんじゃないのかと疑いましたがそうではありませんでした。結局その後今一度対応をし直して無事間に合ったのですが、もし検証システムが無かったらと考えたら冷や汗が出ました。

すすめる理由


勿論一晩と言わずもっと早く対応しなければならないようなものもあるでしょう。逆にリリース後ならまだしも新規でリリースに向けて色々なものを開発している中で検証システムにそこまでパワーはかけられないといった事もあるでしょう。その辺は予算等の事情とバランスを取るしかないとは思います。末永く使うものですからリリース後に少しずつ拡充して行くのでも良いと思います。

一番伝えたい事は検証システムがあった方が圧倒的に「お得」だという事です。
先程の例でもし最初の対応のままリリースして二次災害を起こしていたらどうなっていたでしょう?一度の品質問題でいくらの損失になるか意識した事はありますか?ユーザーの直接的な損害だけではなく対応にかかる色々な人のパワー、元々の業務が中断する事によるロス、会社の信用の毀損...品質問題は本当に多くの損失に繋がります。勿論直接的にテストにかかるパワーが大幅に削減できるという事もあります。

具体的に損益を計算した事はありませんが今まで自分が開発したものの中でトップクラスに投資効果が高いものだったのは間違いありません。予算を決裁する立場の人にはそういう類のものなのだと理解してもらいたいですし、逆に決裁を仰ぐ立場の人はその辺の説明がちゃんとできれば良いのではないかと思います。

一覧


メニュー

関連


事例:天文衛星「ひとみ」の事故


記事を広める



品質の最新記事


posted by 善 at 19:17 | Comment(0) | 品質 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。