SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

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

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

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

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

 本連載の第1回では、テストプロセス改善がなぜバグの削減につながるのかを考察した後、テストプロセス改善の分類を紹介しました。第2回では、テストプロセス改善のメリットと課題を解説した後、課題を低減するためのヒントを紹介しました。今回は実践編として、テストプロセス改善の流れについて、具体例を示しながら解説します。具体例は、弊社がある金融会社のテストプロセスを改善して、市場バグが93件/年から翌年10件/年に89.2%改善した事例をベースにしています。しかし、実際の情報をそのまま出すわけにはいかないので、そのエッセンスだけを参考に、全て新規に作成しました。そのため、本記事で示した例は、実際の企業や業務内容とは一切関係しません。また、読者の皆さまが理解しやすいように、具体例はなるべくシンプルになるように努めました。

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

対象読者

  • テストプロセス改善をこれから挑戦しようとしているエンジニア読者
  • テストプロセス改善の流れを知りたい読者

テストプロセス改善のためのプロセス

 テストプロセス改善をするときに、きちんとプロセスに沿って実施していくのが重要です。プロセスが重要と言っておきながら、自らがプロセスを守らないようでは笑い話にもなりません。

 テストプロセス改善のためのプロセスとして、「International Software Qualification Board Expert Level Syllabus Improving the Testing Process(Implementing Improvement and Change)2011」で、デミングサイクル (The Deming Cycle:PDCAサイクルとも呼ぶ)と、IDEAL改善フレームワーク (The IDEAL improvement framework)の2つが紹介されています。

 PDCAサイクルはご存じの方が多いと思いますが、IDEAL改善フレームはあまりなじみないかもしれません。しかし、IDEAL改善フレームは、テストプロセス改善モデル (Test Process Improvement Models)のTMMiでも紹介されているので、理解しておくことがオススメです(CMMiでも紹介されています)。

 そのため本記事では、IDEAL改善フレームワークに沿って説明することにします。ただし、読者が実際にテストプロセス改善するときは、PDCAサイクルでも良いですし、別のプロセス、例えばシックスシグマのDMAICでも良いですし、会社指定のプロセスでも構いません。

IDEAL改善フレーム

 「IDEAL改善フレーム」は、「Test Maturity Model integration(TMMi) Guidelines for Test Process Improvement Release 1.2 (以降、TMMi Framework)」のAnnex Bに解説が載っています(英語です)。さらに詳しく知りたい方は、こちらも英語になりますが、カーネギーメロン大学ソフトウェア工学研究所(Software Engineering Institute:SEI)が提供しているユーザーガイドに詳しく記載されているので、参照するとよいでしょう(ちなみに、IDEALはSEIのサービスマークです)。

 ただし、この情報は、1996年発行と少し古く、最後の「L」を「Learnig」ではなく「Leveraging」にしているなど、現行のIDEAL version1.1と違いが多くあります(筆者の知る限り、version1.1は概要説明だけで、ユーザーガイドはありません)。

 さて、ここでは「TMMi Framework」の解説に沿って、「IDEAL改善フレーム」の概要を紹介します。「IDEAL改善フレーム」は、表1のように5つの工程があります。各工程は、IDEALの頭文字からなり、「開始(I)」「診断(D)」「確立(E)」「行動(A)」「学習(L)」で構成されています。「PDCAサイクル」と比較すると、計画を立てる「確立(E)工程」の前に、「開始(I)工程」と「診断(D)工程」があるのが特徴です。

 「開始(I)工程」は、プロセス改善をするための体制や基盤を構築します。「診断(D)工程」は、現状を診断し、あるべき姿と比較します。「PDCAサイクル」ではそれらの作業が「P」の中に含みますが、独立した工程にすることで、より強調されます。筆者はそれらが特に重要になってくると思っているので、プロセス改善をする際は「IDEAL改善フレーム」をよく使います。

表1: IDEAL 5工程の改善サイクル (「TMMi Framework」のTable B.1を筆者が翻訳)
頭文字 工程 ゴール
I
開始(Initiating)
プロセス改善の成功にむけて、初期の改善体制を構築する
D
診断(Diagnosing)
あるべき姿に対して、組織の現状を確認する
E
確立(Establishing)
計画を立て、どのように改善していくか特定する
A
行動(Acting)
計画を実行する
L
学習(Learning)
経験から学び、改善の能力を向上させる

 5つの工程にはさらに、2~4の改善プログラムからなります(図1)。段取り八分という言葉がありますが、テストプロセス改善にも当てはまります。IDEALでは、最初の3工程が段取りにあたるので、特にここをしっかり理解しましょう。ただし、これはプロセス全般に言えることですが、プロセスに固執しすぎないように注意しましょう。プロセスが実情に合わないと判断したら、躊躇せずに実際の状況に合わせて、プロセスを追加・変更・削除をするようにしてください(これをテーラリングと言います)。

図1:各工程の改善プログラム(出典:ITmedia 情報マネジメント用語辞典 IDEALモデルhttps://www.itmedia.co.jp/im/articles/0711/06/news134.html)
図1:各工程の改善プログラム(出典:ITmedia 情報マネジメント用語辞典 IDEALモデル

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
テストプロセス改善の具体例

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
「テストプロセス改善」をしてバグを削減しよう連載記事一覧

もっと読む

この記事の著者

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

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15197 2021/11/25 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング