CodeZine(コードジン)

特集ページ一覧

テストプロセス改善で93件あった市場バグが10件に! ソフトウェアのバグを削減しよう【実践編】

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

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

目次

テストプロセス改善の具体例

確立工程(Establishing)

 確立工程では、診断工程で承認を得た提案書を詳細化します。具体的には、アサイン可能な人員や組織の狙いなどさまざまな要因を考慮して、優先順位、アプローチ方法、行動計画を立てます。

優先順位の設定

 確立工程の1つ目は、「優先順位の設定」です。ここでは、診断工程で提案した改善内容について優先順位をつけます。改善内容が多い場合や厳密性が求められる場合は、コストと効果から点数をつけて決定します。それほど厳密性を求められない場合は、頭の中だけで決定する場合もあります。

 例えば、今回の例でいうと、「QUINTEEのカスタマイズとRedmineのマニュアル作成は同じ人がやるので、同時にはできない。プロセスのほうが影響度が高いので、QUINTEEのカスタマイズを先にやってから、Redmineに移ろう」といった具合です。

アプローチの策定

 確立工程の2つ目は、「アプローチの策定」です。人員や技術要因、コストなどの観点から、どのように改善を実現するか決めます。例えば、診断工程で、バルテスのテストエンジニアをアサインすることを決めましたが、具体的にどのように進めるか決めないといけません。具体的にいうと、人選をどうするか、いつからスタートするか、契約をどうするか、入場方法はどうするか、システムのトレーニングをどうするかなどを決めていきます。

行動の計画

 確立工程の3つ目は、「行動の計画」です。診断工程の提案内容、優先順位、アプローチ方法をもとにして、作業を分解します。作業の分割方法は、WBS(Work Breakdown Structure)を利用しても良いですし、PERT図(Program Evaluation and Review Technique)やガントチャート(Gantt Chart)を利用しても良いです。読者の慣れ親しんだやり方で作業を進めてください。ポイントとしては、詳細作業内容、スケジュール、マイルストーン、責任、計測方法、確認方法などを明確にすることです。

行動工程(Acting)

 行動工程では、確立工程で立てた行動計画を実行します。計画を立てても行動されなければ、絵に描いた餅になってしまいます。よって、計画した行動が確実に実行されるようにする必要があります。

解決策の作成

 行動工程の1つ目は、「解決策の作成」です。ここでは、確立工程で作成した行動の計画を実行していきます。例えば、QUINTEEを実際に、XYZソフトウェア社の業務に合うようにカスタマイズしたり、Redmineの環境の構築やマニュアルを作成したりします。進捗は朝会や進捗会議で確認します。

先行評価/施行の実施

 行動工程の2つ目は、「先行評価/施行の実施」です。このような改善を実施する際、いきなり全体に適用するのではなく、小さく試すのが賢いやり方です。実際に試してみないと、分からないことが多いからです。また、適用事例があったほうが全体に適用するときに便利です。本例でも、診断工程の提案書のスケジュールで示した通り、PoC(試験実施)期間を設けています。

解決策の改良

 行動工程の3つ目は、「解決策の改良」です。「先行評価/施行の実施」で見つかった問題や課題を解決して、解決策をリファインします。例えば、カスタマイズしたQUINTEEのフォーマットを実際に使ってみると、使いにくい部分があることもあります。その部分を、使いやすくリファインすることが該当します。筆者はこのリファインがとても重要だと考えています。そのため本例では、PoCの他に、四半期ごとに振り返りを実施してリファインの機会を作っています(図8「5.スケジュール」参照)。

解決策の実施

 行動工程の4つ目は、「解決策の実施」です。「解決策の改良」でリファインした解決策を全体に適用していきます。ここでは、マニュアルをそろえたり、説明会を開いたり、事例を紹介したり、バックアップ体制を整えたりして、しっかり準備することが大事です。筆者は、1回の説明では全体の半分も伝わらないと考えています。よって、根気よく実施していくことが重要です。

学習工程(Learning)

 IDEALモデルの最終工程は、学習工程です。学習工程では、このテストプロセス改善で何を達成し、何を達成できなかったか、効果はどうだったかを確認します。また、次の改善につなげる提案をします。

分析と検証

 学習工程の1つ目は、「分析と検証」です。ここでは、テストプロセス改善の成果や効果を、分析・検証していきます。まずは、QUINTEEとRedmineの適用および弊社のテストエンジニアをアサインして、テストプロセスがどの程度、充足したかを検証します。比較できるように、診断工程の時と同様にTPI NEXTで診断します。診断結果は、図9のようになりました。緑の部分が充足している部分ですが、テストプロセス改善前が5箇所だったの対して、改善後は59箇所と充足箇所が増えています。

 今回は、TPI NEXTを順番に改善していくというより、市場バグの低減に効果のある箇所を優先したのと、リソースの都合でところどころ歯抜けになっています。その部分については、今後の改善対象になります。

図9:QUINTEE適用後の診断結果
図9:QUINTEE適用後の診断結果

 次に、テストプロセス改善が、どのようにテストの能力に影響したのかをみていきます。ここでは、(1)バグの摘出能力 (開発単位(KLOCもしくはFP)あたりのバグ数)、(2)1テスト実行あたりの単価、(3)1バグあたりの単価の3つを確認します。確認の結果、図10のように、バグの摘出能力は約240倍、1テスト実行あたりの単価は約1/4、1バグあたりの単価は約1/157になりました。

図10:テストプロセス改善効果(テスト能力)
図10:テストプロセス改善効果(テスト能力)

 最後に市場バグが、どの程度減ったのかみていきます。確認の結果、図11のように、昨年93件から今年は10件と89.2%の改善効果がありました。この結果は、診断工程の提案書で設定した「努力目標:13件/年以内の市場バグ」を達成する結果となりました。

図11:テストプロセス改善効果(市場バグ)
図11:テストプロセス改善効果(市場バグ)

 これらのテストプロセス改善結果は、診断工程の提案書の時と同様に、図12のように1枚の報告書としてまとめます。

図12:テストプロセス改善結果の報告
図12:テストプロセス改善結果の報告

将来活動を提案

 学習工程の2つ目は、「将来活動を提案」です。ここでは、テストプロセス改善の実行の結果から、次の改善の提案をします。TPI NEXTの歯抜けの部分の対応でも良いですし、XYZソフトウェア社のテストエンジニアをトレーニングして、自分たちでテストをできるようになるという提案でも良いです。もしくは、適用したQUINTEEのさらなる改善かもしれません。これらの改善提案は、図12で示したテストプロセス改善結果の報告書に含める場合もあります。

 以上で、IDEALの全てのプログラムは終了になります。ただし、将来活動の提案が承認され、さらなる改善を実施する場合は、次のサイクルが始まります。

最後に

 いかがでしたでしょうか? テストプロセス改善について3回にわたり連載してきました。第1回では、テストプロセス改善がなぜバグの削減につながるのかを考察した後、テストプロセス改善の分類として、 (1) モデルベースドアプローチ、(2) 分析的アプローチ、(3) ハイブリッドアプローチ、(4) その他のアプローチの4つを紹介しました。第2回では、テストプロセス改善のメリットと課題を解説した後、課題を低減するためのヒントを紹介しました。

 第3回では、実践編として、テストプロセス改善の流れについて、具体例を示しながら解説しました。具体例は、本連載用に新規に作成したものですが、市場バグが93件/年から翌年10件/年に89.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