IoT時代の組み込み系ソフトウェア品質（5）

ソフトウェア品質のためにテストが「できること」「できないこと」（3/5 ページ）

公開 2017年12月13日 09時00分

更新 2018年02月23日 14時05分

著者

五味弘

[TechFactory]

印刷する連載新着通知を受け取る

ソフトウェアテスト、最大の問題点

　テストがヒトに依存し、テストに不向きな品質特性が多いということが、テストによる品質制御の問題であるが、テストで品質の弱点を見つけるという考えや手法そのものは間違っていない。実際、テストは品質向上に最大の貢献を果たすだろう。しかし、テストには、テストにだけ発生する大きな問題がある。

　テストはソフトウェア開発の3割から4割程度のコストを使う（*）ので、お金も大きな問題であるが、お金の問題はテストに限ったことではないので、これは違う。ヒトの問題も大きいが、これもテストに限ったことではない。

（*）IPA/SECのソフトウェア開発データ白書2016-2017 p.191、組込みソフトウェア開発データ白書2017 p.80（改良開発）。

　テストの最大の問題点とは「テストで品質の弱点が見つかった時には既に手遅れ」であることだ。納期が迫っている段階で、大幅に手直しが必要な品質の弱点が見つかっても既に手遅れである。時間こそがお金よりも問題になるリソースであり、テストが完成後に行われる構造に起因する、手の打ちようがない問題である。

　このテストの最大の問題をカバーするためには、早め早めの作りこみとテストが必要であり、上流工程での品質活動が望まれる。完成後のテストでは遅すぎる。そこで比較的早期に実施できるレビューについて、次節で考えてみる。

コードレビュー（静的テスト）と品質向上

　コードレビューは静的テストである。ここまで「ソフトウェアテスト」と呼んでいたテストは、実際のプログラムを動作させる動的テストと呼ばれるものだが、コードレビューは実際にプログラムを動作させないので静的テストと呼ばれている。

　レビューはソースプログラムやドキュメントなど、知覚できるものであれば何でも対象になる。レビューは通常、レビュー対象を作った人、コメントするレビュワー、司会進行の議長、それに記録係で行う。人数は5～6人が望ましく、時間は1時間程度が適切だ。大人数で行う「ワールドワイドレビュー」や長時間に渡る「ロングランレビュー」は集中を欠くのでおすすめできない。

　レビューは直接ならび間接的に、品質向上へ貢献する。直接的には指摘を受けたところを直すことによって欠陥がなくなり、間接的にはレビュワーの考えを聞くことで、その考えを自らの血肉にできる。このように、レビューをすると参加者全員が一番優れたレビュワーのスキルに近づくことができる（ように感じる）。特に新人など経験が少ないメンバーにとって、レビュワーの経験や知識を基にしたコメントは、下手な講義や書籍より何倍もの効果がある。

　また、レビューを受けなければならない恐怖と、レビュワーからのするどい質問に答えなければならないという恐怖がレビュー対象物の品質を向上させる。心臓に毛が生えていても、いい加減なものはレビューの場に出せないということが恐怖とともに実感できる。

　このようにレビューは（短時間、少数で行う限り）品質向上に大きな効果が期待でき、加えて動的テストよりも早期に実施されるので、「問題が発覚した時点で既に手遅れ」という事態を避けることもできる。

図3 レビューの御利益とオキテ

次ページへ組み込み系テストが品質のためにできること

印刷する

IoT時代の組み込み系ソフトウェア品質

組み込みソフトウェアにおける「品質」とは、一体、何者であろうか。多用されている言葉であるがその実態はようとしてしれない。この連載ではIoT時代の組み込み系ソフトウェアの品質」をテーマに開発現場の目線で見ていく。出演者は情報系に籍を置く大学1年生の紅美香美（くみこうみ）と品質寛容（しなしちひろい）。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

五味弘

OKI（沖電気工業）シニアスペシャリスト、エバンジェリスト。博士（工学）。ソフトウエアの開発支援・教育に従事。電子情報振興協会（JEITA）専門委員会の委員長や情報処理振興機構（IPA/SEC）などの委員多数。三重大学などの非常勤講師も務める。エンタープライズ系と組み込み系におけるソフトウエア開発の知見融合が関心事。共著書に『定量的品質予測のススメ』（オーム社、2008年）、『プログラミング言語論』（コロナ社、2008年）などがある。