PDCAモデルを活用したテストプロセス改善（TPI）

テストプロセス改善とは何ですか？

テストプロセスの改善 これは、テストプロセスのパフォーマンスを測定し、その弱点を特定し、管理された変更を適用することで、次のプロジェクトでより高い品質をより低いコストとより短い時間で実現するための実践です。テストを、リリースごとに同じように繰り返される活動ではなく、測定および調整可能なプロセスとして捉えます。

想像してみてください Guru99銀行プロジェクトが完了しました。経営陣はあなたの仕事ぶりを高く評価しており、顧客も​​満足しています。それでも、あなたの上司はまだあなたにいくつか質問があるようです。

マネージャーはよくこう説明する ソフトウェアテスト 厄介で制御不能なプロセスとして。 Guru99 Bankプロジェクトにおいて、以下の問題に直面しましたか？

これらは、ほぼすべてのテストプロジェクトで共通して見られる問題です。多くの組織は、テストプロセスを改善することがこれらの問題を解決する唯一の永続的な方法であると認識しています。なぜなら、過去の失敗から学ぶことが、次のリリースサイクルで同じ失敗を繰り返すことを防ぐ唯一の方法だからです。

なぜテストプロセスの改善を行うのか?

以下のシナリオは、テストプロセスの改善がなぜ重要なのかを示しています。 Guru99 Bankプロジェクトは完了しました。テストの質は素晴らしく、お客様からも良いフィードバックをいただきました。

このシナリオから得られる教訓は何でしょうか？それは単純に 「常に向上を目指す」たとえ自分が良い仕事をしたと思っていても、必ず自分よりも優れたアイデアや解決策を見つけた人がいて、より良い仕事をしているものだ。

どの企業もプロジェクトを完了させたいと考えています。 最高 品質、 最低 コスト、そして 最短 納期。テストプロセスの改善は、テストチームがこれら3つの目標すべてに同時に取り組むのに役立ちます。

テストプロセス改善をどのように実施するか？

テストプロセス改善を実施するため Guru99 Bank プロジェクトでは、テスト マネージャーは以下に従うことができます。 PDCA モデル。PDCA（計画-実行-評価-改善）は、ビジネスにおいてプロセスの管理と継続的な改善に使用される4段階の管理手法です。ループを一周するごとに1回の改善サイクルとなり、改善（Act）の出力が次の計画（Plan）の入力となります。

ステップ 1) 計画を立てる

計画段階では、改善策が設計されます。これはさらに3つの小さなステップに分かれています。

ステップ 1.1) 問題を特定する

テスト改善プロセスの最初のアクティビティは、 識別 現在のプロジェクトで発生した問題。 このプロジェクトの問題が他のプロジェクトでも再発する可能性があります。 問題を解決し、将来的に問題を回避するための解決策を見つけることが、テスト改善の主な目標です。

さて、プロジェクトに戻りましょう。 Guru99 Bankのウェブサイトについて、何か問題点や改善点があれば教えてください。以下から選択してください。

ステップ 1.2) ターゲットを決定する

プロジェクトで発生した問題点と課題を理解することが重要です。そうすることで、改善すべき点や、優先的に取り組むべきテスト段階を特定できます。

テスト実行フェーズに時間がかかりすぎることがわかったとします。 ずっと 完了までの時間とコスト。テストをより迅速かつ安価に実施できるだろうか？この問いが、サイクルの目標となる。有用な目標は、数値と期限として示される。例えば、「次回のリリースまでに回帰テストの実行時間を30%削減する」といった具合だ。

ステップ 1.3) 改善アクションを定義する

合意された目標に基づき、改善策が決定される。これらの対策は、すべてを一度に変えることは現実的ではないため、段階的に少しずつ導入していくべきである。

例えば、検査をより迅速かつ安価に行うために、以下の対策が候補となる。

上記の例では、オプションAとBはどちらもテストをより迅速かつ安価に進める方向へ導きます。オプションCはテストをより迅速に行えるようにしますが、経験豊富なテスターはより高い給与を要求するため、コストが高くなります。このトレードオフこそ、あらゆる候補者の行動を直感ではなく目標に照らし合わせて判断しなければならない理由です。

