ホーム > GAIO CLUB > GC ONLINE Vol.03 : 単体テストを実施して単体品質を向上するための課題

GC ONLINE Vol.03 : 単体テストを実施して単体品質を向上するための課題

いまや、単体品質を確認するための「単体テスト」は、製品の分野を問わず、組込みソフト開発の基本事項となっています。本特集では、単体テスト導入に成功したお客様の情報を基に、単体テストを運用しプロセス化するためにクリアすべき課題について解説します。

ソフト品質問題を抱える組込み製品が増えています

開発するソフトの規模が大きくなるに伴い、ソフト品質問題を抱える組込み製品が増えています。これは、組込み開発に依然として多く残っている文化である「実機信仰」型の開発が１つの原因となっています。「実機信仰」型とは、実機で動けば全て良しの考え方のことで、要求仕様が決まり、コーディングを行った後、直ぐに実機やICEにソフトを載せてデバッグを始め、それだけでテストを終えてしまうスタイルです。

この実機によるシステムテスト中心の検証では、関数などの単体レベルでのソフト検証が不十分となり、システムテストで発見できない単体依存の不具合を、出荷製品に潜在させてしまいます。市場で問題を起こし、その原因を特定してみると、コーディング上のケアレスミスであることも珍しくありません。

組込みソフトの単体品質を確認し保証する「単体テスト」

人がコーディングする以上は、プログラムに不具合を作り込んでしまう事は避けられません。それならば、組込みソフトの単体品質を確認し、人間が作り込んでしまったミスを検出するテスト工程は必ず必要です。いまや、単体品質を確認するための「単体テスト」は、製品の分野を問わず、組込みソフト開発の基本事項となっています。

単体テストツールを比較検討して購入するだけでは実は何も解決出来ません

単体テストを実施して、プロセス化、定着化するには、クリアすべき課題が多くあります。ツールを比較検討し、使い勝手などを調べて、購入するだけでは、単体テストを定着運用することはできません。この原因には次のような理由があります。

●単体テストが製品品質に及ぼす影響を定量的に図ることが難しい
●単体テストの工数負担が大きく開発の工程に組み込むことができない
●単体テストデータ作成が難しく担当者のスキルに依存ししまいテスト品質がばらついてしまう
●ツールを使用するための準備や学習に負担が大きい

これらは、ツールの機能や使い勝手の良さだけで解決することは難しく、単体テストへの理解や運用時の体制作りが重要なポイントとなっています。

単体テストを実施して単体品質を向上するためにクリアすべき課題とは？

単体品質向上は、製品の品質改善のほんの一歩に過ぎませんが、これを実施するだけでも一筋縄では行かないのが現実です。ガイオは、単体テストを導入して運用に成功するお客様と、そうでないお客様の事例を数多く見て参りました。そこで、単体テスト導入に成功したお客様の情報を基に、単体テストを運用しプロセス化するためにクリアすべき課題について解説します。

単体テストへの正しい理解が必要　～経営/管理者と開発者双方に～

■単体品質は「企業の経営」に大きな影響を与える

組込みソフトの単体品質は、市場にリリースされる製品の品質に大きな影響があります。この単体品質が、「企業の経営」に与える影響を経営者/管理者が正しく理解することが、最も重要なポイントです。

■重要性を理解していても行動しない、行動できない

多くの開発者は、単体品質の保証が重要であることを頭で理解していても、自ら行動して、実際に単体テストを実施して成功する例は稀です。これは、企業内に多くの障害があるからです。

・技術への理解が乏しい経営者には重要性が理解されない
・経営事情からコストや開発期間が優先されてしまう
・管理者の品質意識が乏しくテストにコストが掛けられない

企業内で経営/管理と開発者の双方が、単体品質の影響を理解することが品質改善活動の第一歩です。

単体テストの標準化、機械化　～人に依存しないテストと自動化が必要～

■人に依存するテストでは品質を正しく計測できない

単体テストを実施するに当たり、最初の課題となるのが「どの様にして単体テストを設計するか？」です。明確な設計指針を作らずに実施すると、テスト品質は担当者の経験やスキルに依存してしまい、プロジェクト全体のソフト品質を判断することは困難です。まず、人に依存しないテスト設計、実施方法を確立することが必要です。

■単体テストに掛かる工数問題を解決する

単体テストは、ソフトの基本要素である関数が対象です。対象関数の個数は、システムにより数百、数千個となり、手作業での実施は、ほぼ不可能です。実施には、可能な限り作業を機械化することが必須です。機械化すべき項目は多くあります。

　・テストの準備（仕様情報の抽出、ソース解析）
　・テスト設計（テストデータの作成、テスト設計レビュー）
　・テストの実行と判定（期待値合否判定、カバレッジ計測）
　・結果の集計と管理

教育、継続運用の体制作り　～活動定着チーム、専任者が必要～

■テスト方法、指針の「マニュアル化」が必要

単体テストは、ソフトに潜在する不具合を検出することが目的です。そのため、要求される単体品質を満足するためのテスト指針、テスト方法を定義し、人に依存しないテストのためのマニュアル化を進めることが必要です。また、テスト担当者に徹底して実施させ、継続運用を行うためのサポートも必要事項の１つです。

■活動定着チームの常備と即応サポート体制が必要

単体テストは、プロジェクト、企業全体でのソフト品質改善活動です。開発者各人に任せる体制では運用定着は難しく、専任の活動定着チームが必要です。改善活動に成功している企業は、例外なく活動定着チームを持っています。
テスト担当者に対する啓蒙、教育を実施し、短期間でテストマニュアルを正しく理解させるサポート体制が必要です。

結果の可視化/見える化　～進捗・効率・品質の正しい把握が必要～

■プロジェクト全体のテスト結果、進捗を一箇所に集計

単体テストは、多人数の技術者が関わるのが普通です。日々のテスト作業や進捗から、テストの効率を判断したり、テスト結果からプロジェクト全体のソフト品質を把握するには、結果や進捗を一箇所に集計した「見える化」を進め、テスト工程の問題点を早急に把握できるシステム作りが必要です。テストツールの運用状況を可視化することも重要です。

■テスト合否判定の基準を明確に定義することも必要

本質的にテストには「100% OK」となるゴールはありません。厳密に行おうとすれば幾らでも行えるものであり、「どこまで行えばOKか」の指標は、テスト毎に設定する必要があります。このためには、プロジェクト全体のテスト結果を見通した上で、ゴールとするラインを引く必要があります。