CodeZine(コードジン)

特集ページ一覧

テストプロセス改善にはどんなメリットが? 課題を低減するためのヒントをテスト専門企業が伝授

「テストプロセス改善」をしてバグを削減しよう 第2回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 前回は、テストプロセス改善がなぜバグの削減につながるのかを考察した後、テストプロセス改善の分類を紹介しました。今回は、テストプロセス改善のメリットと課題を解説し、課題を低減するためのヒントを紹介します。テストプロセス改善には、市場バグを削減できるなど多くのメリットがある一方、効果を得るまでに時間がかかったり、テスト作業が増加したり、ステークホルダーの理解を得られなかったりする課題もあります。それらの課題を対策せずにテストプロセス改善を進めると、ステークホルダーから抵抗にあったり、改善がなかなか進まなかったり、最悪の場合、時間とコストだけ浪費して効果が得られないという結果になることも。そのため、事前にどのような課題があるかを把握し、対策を立てておくことが成功への近道です。本稿では、その課題を低減するためのヒントをお伝えします。

目次

対象読者

  • 市場バグが多くどうにかしたいエンジニア読者
  • テストプロセス改善のメリットを知りたいエンジニア読者
  • テストプロセス改善の課題と、課題低減のヒントを知りたいエンジニア読者
  • テストプロセス改善をこれからやってみようとしているエンジニア読者

テストプロセス改善のメリット

 筆者はソフトウェア品質の専門家として仕事をしている関係上、テストプロセス改善に携わる機会が多くあります。テストプロセス改善にはさまざまなメリットを感じているのですが、その中で最も大きいと考えるメリットが以下3つです。

  1. 市場バグを削減できる
  2. 相対的にコストが安くなる
  3. メンバーのスキルが向上する

 それでは、それぞれについて詳しく見ていきましょう。

1. 市場バグを削減できる

 筆者が最もメリットを感じているのは、市場バグの削減です。読者の中には、市場バグを出してしまい、夜通しでバグ修正に追われたという方もいるのではないでしょうか? 筆者も開発をしていた時代に、市場バグを出してしまい何日も眠れない日々が続いた苦い経験があります。顧客にもエンドユーザーにも迷惑をかけてしまい、申し訳ない気持ちでいっぱいでしたし、コストもかかりました。このように市場バグは誰も得をしない、やっかいな存在です。

 市場バグを出さないためには、そもそもバグを混入させないことですが、バグの混入の予防は計画・技術・マネジメントの総合力が必要で、ある程度時間も必要です。なぜならば、バグの混入の予防は、事前に人が間違えそうなプロセスを見つけ、人が間違わないようにする仕組みをプロセスに組み込まないといけないからです。

 一方で、すでに混入してしまったバグをできるだけ多く検出するなどテストの質を強化するほうが、比較的取り組みやすく、効果が出やすいです。さらに、システムテスト工程のほうが動くシステムで検証できるため効果が見えやすいです。よって、改善の順序としては、最終工程から前工程に順番に改善していく(シフトレフトと言います)ことが良いと考えています。

 さて、市場バグが多く発生している状態は、前工程であるテストでバグを適切に検出できていないことを意味します。つまり、テストの品質が悪いということです。テストの品質について、元IBMでソフトウェア開発の定量化手法の専門家であるCapers Jones氏が、ソフトウェアテスト技術者向けイベント「JaSST '08 Tokyo」の基調講演にて、「当時のIBMではテスト・ケースの3分の1に誤りがあった」 (出典:日経xTECH ニュース)と述べています。

 テスト専門会社の専門家として、筆者はいろいろな企業のテストを見てきましたが、このことはIBMに限った話ではなく多くの企業に当てはまると考えています。そのため、テストプロセスを改善すればテストの品質が向上し、バグ検出能力が向上します。その結果として市場バグを削減することができます。

 ただし、東海大学 大学院 山浦恒央博士が「猛烈な勢いで発生していたバグが、ある瞬間からゼロになることは絶対に、絶対に、絶対にありません」(出典:山浦恒央の“くみこみ”な話

)と述べています。

 また、ソフトウェアバグの障害率を表したモデルにRayleigh(レイリー)モデルがあります(図1)。このモデルはバグをWeibull曲線で表しており、「総バグ数(K)」と「バグがピークとなる工程(tm)」が分かると、各工程のバグ除去率パターンが分かるというものです(参考:『ソフトウェア品質知識体系ガイド -SQuBOK Guide-』 )。

 つまり、バグのピークから次工程でなめらかにバグが減っていくことを意味します。例えば、システムテストで多くのバグを検出している場合、次工程の本番でいきなりゼロになる(曲線でなく線が垂直になる)ことはありません。なお、市場バグが多く発生している状況は、バグのピークが図1よりも右側になっていることを意味します。

