Dual Target Testingで組み込みソフトウェアの品質を早期に作りこむ

4/22(日)に「Test Driven Development for Embedded C 読書会 第3回」を開催しました。当日のやり取りはTogetterにまとめていますので、そちらもご覧ください。

この日は以下の2章をやりました。

• 第5章「Embedded TDD Strategy」
• 組み込みシステム開発でTDDをやる上で重要なDual Target Testingについて紹介されています。
• 第6章｢Yeah, but...｣
• TDDを実開発に導入する上でよく聞かれる反対意見とその意見に対する反論が書かれています。

本エントリでは第5章の内容をご紹介します。

ハードウェアとソフトウェアの並行開発が組み込みシステム開発を難しくしている

組み込みシステム開発では、ハードウェアとソフトウェア開発が並行で走ることがよくあります。

以前、「組み込み開発のリスクである「ソフトウェアとハードウェアの並行開発」の解決方法の一つが組み込みTDDじゃないだろうか？」というエントリでもそのことについて書きましたが、この並行開発が組み込みシステム開発が困難になる理由だと私は考えています。それはソフトウェアとハードウェアの両方にバグが混入された状態で開発が進むため、原因の切り分けが非常に分かりづらいバグが発生することがよくあるからです。

並行開発について少し例を挙げてみましょう。私が経験した組み込みシステム開発では、以下のようにいくつかイテレーション（フェーズとも言う）を区切って、イテレーションごとに機能のスコープを切り、イテレーションの最後にハードウェアとソフトウェアを結合して、品質評価をやるというスタイルを取っていました。こういうプロトタイピングを繰り返し、だんだん仕様を固めていくスタイルはよくあるのではないでしょうか？

このように繰り返しプロトタイピングしながら進めていくスタイルでは、

• 開発序盤にそもそも次期製品のハードウェアがない。
• たいていの場合は、チップ周りを担当する人には本当に最小限の回路が乗っているハードが提供されて、OSの立ち上がりの確認をしたりする。
• もっとユーザ寄りの機能を担当する人は、前製品のハードウェアが提供され、全製品と重複している箇所の動作確認からはじめたりする。
• ソフトウェアとハードウェア双方にバグがある。

という状態で進みます。

そして、イテレーションの最後に結合してリリースした後の品質評価が大量のバグが上がってくると、まずはバグの原因はハードウェアなのかソフトウェアなのかの切り分けから始まります。双方の品質が低い状態なので原因の切り分けははっきり言うと難しいです。そのため、ソフトウェア技術者にとってはソフトウェアにバグはないと確認し、自信を持って主張するためのエヴィデンスの確保に大量の時間を取られてしまいます。

はっきり言って、この時間は不毛だし、生産的ではないでしょう。この不毛な時間を少しでもなくし、より生産性の高い開発を実現するために、組み込みソフトウェアエンジニアは日夜、ハードウェアが届く前にソフトウェアの品質を作りこむことに力を注がなくてはいけません。


Dual Target Testingでソフトウェアの品質を早期に作りこむ

ハードウェアが届く前にソフトウェアの品質を作りこむにはどうしたらいいんでしょうか？書籍で推奨されているのがDual Target Testing、つまりターゲット・ハードウェアとPC上の両方でテストできるようにすることです。

書籍では、以下のプロセスでテスト駆動な開発をしろと解説しています。

特徴は以下。

• 最初の段階で、徹底的にPC上で単体テストとリファクタリングをして、単体レベルのソフトウェアの品質を確保してから評価ボードに持っていく。
• デバッグ環境の貧弱な評価ボード上で単体レベルのロジックのミスを見つけるような、不毛な作業がなくなります。
• PC上でターゲット用のコンパイルを行ったり、評価ボードやターゲットハードウェア上でも単体テストを動かすことで、ホスト環境とターゲット環境の違いによるバグを早期に見つける。
• ターゲットハードウェアに対する受け入れテストも用意する。

ここでやっているのはあくまでも単体テストなので、単体テストのスコープの検証しかできませんが、評価ボードに持っていくまでに品質を確保できているので、まず開発の立ち上がりがスムーズに行くと考えられます。

また、PC、評価ボード、ターゲット・ハードウェアの3つに対して単体テストが自動的にできるため、結合した上で単体レベルの動作確認などが不要になります。結合した時に振る舞い、あるいはマルチタスクの微妙なタイミングによリ発生するバグなど、もっと複雑な不具合の究明に力を注ぐことができるはずです。

Dual Target Testingをやるには地道に単体テストを積み上げる必要がある

ただし、自動テストをやるには単体テストが用意されている必要があります。これは、いきなり評価ボードに持っていって実機デバッグをやるより、はっきり言って時間のかかる作業だと思います。

単体テストを作らずに評価ボードで実機テストを繰り返すスタイルは、直近で見ると一見手間がかからなくて楽な方法です。しかし、機能を追加するとテスト作業が全てが手作業になり、繰り返し単体レベルの動作を保証することはできません。また、途中で混入したデバッグ作業に時間を浪費し、生産性の向上は見込めません。

Dual Target Testing用に単体テストを積み上げていくスタイルは、直近で見ると時間がかかり、進捗は遅くなりますが、開発を進むにつれて混入したバグを即座に発見することができるため、デバッグ時間の節約にもなり、より難易度の高い不具合の究明に時間をさけるようになります。

この開発時間についてどう捉えるかは6章で扱っているので、そちらで紹介したいと思います。

どうやってDual Target Testingをやるの？

具体的なテクニックは第7章「Introducing Test Doubles」以降で紹介されています。次回の読書会で扱う予定。その際にまたブログで紹介したいと思います。