【松尾谷徹が語る】現場力を高めるテスト(1)この記事どう?ためになった仕事に役立つ知っておくべき検索する印刷その他マイページプロジェクトの大規模化につれて,テストの負担がどんどん大きくなってきた。上流工程をいくら改善しても,バグの探索にかかる時間やコストは変わらない。網羅性と合理性を両立させたテストの技法について解説する。組み込みソフトウエアの大規模化と複雑化に伴い,品質問題がクローズアップされるようになってきた。「品質セントリック」と呼べるほど,組み込み機器の品質に厳しい目が向けられる中で,最後のとりでが本稿で述べる「テスト」である。Z』の掲載記事を抜粋したものです。組み込みソフトウエアのテストには大きく2つのポイントがある。1つは可能な限り数多くの項目について,漏れなくテストを行う「網羅性」である。1つは,テスト項目について必要/不必要をきっちりと押さえる「合理性」だ。開発現場では,できるだけ少ないテスト項目でカバー範囲を可能な限り広げるという相反する要求を満たすことが求められている。した状況に対応する工学的なアプローチとして,筆者は「探索理論」に基づく手法が有効だと考えている。1つ強調しておきたいのは,「人」の問題である。図1に示すように,テストはソフトウエア開発では下流工程に位置する。テスト工程では,単体テストや結合テストに参加する人が,漏れなくテストやデバッグを行わないといけない。テストとは担当者が総掛かりで取り組む作業であり,チームとしての力が非常に重要になる。この点について,開発に携わる多くの方が頭では理解している。実行できているかというと,大いに疑問である。チームとして仕事を進めるというのは結構厄介である。組み込みソフトウエア技術者をはじめ専門家というのは一般に,専門能力は高いが協調性に欠ける面がある。組み込みソフトウエア開発のプロジェクトでは,こうしたプロの集団を集めて仕事を進めなければならない。このプロの集団をきちんと組織化することは,テスト技法に勝るとも劣らないほど重要である。探索理論に解がある組み込みソフトウエア開発は,要件定義から始まって,設計,コーディング,テストへと進む(図1左)。それぞれの工程にどれだけのコストを投じているかを工作機械を例に示したのが図1右である。要件定義はさまざまな調整が必要なので,全体の15%とそこそこのコスト(時間)がかかっているが,設計工程やコーディングのコストは意外に小さい。これはオブジェクト指向技術などのソフトウエア工学の大きな成果と言える。ソフトウエアの開発工程とコスト要件定義と設計が上流工程,コーディングとテストが下流工程と位置づけられる。テストに要するコストが,全工程の実に70%を占めている。テスト工程の合理化が焦眉の急となっている。図は工作機械の例である。組み込みソフトウエア開発のコストにおいて,最大の問題がテストにあることは図1を見れば一目で分かるだろう。実に全体の70%に達するコストを掛けて,上流工程で入り込んだバグをつぶしているのである。ソフトウエア工学の鉄則ともいえる「上流工程をちゃんとやれば下流工程はうまくいく」は確かに正しい考え方である。一生懸命テストをしても,バグは次から次へと出てくる。上流工程に原因があるのだから,そこを正すという考え方は当然である。実際,「テスト技法なんかを勉強するより,原因を取り除く技術をちゃんと入れましょう」と1980年代に偉い先生たちに言われ,筆者も「確かにそうだ」と納得した。テストの技法などを勉強したって,きっと定年のころにはなくなってしまう。テスト工程よりも上流工程を勉強しようとなった。して筆者は,30年間,技術者人生を過ごした。ところが現状は,図1に示すような状況である。テストの問題は全く解決していない。それなら惨憺たる下流工程をもう少しどうにかしようというのが,筆者の考えである。テスト工程を合理化し,バグを効率的に取ることができれば,70%掛かっていたコストが60%なり50%なりに減り,開発現場が抱える問題の解決につながるのではないか。ここで注意してほしいのは,上流工程の改善がダメだと言っている訳ではないということである。上流工程でなければ解決しないことはいっぱいある。上流工程は今後も頑張る必要がある。下流工程もちゃんとやらなければいけないというのが筆者が主張したいことである。テストとは,詰まるところ「探す技術」どうすればテスト工程を合理化できるのだろうか。合理化するなら上流工程と同じように,ソフトウエア・エンジアリングの裏付けをもってテストの合理化も進めたい。ところが,ここで困ったことがある。テストの技術は,ここ何年もさほど進歩していないのである。Myers氏の『ソフトウエア・テストの技法』が,いまだにベストセラーの一角を占めているほどである。Beizer氏の教科書が登場したが,読むのに1年くらいかかるほど分厚いし,読んでもよく分からない。細かい技術はいっぱい載っているが,現場の実態に必ずしも即していない。現場が求めているのは,単体テストや結合テストにブラック・ボックス手法が使えるのか,使えないのかといった実利的なヒントだ。した実践的なところは,ほとんど議論されていないのが現状である。テストの本質は,ものを探すところにある。さまざまなところに隠れているバグを探すことこそ,テストの神髄であり,ここに難しさがある。コンタクト・レンズが広い部屋に落ちているとしよう。落ちている個数は分からない。“5個くらい”とあいまいだ。それを全部探さないといけない。探すのには,かなりの時間がかかる。5個が3個に減ったらどうだろう。探す時間は5分の3になるだろうか。落ちているコンタクト・レンズの数は,“3個くらい”とやはりあいまいだから,3個で打ち切ればよいという話ではない。“5個くらい”も“3個”くらいも,探す時間は変わらない。ここにテストを合理化することの難しさがある。バグを見つけるにはくまなく探さなければならない。見つけたバグを改修する作業は,入っているバグの数に比例するが,探す作業はバグの件数には関係ない。ちなみに,上流工程を頑張るということは,改修するバグの件数を減らすことを意味する。網羅的に探す手間は,上流工程の優劣とは関係ない。こんなことは少し考えれば分かることだが,なかなか気付かれなかった。上流工程におけるバグ含有率や含有件数を減らす努力とは別に,バグを探す技術をきちんと確立しなければならないのである。Reserved.このページに掲載されている記事・写真・図表などの無断転載を禁じます。著作権は日経BP社、またはその情報提供者に帰属します。表示切替:スマホ|パソコン。