8 key performance indicators
この記事では、Panaya Test Dynamixエンドツーエンドテストソリューションを使用して、品質リリースの8つの主要業績評価指標について説明します。
ソフトウェア品質管理者が、記録的な速度で高品質のソフトウェアを提供するというプレッシャーの高まりに直面していることは周知の事実です。
私たち全員がよく尋ねる質問は、ソフトウェア品質の観点から「成功をどのように測定するか」です。
市場投入までの時間ははるかに簡単な計算ですが、高品質のソフトウェアを提供する際のパフォーマンスの測定は、プロジェクトの方法論（ウォーターフォール、ハイブリッド、アジャイル）、ソフトウェアの複雑さ、技術レベルなど、さまざまな要因によって異なります。関係する負債、インターフェースの数、その他多数。
一言で言えば、許容レベルに達する変数の数 重大度の高い欠陥 過小評価してはいけません。したがって、この市場で生き残るためには、私たちの意見と測定棒の両方で継続的に進化する必要があります。
これが、品質スコアカードに追加し、リリースリスクを軽減し、品質を向上させ、成功をすぐに測定するために追跡を開始する必要がある上位8つのKPIのリストを作成した理由です。
学習内容：
品質リリースの主要業績評価指標
＃1）欠陥検出の有効性（DDE、別名欠陥検出率）
これはあなたの尺度です 全体的な回帰テスト 効果。これは、顧客によるリリースの前後に見つかった欠陥の比率として計算されます。
リリース後に見つかった欠陥は、通常、 「インシデント」 テスト段階で欠陥が見つかったのに対し、ヘルプデスクシステムに記録されている（ 例えば。 、ユニット、システム、回帰、またはUAT）は、リリース前に識別され、次のようなツールで文書化されます。 パナヤテストダイナミックス 。
このKPIを適切に計算するには、実稼働環境にリリースする前に、各欠陥が特定されたソフトウェアバージョンを常に分類する必要があります。
DDEによく使用される式：
ソフトウェアバージョンリリースで特定された欠陥の数/
ソフトウェアリリースの欠陥の数+エンドユーザーによって特定されたエスケープされた欠陥（例えば。、インシデント）
簡単な図を次に示します。
先月のSAPService Packの回帰テストサイクル中に95個の欠陥が見つかり、リリース後に25個の欠陥がログに記録されたと想定します。 DDEは、95を（95 + 25）= 79％で割ったものとして計算されます。
ウォークラフトプライベートサーバーバニラの世界
DDEは、本番環境にリリースされた翌日に100％から始まる折れ線グラフで監視する必要があることに注意してください。また、社内のエンドユーザーと顧客が例として最新のSAPサービスパックを使用し始めると、必然的にいくつかのインシデントがログに記録されます。
サービスパックが本番環境に到達してから2日後の最初の1週間以内に、「狂乱索餌」が発生するのは私の経験です。インシデントがログに記録されると、100％から約95％に急速に低下することに気付くでしょう。会社が毎月のサービスパックリリースのリズムに乗っている場合は、各サービスパックで30日間のDDEを測定します。
一方、会社が1年に4つのメジャーリリースサイクルしか実行していない場合は、90日間測定して、その期間にどのように減少するかを確認します。
「優れたDDE」とは何ですか？
これは、すべての組織や人が時間の経過とともに変化する血圧測定値によく似ています。
医学界は「最適な」血圧測定値を120/80と定義していますが、加齢とともに収縮期血圧が上昇するのは自然なことです。 DDEを使用すると、業界の実務家やソートリーダーは、ほとんどの業界で90％が称賛に値すると言うことが知られています。
ただし、次のような変更影響シミュレーションツールを使用して左にシフトすることにより、組織が一貫して95％を超えるDDEを達成するのを見てきました。 パナヤの影響分析 。
＃2）システム全体の欠陥（SWD）
同じオブジェクトに関連付けられている複数の欠陥に遭遇したことがありますか？確かに、あなたは持っているでしょう。これは、多くのテストマネージャーが遭遇する一般的な現象です。
突然、UATサイクルで報告されたバグの数が大幅に増加しました。幸いなことに、あなたは15分ごとに欠陥を監視し、重複を手動で「リンク」するか、すべての説明を読んで根本原因を自分で識別するタイプだと思いますよね？疑わしい。
それで、「欠陥インフレ」の避けられないドラマを管理するためのあなたのオプションは何ですか？
その夜の要約に続くドラマは、「なぜ今日、このような突然の欠陥の増加」について、本社の指導者に呼びかけています。 （一時停止…。応答する前に深呼吸）…「私は機能リードと協力して、手動の根本原因分析を実行しているところです。
しかし、問題の多くは一般的な問題に関連していると思いますが、それはまだ特定されていません」、おなじみのように聞こえますか？
私の提案は、パナヤが呼ぶものを追跡し始めることです 「システム全体の欠陥」 。これを手動で追跡するには、永遠に時間がかかります。信じてください。何度も試しました。また、欠陥を相互にリンクしてコメントを追加する機能だけが残っている従来のALMツールを使用しているときに行うのも面倒です。
うわー、それは本当に役に立ちました！ （皮肉を感じますか？）しかし、現在ツールに選択肢がない場合は、システム全体の欠陥を適切に追跡して明確に「説明」する時間を確保する必要がありますか？バグトレンドラインがテストサイクルの終わりに向かって下向きではなく上向きに移動している理由。
機会があれば、Panaya Test Dynamixをチェックしてください。エンジン自体にSWDが組み込まれており、オンザフライで自動的にSWDを計算します。
蜘蛛の巣– このプラットフォームの「リスクコックピット」内にあるこれは、すべての品質、テスト、およびリリースマネージャーが追跡する必要がある最も重要なKPIをまとめる、6つの追加の主要業績評価指標の強力でシンプルな表現です。
＃3）要件の完了
QAマネージャーは、各要件にロールアップされたコードまたはトランスポートレベルの可視性によってのみ実現できる、より深いレベルでのリスクを理解しています。これには、適切なツールのセットが必要です。
Panayaツールは、単体テストのインテリジェントな提案、および輸送活動に基づくリスク分析を求めるSAPが運営する組織のニーズに応えます。
このレベルの追跡は、 パナヤリリースダイナミックス（RDx） 。
＃4）開発の完了
私たちは、顧客が王様であり、これがすべての組織のデジタル変革戦略を推進する時代に生きています。この時代では、ソフトウェアの品質保証と配信に対する考え方や組織的なアプローチにとらわれることはできません。
過去の従来のALMモデルは、今日の継続的デリバリーモデル用に設計されていませんでした。この古い考え方に対抗するために、QAおよびテストマネージャーは、アプリケーション開発のアクションに自分自身を組み込む必要があります。つまり、ユーザーストーリーの配信にパルスを与える必要があります。
ユーザーストーリーが完了ステータスに達するまで「座って待つ」だけでは不十分です。むしろ、ユーザーストーリーの進化を追跡し、毎日のスクラムミーティングに参加し、テスト対象のアプリケーションに重要な変更が加えられることで発生するリスクについて率直に話し合う必要があります。
＃5）テスト計画の適用範囲
これは、システム、統合、回帰、およびUATカバレッジのみの追跡に追いやられていないため、追跡するのに私のお気に入りのKPIの1つです。
左シフトの真の精神で、私はユニットテストカバレッジを追跡することの重要性についてアドバイスし始めました。クレイジーに聞こえますよね？特に、単体テストの実行だけを簡単にする適切なツールがある場合はそうではありませんが、実際の結果（証拠）の取得も簡単になります。
Panaya Test Dynamixの組み込みのテスト記録および再生機能をオンにすると、単体テストへの参加が急増します。エンドツーエンドのカバレッジを示す要件トレーサビリティマトリックスを誇らしげに表示できるだけでなく、ユニットから回帰テストまで、監査部門に実際の結果を簡単に示すことができます。
＃6）変更リスク分析
テスト対象のアプリケーションに加える変更にはリスクが内在しますが、正しいことをテストしているかどうかは常にわかりません。
多くの組織には、「変更リスク」が組織にとって何を意味するかについて独自の定義があります。 Panayaのリリースダイナミックス（RDx）の「リスクコックピット」内で、プロジェクトまたは次のリリースの影響分析を使用して、変更の追跡から当て推量を取り除くことができます。
RDxは、各要件のリスクを体系的に計算し、配信ライフサイクルに進むにつれてリスクがどのように変化するかを常に把握します。
＃7）テスト実行リスク
すべての組織が、作成されたテスト、合格したテスト、自動化されたテスト、実行されたテストなどのKPIを追跡することはあまりにも一般的ですが、各テスト内で実行された実際のステップを追跡するのはどうでしょうか。
あなたは今までに多くの 人気のALMプラットフォーム テストの「ステップ」実行の進行状況を追跡するための、すぐに使用できるレポート機能を提供していませんか？全体でさまざまな「ハンドオフ」が発生している場合 UATサイクル 、テストレベルだけでなく、ビジネスプロセスレベルでも、テスト実行のリスクとステータスを追跡することは理にかなっています。
Panaya Test Dynamixは、すぐにそれを実行します。
＃8）欠陥の実行
トラッキングの欠陥には、本質的に否定的な意味合いもあります。
アクティブな欠陥、1日あたりに修正された欠陥、拒否された欠陥、および重大な欠陥を追跡することに加えて、スコープイン要件に関連する欠陥の解決を監視することもお勧めします。
多くの組織は、欠陥解決について要件主導の見方をしていません。
なぜこのテストソリューションなのか？
リリースダイナミックスとパナヤテストダイナミックスの両方に組み込まれたエンドツーエンドのトレーサビリティにより、組織は要件レベルで最初から最後まで欠陥解決のワークフローを追跡できます。
これは、プロジェクトまたはリリースサイクルの鳥瞰図を求めるリリース、品質、およびテストマネージャーにとって特に役立ちます。
Panayaは、技術ITおよびビジネスユーザーのテストプロセスを加速し、それによって全体的なテスト作業を30〜50％削減します。
- マネージャー： テストと欠陥、およびボトルネックの防止に関するリアルタイムのアラート。
- ビジネスユーザー： テストの証拠と欠陥の自動文書化。
- 機能アナリスト： 反復テスト活動の自動化。
- プロのテスター： ビジネス知識の獲得をシームレスに改善します。
- 欠陥ソルバー： テスターとのやりとりを減らします。
このソリューションについて他に知っておくべきこと
＃1）Panaya TestDynamixはSaaSソリューションです つまり、シームレスな統合、頻繁で痛みのないアップグレード、およびオンプレミスの自動化ツールの監視が可能になります。
＃2）組み込みのコラボレーションツール 組み込みの通知とコミュニケーションツールを使用して、テストサイクルを合理化します。
次のユーザーへのテストステップの自動ハンドオーバーにより、アイドル時間がなくなり、ワークロードのボトルネックが解消され、最適なワークフローが保証されます。
＃3）スマートな欠陥管理 ユーザーは、欠陥、その解決策、およびそれらによって影響を受けるビジネスプロセスを一元的に監視できます。
欠陥が見つかると、影響を受ける他のすべてのテストを自動的に識別し、主な欠陥が解決されるまでテスターに通知をブロックまたは送信します。解決された欠陥は、欠陥のバックログを排除することにより、自動的に閉じられます。
＃4）UATとSITへのビジネスプロセス中心のアプローチで、 部門の枠を超えて地理的に分散した対象分野の専門家は、実際のビジネスプロセス（パッケージ化されたアプリケーション）に基づいてUATサイクルを検証します。
＃5）テスト自動化コネクタ Panaya Test Dynamixと既存の自動化ツールの完全な統合を提供し、全体的な追跡および監視機能により、最小限の時間と労力で効果的な回帰サイクルを実現します。
＃6）テストエビデンスの自動化 従来ExcelとWordで管理されていた手動テストを自動化します。
開発者とテスターの間のやり取りを減らしながら、テストの証拠やテストの再現手順の記録など、すべてのテストの実行を簡単に文書化することで時間を節約します。ドキュメントは 監査対応 、すべての内部および外部の品質基準への準拠を保証します。
＃7）自律テストSM SAP向け ゼロタッチのテストケースの作成と保守が可能になるため、ビジネス知識の取得や手動で設計されたスクリプトの作成と保守のプロセスに関連する問題に対処する必要がなくなります。
スクリプトはカスタマイズ可能ですが、機械学習は群集分析に基づいて検証と提案を提供します。
＃8）自動化されたビジネス知識の取得–オメガ 機械学習アルゴリズム（SAP）を使用して、本番環境でシームレスにキャプチャされたビジネスユーザーアクティビティに基づいて、実際のテストケースを自動的に作成します。
結論
ソフトウェア品質マネージャーとすべての関連する利害関係者は、テストKPIを満たし、Panayaを使用して範囲や品質を犠牲にすることなく、労力を30〜50％削減しながら、より多くのイノベーションを推進できます。
すべての利害関係者が同じテスト方法を採用して、大規模なUATを含むすべてのテストサイクルにわたってリアルタイムの可視性を獲得するため、テストプロセスを標準化し、成功を測定します。
詳細については、探索することができます パナヤテストダイナミックス 。
以下のコメントであなたの考え/質問を教えてください。
推奨読書
- 品質属性とは何ですか？
- MongoDBパフォーマンス：ロックパフォーマンス、ページフォールト、データベースプロファイリング
- 品質保証と品質管理の違い（QAとQC）
- 偽の品質の神と真の人間-ソフトウェアの品質の責任者は誰ですか？
- ジョージア工科大学がRadViewWebLOADでのパフォーマンステストを標準化
- HTTPとHTTPS：機能とパフォーマンスの詳細な比較
- パフォーマンステスト計画とパフォーマンステスト戦略の違い
- 手動パフォーマンステストを実行する方法は？