図1:Rayleighモデル (バグの統計モデル)
図1:Rayleighモデル (バグの統計モデル)

 さらに、山浦博士によると、「経験的に、プログラムを変更すると1カ所につき20%の確率で新しいバグを作り込みます」 (出典:山浦恒央の“くみこみ”な話) と述べています(フレデリック・ブルックス氏の名著『人月の神話』にも「プログラムの変更は20~50%の確率で新しいバグを呼び込む」と記載があります)。

 つまり、テストによってバグを顕在化しても、バグの修正過程で新たなバグが混入してしまいます。もちろん、バグの確認テストやリグレッションテストである程度は再検出できますが、バグの数が多いとそれにも限界があります。そのため、テストプロセス改善で市場バグを削減できますが、ゼロにするのは非常に難しいので、過度な期待をしすぎないようにしてください(いわゆる銀の弾はなく、地道な改善が必要になります)。

2. 相対的にコストが安くなる

 バグの修正は、バグが作り込まれてからそれが見つけられるまでの期間が早ければ早いほど、バグの修正コストが安くなります。例えば、基本設計工程でバグを見つけ修正した場合、修正対象は基本設計工程だけです。しかし、システムテスト工程でバグを発見すると、修正対象は基本設計・詳細設計・プログラミングといった前工程全てになります。このようなことから、市場バグは最も修正コストが高くなります。もし、市場バグを1つ前の工程であるシステムテストで検出することができれば、コストがその分安くなります。

 ただし、システムテスト工程でバグを多く検出すると、システム工程のコストは増えます(全体で見るとコストは安くなります)。このように、前工程の負荷を上げて、問題を以前よりも早く発見し、コストを下げることを「フロントローディング」と言います。

 頭で分かっていても、納期のプレッシャーが強いときは、フロントローディングをするのには勇気がいります。その点、システムテストのバグは目に見えて分かりやすいため、ステークホルダーの理解を得やすいです。そのこともあり、筆者は最終工程から前工程に順番に改善していくのが良いと考えています。市場バグが多発しているなら、その1つ前のシステムテストから改善していきます。

 コストの削減効果は業界や企業によって違うので、企業でデータを収集して算出する必要があります。そのようなデータがない場合は、データが準備できるまでは一般データを使うことになります。ここで参考になるのが、Rex Black著『ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために』のP.87で紹介している、Barry Boehm著の『Software Engineering Economics』のデータです(表1)。

表1:バグの修正コスト(『Software Engineering Economics』をもとに筆者が作成)
フェーズ バグの修正コスト
要件・設計フェーズ 1ドル
プログラマによるテスト 10ドル
システムテスト 100ドル
リリース後 (市場バグ) 1000ドル

 人件費やプロセスによってコストは変わりますが、重要なことは、市場バグの修正コストはシステムテストに比べて非常に大きいということです(表1では、10倍の開きがあります)。よって、テストプロセス改善をすることで、市場バグを削減できれば、かなりのコスト削減効果を期待できます。

3. メンバーのスキルが向上する

 テストプロセス改善をしていくと、プロセスの明確化、仕組み化、マニュアル化が促進されます。それらはメンバーのスキル向上に寄与します。「無印良品」を赤字から立て直した経営者の松井忠三氏の著書『図解 無印良品は、仕組みが9割』の中で、「当時、経理部が一人前になるには15年かかっていた。それが明文化してマニュアルを作成したこところ、2年で一通りの仕事を覚えられ、5年もあれば一人前になった」という内容を述べています。

 ソフトウェアテストは、経理とは違いますが、人が学習する過程は同じはずです。つまり、プロセスを明確化し、作業をマニュアル化すれば、メンバーのスキルが早く向上します。

 弊社の例では、「QUINTEE(クインティ)」というソフトウェアテスト知識体系(プロセス、仕組み、マニュアルを含む)をもとに、トレーニングしています。その結果、未経験者でも数カ月で、テストの全体像をつかみ、ある程度の作業がこなせるようになっています。

 また、以前執筆した探索的テストの記事でも紹介しましたが、探索的テストのプロセスを明確にし、仕組み化・マニュアル化することにより、今までシニアテストエンジニアでないとできなかった探索的テストが、1~2年目のテストエンジニアでも、ある程度の品質でできるようになりました。このことより、テストプロセス改善がメンバースキル向上に良い影響を及ぼすと考えています。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:「テストプロセス改善」をしてバグを削減しよう

著者プロフィール

  • 高木 陽平(VALTES ADVANCED TECHNOLOGY INC.)(タカギ ヨウヘイ)

      東京理科大学大学院 技術経営修士(MOT)卒業。バルテスのフィリピン子会社であるVALTES ADVANCED TECHNOLOGY INC.の取締役。今まで、多数のソフトウェアテストやテストプロセス改善の業務に従事。大学でソフトウェア工学の研究室に入り、プロセス改善を研究。そのこともあり、CM...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5