ステップ 2) 実行する

改善点はすでに特定済みです。次は、それらを実行に移すための計画を策定する段階です。この計画は、以下の質問に答えるものでなければなりません。

• どの改善点を、どのような順序で実施する必要があるのか​​？
• 計画はいつまでに完了しなければならないか？
• 計画を達成するためには、どのような手順を踏む必要がありますか？
• 各工程の責任者は誰で、完了はどのように確認されるのか？

改善アクションを実行する

計画が策定されたら、それを実行に移さなければなりません。改善活動は既に進行中のテスト作業を妨げる可能性があるため、テストマネージャーは 注意 彼らに 不要なものを避ける 結果。

次のシナリオを考えてみましょう。 Guru99 Bankプロジェクトでは、テストをより速く、より安価にするために、 自動化テスト 大量の手動回帰テストに代わるものとして導入された。この対策を実施後、生産性は大幅に向上した。

ステップ3) 確認

チェック手順では、次の3つのことを行います。

• 評価する 効率 テスト改善アクションの
• 測定方法 効果的な 解決策は
• それが可能かどうかを分析する 改善されました さらに

この段階の目的は、改善策が成功裏に実施されたことを確認し、計画で設定された目標が実際に達成されたかどうかを評価することです。

その評価を実行する最良の方法は、 メトリクス指標は、組織運営を成功させる上で不可欠です。テストマネージャーはデータを収集し、生産性、品質、コストなどのパラメータを測定するために使用します。

例えば、プロジェクトに自動化を適用する前は、テストの生産性は 1人時あたり10件のテストケース自動化導入後、生産性は測定され、 1人時あたり20件のテストケース.

しかし、その利益と同時に、望ましくない問題も発生した。

この場合、自動化を適用する 増加した テストの生産性、しかしテストの質 減少した改善策は深刻な結果を招く可能性がある。 結果 他の場所では、テストツールの選択ははるかに慎重に行う必要があり、自動化されたスイートは本番コードと同じ厳密さでレビューする必要があります。候補ツールの構造化された評価は、 Selenium チュートリアル人気があるという理由だけでツールが採用されることを防ぐ。

同じシナリオをもう一度考えてみましょう。 Guru99のプロジェクト費用は オーバーラン チームメンバーがあまりにも多くの時間を費やしたため たくさんの時間 テストケースを実行します。 自動テスト ツールを使用することで、 30パーセント プロジェクト費用の削減です。これは良い改善ですが、上司はもっと高い成果を期待しています。

したがって、テストプロセスをさらに改善する新しいソリューションを常に模索する必要があります。このような状況では、他の選択肢によってプロジェクトコストをさらに削減できる可能性があります。

• 人材を効果的に管理し、熟練したテスターが最も価値を発揮できる場所に配置しましょう。
• ツールや人材派遣業者との取引条件をより有利なものに交渉しましょう。
• 重複しているテストケースや価値の低いテストケースは自動化するのではなく、廃止する。

ステップ4) 行動する

改善策が成功裏に実施され、目標が達成されたら、テストマネージャーは以下の活動でサイクルを完了させる必要があります。

• レビュー 改善活動を行い、得られた教訓に基づいて行動する
• 標準化 テスト管理プロセスにおける改善点
• 更新 ポリシー文書、テスト計画テンプレート、および標準プロセス文書
• 決定する これらの変更が次のプロジェクトでいつ、どこに適用されるか

目標が達成されなかった場合でも、サイクルは停止しません。達成されなかった目標は、チェックフェーズで明らかになった、なぜその行動が期待を下回ったのかに関するすべての情報とともに、新たな計画フェーズに引き継がれます。

TPI NEXT、TMMi、CMMIの比較

PDCAサイクルは改善の原動力ですが、参照モデルは「より良い状態」がどのようなものかを示してくれます。一般的に使用されるモデルは3種類あり、これらはしばしば混同されます。

