この記事では、QAプロセスの基準とメーターのグループをまとめて検討することにしました。 そして、各グループでは、最も重要で示唆的な指標のみをリストしますが、再び私の意見では、メトリックが必要な理由、どの状況で役立つか、そしてそれらを使用する方法を理解します。
メトリックスはどうあるべきですか？
ソフトウェアのコンテキストにおけるメトリック自体は、任意の特性、製品自体の品質、またはその開発プロセスの数値表現です。 言い換えれば、これはソフトウェアを測定、比較、評価できるものです。
ここで、メトリックの値とプロパティに関するコメントをいくつか紹介します。
- メトリックの主な目標は、開発プロセスとソフトウェア製品自体を改善することです。 メトリックを使用すると、成功基準が達成されているかどうか、現在の目標への道のどの時点で、目標に近づいているのか、離れているのかを確認できます。
- 測定プロセス自体のために、メトリックは存在すべきではありません。 本当に実用的な価値があり、製品のさらなる開発またはプロセスの最適化に影響を与えるメトリックのみを使用する必要があります。 ここから簡単なルールに従います-最初に変更/改善の領域を特定し、次にそれらを評価する方法を決定する必要があります。
QAの主要な指標グループ
理論的には、QAプロセスのほとんどすべての、重要でないアクション、ステージ、またはステータスでさえ、独自の特性、式、またはインジケーターを作成することができます。 各アーティファクト、ステータスごとの欠陥のすべての遷移を考慮し、セット内のテストの数を計算できます。 ただし、何かを測定したいときにすぐに自問すべき最も重要な質問は、「なぜこの情報が必要なのか、どのように使用できるのか」です。 一連のメトリックを作成する場合、目標、プロセスの改善計画、および製品から進む必要があります。
そのため、この記事では、ほとんどのレポートやステータスで使用されているテストの進捗状況の通常の定量的な指標については考慮しません。 代わりに、作業の品質を評価するために測定および制御する必要がある品質保証の観点から、どの領域、成果物、および開発領域を分析します。 これらのポイントの分析と最適化は、利害関係者との効果的な対話（ https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html ）およびソフトウェア開発全般にとって非常に重要です。
1.開発したソフトウェアの要件。
私たちは開発とテストを行っていることを正確に理解する必要があり、この理解度が評価できる必要があります。 仕様レベルでの潜在的なリスクまたは見逃された問題は、最も深刻で費用のかかるエラーにつながる可能性があります。
2.開発された製品の品質。
ここではすべてが明らかです。予測とリスクの評価を行うには、開発とソフトウェアの品質を評価できる必要があります。 検出されたエラーの有無だけでなく、多くの潜在的な問題があるかどうかを予測するだけで、製品の品質と信頼性を理解することが重要です。
3. QAチームの機能。
ここでも簡単です。テストプロセスを管理し、作業を計画し、タイミングを予測するには、タスクの現在のステータスだけでなく、QAチームの能力も常に把握している必要があります。
4.テストチームの品質。
製品自体の品質に加えて、QAプロセス自体とテストチームの有効性を測定する必要があります。 仕事の質を絶えず最適化し、改善するためには、私たちが今どこにいるのかを知る必要があります。
5.フィードバックと製品の満足度。
後者の領域ですが、もちろん重要ではありませんが、プロセスの利害関係者、サービスの消費者、製品のユーザーの意見です。 製品に対する全体的な満足度を測定し、傾向を強調し、適切な結論を導き出すことができることが非常に重要です。 このグループの適切に選択されたメトリックにより、時間内に発生する可能性のある問題を特定し、フィードバックを迅速に適用してプロセスを改善できます。
次に、各グループに含まれるメトリックを正確に検討し、それらの推定方法を分析します。 各グループについて、可能なメトリックの例をいくつか示し、その意味を説明します。 QAプロセスのこれらの指標および他のいくつかの指標については、私の記事「最も重要なQAメトリック」（ https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qaで詳しく説明しています。 html ）。
グループ1-開発したソフトウェアの要件
この一連のメトリックにより、ソフトウェアの要件（ユーザーストーリー）をどのように解決したかを評価し、脆弱性とソフトウェアの最も複雑で潜在的に問題のある機能を特定し、特別な制御が必要な場所を理解できます。
1.テストカバレッジの要件
「テストの合計数」/「要件の合計数」
メトリックの目的：テストカバレッジの弱点を特定し、リスクを強調します。
- このメトリックは、要件が同等のものにうまく分解されている場合にのみ機能します。 それ以外の場合は、各要件のテストの有無のインジケータに変わります。
- 係数が0に等しい、または0に近い要件の場合、テストの追加を検討する必要があります。
2.要件の相互接続の程度
AVERAGE（「要件No.1に関連する要件の数」/「要件の総数-1」、...、「要件No. nに関連する要件の数」/「要件の総数-1」）
メトリックは、各要件と残りの要件とのリンクの数として計算されます。 この場合、すべての要件の平均値が使用されます。
メトリックの目的：テストのタイミングを評価し、考えられるリスクを考慮に入れるための基礎を提供します。 相互の要件の相互影響の程度を知ることで、たとえば、エンドツーエンドのテストのための追加の時間とケースを計画したり、回帰チェックを実行したり、統合を検討したりできます。
- 私自身の経験から、許容できる接続の程度は0.2〜0.3を超えないことに注意できます。 そうしないと、要件の1つを改良すると処理チェーンが発生し、製品の重要な部分でエラーが発生する可能性があります。
3.安定係数の要件
「既存の要件の変更数」/「新しい要件を含む、反復のために実装された要件の総数」
メトリックの目的：新しい機能を開発するときに、リリースごとにやり直さなければならない実装済み要件の数を示します。 また、このメトリックは、システムの機能がどれだけ簡単にスケーリングされ、新しい機能が追加されるかを示します。
- このメトリックの場合、係数は少なくとも0.5未満でなければなりません。 この場合、既存の機能をやり直すよりも2倍の新しい機能を導入します。 それ以外の場合、チームは、ビジネスに新しい価値を生み出すのではなく、以前にリリースされた機能を作り直すことに重点を置いています。
グループ2-開発製品の品質
このメトリクスのグループにより、リリースごとにソフトウェアの品質と開発自体の品質の両方を評価および比較できます。
1.欠陥の密度
「個別のモジュールの欠陥の数」/「ソフトウェアの欠陥の総数」
これは、反復またはリリースの一部として別のモジュールに分類される総数の欠陥の割合として計算されます。
メトリックの目的：ソフトウェアのどの部分が最も問題があるかを強調します。 この情報は、このモジュールでの作業の評価と計画、およびリスク分析に役立ちます。
- このメトリックは、障害の割合が平均を超えている問題モジュール\システム\機能に注意を引くのに役立ちます。
2.回帰係数
「古い機能の欠陥の数」/「新しい機能を含む欠陥の総数」
このメトリックの目的は、チームの努力が何に費やされているかを示すことです。新機能の開発とデバッグにもっと従事するか、ソフトウェアの既存の部分の修正にほとんどの時間を費やすかです。
- たとえば、回帰係数が0.5を超える場合、これは以前に機能していたソフトウェア関数の復元に半分以上の時間を費やすことを意味します。 この状況を修正する必要があります。
3.再発見された欠陥の係数
「再発見された欠陥の数」/「以前に修正されたものと新しいものを含むエラーの総数」
メトリックの目的：開発または欠陥の修正の品質、ならびに製品または個別のモジュールの複雑さを評価すること。
- 係数が0に近づくほど、古いエラーが繰り返されなくなります。
- さらに、値が0.2〜0.3を超える場合、これはモジュールの技術的な複雑さ、アーキテクチャの問題、または低品質のエラー修正のいずれかを示している可能性があります。
グループ3-QAチームの機会と有効性
このグループのメトリクスの主なタスクは、テストチームができることを数値で表現することです。 これらの指標は定期的に計算および比較でき、傾向を分析し、特定の変更がチームの作業にどのように影響するかを観察できます。
1. QAチームの速度
「N回の反復のストーリーポイントの数）」/「N」
これは、選択された反復の数に対する、実現されたストーリーポイント\要件\複数の反復\スプリントのユーザーストーリーの比率として計算されます。
メトリックの目的：作業の範囲をさらに計画するための能力、チームの速度、および開発トレンドの分析を定量化します。 このメトリックを使用すると、QAの速度を監視し、チームに対する内部または外部の影響がこの速度にどのような影響を与えるかを観察できます。
2.欠陥の平均寿命
「発見された欠陥を修正するための合計時間」/「欠陥の数」
反復またはリリース中に検出された欠陥が検出された合計時間に対する合計時間。
メトリックの目的：1つの欠陥（登録、修正、再現）を処理するのに平均してどれくらいかかるかを示すため。 このインジケータにより、テストに必要な時間を評価し、最も困難なソフトウェアの領域を特定できます。
- 欠陥の存続期間とは、登録から終了までのすべての時間から、考えられるすべての中断を差し引いたものです。 最も長い修正時間で欠陥を表示することにより、このメトリックは、特に複雑で問題のあるモジュールまたは開発チームの「弱いリンク」を識別するのに役立ちます。
グループ4-テストチームの作業の質
この一連のメトリクスの目標は、テスターがタスクをどの程度達成しているかを評価し、QAチームの能力と成熟度を判断することです。 この一連の指標を使用すると、さまざまな期間のチームまたは他の外部テストグループとチームを比較できます。
1.テストとテストスイートの有効性
「検出されたエラーの数」/「テストケースのケースの数」
メトリックの目的：ケースを検出できる平均エラー数を示します。 このメトリックは、テスト設計の品質を反映し、その変化の傾向を監視するのに役立ちます。
- テストの「屠殺」の指標により、各テストセットの有効性、時間の経過に伴う変化を監視できます。 これにより、時間通りに「新鮮な」テストでそれらを補完することが可能になります。
2.本稼働でスキップされるエラー係数
「リリースのリリース後に検出されたエラーの数」/「リリースの前後に検出されたエラーの総数」
メトリックの目的：テストの品質とエラー検出の有効性を実証するために-除外された欠陥の割合と生産性に渡された欠陥の割合。
- もちろん、ミスの許容される割合は多くの要因に依存しますが、> 0.1の場合、明らかに問題があります。この場合、10個の欠陥ごとに生産性が低下し、ユーザー間でソフトウェアがクラッシュするためです。
3. QAチームのリアルタイム
「ターゲットQAアクティビティに費やした時間」/「チームの総労働時間」
チームが目標QAアクティビティに直接費やした時間の、総時間数に対する比率。
メトリックの目的：第1に、計画の精度を高め、第2に、チームの効果を監視および管理します。
- 対象となるアクティビティには、分析、設計、評価、テスト、作業会議などが含まれます。ブロッカー、コミュニケーションの問題、リソースへのアクセス不能などが原因で、対象外のアクティビティが多くなります。
- もちろん、このメトリックは1に等しくなることはありません。実践では、効果的なチームの場合、その値は0.5〜0.6になることが示されています。
4.地域/タイプ/仕事のタイプによる時間推定の精度
推定ランタイム/実際のランタイム
メトリックの目的：後続の推定に補正係数を使用できます。
- 評価の精度は、チーム全体または個々のテスター、システム全体または個々のソフトウェアモジュールに対して決定できます。
グループ5-フィードバックとユーザー満足度
そして最後に、製品がエンドユーザーにどのように受け入れられたか、どのように期待に応えたかを示す一連の指標。 同時に、ユーザーインタラクションの評価の一環として、ソフトウェア自体に関するフィードバックだけでなく重要です。 このグループのメトリックのもう1つの重要なタスクは、ユーザーがITチーム全般、特にQAとのやり取りのプロセスに満足しているかどうかを示すことです。
1. ITサービスに対する顧客満足度
スコアリングによるITサービスに対するユーザー満足度の定期的な調査が実施されます。
メトリックの目的：ユーザーがITチームを信頼しているかどうか、その作業がどのように、なぜ組織されているか、この作業がどの程度期待どおりに機能するかを理解します。
- メトリックは、プロセスの最適化に焦点を当てる必要があること、またはユーザーにとってプロセスをより明確かつ透明にする必要があることを示す指標として役立ちます。
- 満足度指標は、ソフトウェア配信の結果に基づく調査の結果に基づいて計算できます。 これを行うには、すべての成績を収集し、平均スコアを計算する必要があります。
2.製品ユーザーの満足度
製品の品質に対するユーザーの満足度に関する定期的な調査。
メトリックの目的：開発中の製品がユーザーの期待をどの程度満たしているか、正しい方向に進んでいるか、機能の重要性を正しく判断しているか、ソリューションを選択しているかを判断します。
- このメトリックを計算するために、ユーザーの調査も行い、平均スコアを計算します。 この指標を定期的に計算することにより、ユーザー満足度の傾向を監視できます。
3.利害関係者の関与
関係者がイテレーション（リリース）で受け取ったプロセスと製品を改善するためのイニシアチブと提案の数。
メトリックの目的：製品の作業における外部の利害関係者（ビジネス、インフラストラクチャ、ユーザー、サポートなど）の参加の度合いを決定する。 そのようなメトリックを手元に用意しておくと、いつか問題や誤解に遭遇しないように、フィードバックを取得したい場所に移動できます。
パベル・ノヴィコフ、
プログラムマネージャー
https://doitsmartly.ru/