この章では、製品出荷前テストでの「不具合」の発生を減らすための、ソフト開発プロセス上での工夫について、もう少し細かく説明していきます。「組込み制御ソフトウェア」の開発は、後ろのプロセスほど大変というころから、今までと同様に、終わりから考えます。
実際のテストでは、必ずしも、ランタイムエラーのように、はっきりした異常が見えるときばかりではありません。動いているけれども、この出力結果で正しいのかどうか、簡単には判断がつかない場合も多いでしょう。予想と少し異なった出力が出た場合、これはコーティングミスがあったのか、要求仕様の解釈を誤って理解してアルゴリズムを設計してしまったのか、そもそも、ソフトウェアの仕様に間違いがあったのか、ハードウェアが想定通りに機能しなかったのか、などの原因が考えられます。
切り分けの章では、説明を省略しましたが、製品が複数の組み込みシステムから構成されている場合、上記のような異常発生時の問題の切り分けを容易にするためには、製品出荷前テストの前に、それぞれの組込みシステム単体でテストを行うべきです。そのシステム単体テストの前には、以前説明した通り、それぞれ、組込みシステムとハードウェア依存処理のソフトウェアを使ったテストと、アプリケーション処理のソフトウェアを分けて、それぞれのテストを行うべきです。さらにその前には、ソフトウェア関数の単体テストが必要でしょう。これらのテストが実施できていることで、製品出荷前のテストでの、「不具合」発見を簡単にします。
上記で説明したそれぞれのテストを、スムースに実施するには、あらかじめ、テストに使用する入力データと、期待出力データを準備しておく必要があります。ソフトウェア単体テストでは、評価対象の処理が、分かり易い単位まで小さくなっているため、テストに必要な入力データと、期待出力データのペア（テストケース）は、準備し易いでしょう。一方で、多くの関数を組み合わせた、アプリケーション処理のテストケース、これは、実は、製品出荷前のテストケースと共通化できる部分が多くなります。つまり、製品出荷前のテストケースの準備が必要になるのですが、これは、かなり手間がかかるでしょう。ただし、ソフトウェアの要求仕様と同時に、製品出荷前テストのテストケースやテスト条件を、テスト仕様として準備し、ソフトウェアの設計に利用できるようにすることは、見える化やサンプリングの仕組み作りに影響を与えるため、とても重要なことです。
製品出荷前テストのテストケースを作成するには、ソフトウェアの要求仕様を、かなり詳細に設定しておく必要があります。ソフトウェア設計にも、テスト仕様の入手が非常に役に立つのですが、残念ながら開発現場に依存して、そのことに十分理解が得られない場合もあります。私が過去に、人が載る航空機に搭載される「組込み制御ソフトウェア」の開発を担当していたことは、ごあいさつの章で述べていましたが、そのプロジェクトの中で、実際に体験したことの概要をご紹介します。
その航空機には、制御システム故障時のバックアップ目的で、ある範囲で同じ機能を持つ「組込み制御ソフトウェア」の開発が、２個ほぼ並行して進んでいました。隣のチームの開発が先に始まり、少し遅れてもう一方を私のチームで、開発が始まりました。こちらのチームで、ソフトウェア要求仕様を受け取った際、曖昧な部分が多いことに気づき、要求仕様設定者のいるのチームへ、明確にするようにお願いしたところ、「それくらい自分たちで考えろ！」という回答が返ってきました。実は、隣のソフト開発チームでは、既に、ソフトウェア（コード）の開発担当者それぞれが、自分たちで要求仕様を解釈して、設計を開始していました。当時その職場では、ソフトウェア開発者は、「ハードを含むシステムの仕様を理解することも大事である」とか「仕様通りにソフト開発するだけではだめで、ハードの知識を増やして、仕事の幅を広げるべき」と言われることがありました。隣のソフト開発チームはそれを素直に聞いて、要求仕様を振り分けられた担当者それぞれが、ハードの仕様を調べながら、ソフト設計をしていました。その一方で、私のチームというと、「こちらで要求仕様を考えることできません」と訴え、要求仕様を設定する担当者を、増やしてもらい、その人に細かい要求仕様の設定をお願いすることになりました。私にとっては、それが当たり前と思っていたのですが、隣のソフト開発チームと比較されて、「できない人の集まり」のように見られていたかもしれません。実際に、先に開発が始まった方から人材の投入が始まっており、私がその開発に招集されたのも、隣のチームの開発が始まった後からでした。優秀な人から、隣のチームへ人がアサインされていたようですが、隣のチームをお手本にすれば、いいのではないかと思われていたのかもしれません。実際私のチームへアサインされたメンバーは、「組込み制御ソフトウェア」開発の経験が無い人たちでした。今思えば「できないなら仕方ない」ということで、わがままが許されたのかもしれません。
要求仕様を設定する担当者を手に入れた私のチームは、仕様明確化を進めました。処理内容から、アルゴリズムまで、定義できるものは、出来るだけ要求仕様側でまとめ、実際は、内容によってはこちらで手伝って、仕様書として文書化していきました。ソフトの設計書では、仕様がどのように、プログラムのコード化されるか、どのコンポーネントや関数で、要求された内容が実現されるか、定義されたデータがどのような変数になっているか、どこで更新されるかなどの情報を定義していきました。また、あらかじめ製品出荷前テストの仕様も作成してもらい、要求仕様を誤って解釈して設計してしまうことを、大きく減らすこともでき、見える化やサンプリングの仕組みも、上手く作り込むことができました。また、ソフトが完成したときの要求仕様書は、とても細部まで細かく定義されたものとして、仕上がっていました。逆に、「こんなに細かい仕様ならだれでもソフト作れるよね」と、周囲からダメ出しされたりもしました。
さて、隣のソフト開発チームはどうなったでしょうか。実は、個々のソフト設計者が仕様を決める状況となり、担当者毎に、仕様の解釈や明確化の度合いが異なり、それらの調整が完全にできないまま開発が進み、ソフトウェアを結合時に色々と不整合が見つかるなど、手戻りが多発して、開発が遅延していました。遅れを取り戻すために、人が増えて、さらに増えた人が独自の解釈で仕様を判断して、他の担当者の解釈との間でさらに矛盾を発生させていったようです。あいまいな要求仕様書をベースにしたソフト設計は、あまりにも修正が多く、計画通りに出荷前のテストを開始することが、できなかったようです。テスト仕様も明確で無いので、テストデータは、おそらくテストの担当者が作成することになるのですが、その準備が十分できたからどうかは、よくわかりません。その時には、こちらのシステムだけで航空機は初飛行を終わらせており、担当分のソフト開発を終わらせた私は、チームメンバーにリーダ―業務を引き継ぎ、その開発現場からは去っていました。こちらの開発が終わった時点で、隣のチームは、こちらのチームより、開発工数が3倍以上かかっていたはずです。
上記の経験から、私は改めて以下の内容が重要と認識しました。
（１）ソフト要求仕様は、明確かつ細かく定義する
（２）ソフト要求仕様は、少人数で決める
（３）ソフトのテスト仕様は、ソフト要求仕様と同じタイミングで作成する