TPIネクスト これは、Sogeti社が公開しているテスト専用の参照モデルです。16の主要領域を3つのグループに分類し、それぞれを「初期」「管理済み」「効率的」「最適化」の4つの成熟度レベルに基づいて評価します。評価は主要領域ごとに行われるため、ある領域では効率的であっても、別の領域では管理済みという状況もあり得ます。

TMMiTMMiによって維持管理されています Foundationは、初期、管理、定義済み、測定済み、最適化の5つのレベルからなる段階的なテスト成熟度モデルです。組織は、そのレベルのプロセス領域を満たして初めて、そのレベルに到達します。

CMMI TMMiはテストモデルではありません。開発組織全体を対象とし、段階的な表現には、初期、管理済み、定義済み、定量的に管理済み、最適化の5つの成熟度レベルがあります。TMMiはCMMIを置き換えるのではなく、補完するために設計されました。

テストプロセスの改善を証明する指標

数値データがない場合、チェックフェーズは成り立ちません。各サイクル前後で収集される、小規模で安定したメトリックセットで十分であり、比較の両側で同じ定義を使用する必要があります。

• テスト実行の生産性 — 1人時あたりに実行されたテストケース数
• 欠陥検出率（DDP） ―テストで発見された欠陥が、リリース後に報告されたものも含めた全欠陥に占める割合
• 実行されたテストケースあたりのコスト — 総テスト費用を、実行されたテストケース数で割った値
• 要件カバレッジ — 少なくとも1つのリンクされた要件 テストケース
• 不具合修正の所要時間 — 欠陥の平均年齢 欠陥ライフサイクル

使い方 Guru99 Bank のデータでは、テストで 180 の欠陥が見つかり、リリース後に顧客から 20 の欠陥が報告されたため、計算は簡単です。

# Defect Detection Percentage and improvement deltas
def ddp(found_in_test, found_after_release):
    return found_in_test / (found_in_test + found_after_release) * 100

def delta(before, after):
    return (after - before) / before * 100

print("Defect Detection Percentage: %.1f%%" % ddp(180, 20))
print("Productivity gain: %.1f%%" % delta(10, 20))
print("Test cost change: %.1f%%" % delta(50000, 35000))

出力：

Defect Detection Percentage: 90.0%
Productivity gain: 100.0%
Test cost change: -30.0%

DDPが90%ということは、10個に1個の欠陥品が顧客に届いてしまったということであり、生産性が2倍になりコストが30%削減されたとしても、品質目標は完全には達成されていない。このような客観的な視点こそが、チームが早々に勝利宣言をするのを防ぐのだ。

テストプロセス改善におけるよくある間違い

改善プログラムの多くは、技術的な問題ではなく組織的な問題によって失敗に終わる。以下に挙げるミスが、頓挫する取り組みの大部分を占めている。

• 基準値なしで改善する。 変更前に誰もプロセスを測定していなければ、変更が効果的だったことを証明することはできません。ベースラインは計画段階で把握し、後から把握するのは避けましょう。
• ビジネスの推進力ではなく、成熟度レベルを追い求めている。 コスト、欠陥、またはリードタイムを削減しない証明書は、改善ではなく、費用である。
• 一度に多くのことを変えすぎている。 5 つのアクションが同じリリースに含まれる場合、回帰は発生しません。 tracそれらのいずれかに。
• 機能不全に陥っているプロセスを自動化する。 自動化は、それが適用されるあらゆるプロセス、例えば不十分なテスト設計や不明確な参加基準なども含めて、その問題を増幅させる。
• スキップping 実行段階。 テストポリシーには決して記載されない改善点と、 ソフトウェアテストのライフサイクル 文書は、それを発明したプロジェクトチームと共に消滅する。
• テスターを除く。 変更について相談を受けなかった人々は、必ずと言っていいほど、その変更を回避する方法を見つけるものだ。

これらのアイデアをさらに発展させるには、 ソフトウェアテストのライフサイクル、締めます テストケース デザインし、形式化する 欠陥管理プロセスどこで評価するか 自動化テスト 真のリターンをもたらし、次のようなツールがどのように役立つかを見てください。 HP ALM チェックフェーズが依存するメトリクスを保持できます。

よくあるご質問