メニュー

ソフトウェアを稼働させるために許容できる欠陥をどのように決定しますか？

how do you decide which defects are acceptable

問題を排除するために楽器を試してください

Software Go-Liveは、どのソフトウェア製品にとっても常に大きなイベントです。すべてが機能し、私たちがそうであることを絶対に確認することが重要です 高品質のソフトウェアをユーザーにリリース 。

不良または時期尚早または不安定または使いにくい製品は、経済的に多くの損失を引き起こす可能性があり、ユーザーがブランド自体への信頼を失う可能性もあります。

多くの場合、終了基準を満たすまでテストを実行する必要があると聞いています。また、欠陥を許容可能なレベルに修正する必要があると聞いています。

これらは優れたガイドラインですが、あいまいです。

software-go-live-criteria

もう少し詳しく言うと：

  • ソフトウェアが稼働するのに許容できる欠陥の割合は何パーセントですか？
  • ソフトウェアが稼働できる未解決の欠陥をどのように決定しますか？
  • 何 欠陥の種類 他の人よりも深刻ですか？

推奨読書=> テストをいつ停止するか？

これらの質問はありますか？次に、この記事はあなたがそれらに答えるのを助けるつもりです。読む…

複雑なソフトウェアには欠陥がないわけではなく、動作中のソフトウェアと比較して欠陥を閉じることについての鶏が先か卵が先かという話です。

欠陥を修正すればするほど、欠陥を閉じるときに新しい欠陥が注入される可能性が高くなります。そう、

  • 欠陥の範囲と、稼働できる欠陥の種類をどのように決定しますか？
  • 導入するソフトウェアをどのようにベースライン化して稼働させますか？
  • UATコーディネーターはどのようにして本番稼働を呼びかけるのですか？
  • ソフトウェアはどのパラメータに対して判断されるべきですか？
  • どのように答えますか–ソフトウェアは使用に適していますか？それは利害関係者に価値をもたらしますか？

通常、支払いのマイルストーンにリンクされているため、本番環境に移行することは、顧客とベンダーにとって主要なマイルストーンです。どちらも、大規模な変革プロジェクトを成功させる上で同等の責任を負っています。

私の経験では、顧客はお金に見合う価値を求めており、 終了基準 UATが稼働するために。

上記の終了基準は、アプリケーションのすべての領域で許容できる問題の範囲を多かれ少なかれ定義します。

  1. 機能的
  2. パフォーマンスと負荷
  3. 使いやすさ
  4. セキュリティ
  5. 外部システムとの統合
  6. レポート
  7. データ移行

これらのタイプの欠陥のすべてをさらに説明する必要があると思います。そして、それはまさに私たちが今やろうとしていることです：

World ofWarcraftのプライベートサーバーリスト

＃1。機能上の欠陥：

ソフトウェアがお客様の仕様に従って作成されている場合は、要件を満たしている必要があります。逸脱は機能上の欠陥として記録されます。

機能上の欠陥 次に、に従って分類されます 重大度と優先度 。

重要な考慮事項は次のとおりです。

  • 重大度が高く優先度の高い欠陥は、通常、ソフトウェアの日常的な使用に影響を与えるものです。これらのタイプの欠陥は、稼働する前に修正する必要があるものです。例外なし。
  • 機能上の欠陥は、最初に指定された要件の一部ではなかったため、変更要求として分類される場合があります。このようなCRは、運用開始後にビジネスが機能するために必須であり、実装する必要もあります。
  • 欠陥の分類と機能上の欠陥の優先順位付けは、ビジネスユーザーおよびビジネスアナリストと協力してUATコーディネーターによって行われます。通常、顧客は、欠陥の何％を稼働させることができるかという終了基準を持っています。

＃2。パフォーマンスと負荷の欠陥：

パフォーマンスの欠陥 ソフトウェアを外部ユーザーが使用する場合は、運用開始などを検討することが重要です。

ソフトウェアが特定の数のユーザーに対して遅い場合、ユーザーはロードに時間がかかるため、ソフトウェアの使用を避けます。ソフトウェアが非常に遅い場合、ユーザーは競合他社のサイトに移動する傾向があり、それによってビジネスが失われます。

場合によっては、クライアントに面していないアプリケーションの部分もパフォーマンスに影響を与える可能性があります。

例えば：毎日の終わりに実行されるバッチプロセスがあり、これが続く間にアプリケーションの応答時間が低下する場合は、バッチのパフォーマンスも考慮すべき要素です。

  • パフォーマンスは通常、システム上に一定数の同時ユーザーがいるときに、レンダリングしてユーザーが利用できるようになる画面の応答時間の観点から測定されます。
  • パフォーマンステストは、次のようなツールを使用して行われます。 LoadRunner 、 WebLoad 、Neoloadなど。
  • 特定の負荷および将来の予測負荷でのソフトウェアのパフォーマンスは、通常、契約に文書化されており、運用開始前に実証する必要があります。
  • ユーザーがあまり使用しない画面またはアプリケーションの一部は、稼働後の評価に延期されます。
  • パフォーマンスは、ハードウェアの種類とソフトウェアが展開されているネットワークの状態にも依存します。
  • パフォーマンステストは、パフォーマンスツールを使用して、指定されたハードウェアでUAT中に実行され、それらの欠陥は、機能上の欠陥と同様の方法で追跡されます。それらも優先され、稼働開始の終了基準を満たすことでコンセンサスが得られます。
  • 通常、UATのパフォーマンスと負荷のテストは、ビジネスユーザーによる機能的なUATが完了し、機能的な欠陥の許容可能な終了基準に達した後に実行されます。

＃3。使いやすさの欠陥：

作成されたソフトウェア エンドユーザーが簡単に使用できる必要があります さまざまなホットキー、ショートカット、最小数の画面ナビゲーション、ページ付けなどを使用します。ソフトウェアはスマートで直感的である必要があります。

適切な画面に移動する前にページの移動が多すぎる場合、ユーザーは通常、ソフトウェアの使用にあまり関心を示しません。

  • 使いやすさのガイドラインは、ソフトウェアを構築する前に作成されます。ソフトウェアはこれらのガイドラインに準拠する必要があります。
  • また、ソフトウェアを作成する際にツールの制限があり、エンドユーザーがソフトウェアを使用する前に賢く克服する必要があります。
  • 使い勝手の良いソフトウェアで、エンドユーザーは通常のソフトウェアの5倍ものデータを入力できます。
  • ソフトウェアのルックアンドフィールは鮮明である必要があり、また、運用開始前に法的な問題を整理する必要があります。
  • 多くの場合、ユーザビリティコンサルタントは、ユーザーにスムーズなユーザビリティ体験を保証するために任命されます。
  • ソフトウェアアプリケーションに付属しているドキュメントも、合法的に使用できるため、厳格なユーザビリティガイドラインに準拠している必要があります。
  • UATテスター/外部テスターに​​よってログに記録されたユーザビリティの欠陥も、機能およびパフォーマンスの欠陥として優先され、稼働開始の終了基準を満たす必要があります。

＃4。セキュリティ上の欠陥：

セキュリティ ソフトウェアアプリケーションがハッキングされ、顧客の機密データがすぐに盗まれる可能性があるため、ソフトウェアの使用はホットな問題です。

したがって、信頼できるソフトウェアは、非常に有能なハッカーでさえ、適切な特権なしにアプリケーションに侵入することを許可するべきではありません。

  • セキュリティテストは、ソフトウェアへの特定の入力を使用してUATで実行され、ハッキングされないことを確認します。
  • セキュリティテストは、ソフトウェアをハッキングして脆弱性があるかどうかを確認しようとする合法的なハッカーによって行われます。
  • システムを稼働させる前に、すべてのセキュリティ上の欠陥を閉じる必要があります。
  • セキュリティとは、アプリケーションのさまざまなセクションを使用したり、データを作成および承認したりするための、さまざまなユーザー（外部および内部）へのログインとロールおよび特権も意味します。

＃5。外部ソフトウェアシステムとの統合：

通常、顧客のサイトに展開されるソフトウェアアプリケーションは、そこにすでに存在する可能性のある既存のソフトウェアとインターフェイスする必要があります。

例えば：印刷システムでは、それらが使用されているか、課金アプリケーションやデータ画面システムなどの外部システムである可能性があります。展開するソフトウェアアプリケーションは、これらの外部システムとシームレスに統合する必要があります。これらのシステムへのすべての入力と出力は同期して機能している必要があります。今日のテクノロジーには、モバイルアプリと、アプリケーションが必要とするさまざまなソフトウェアプラットフォームが含まれます。 と互換性があります 。

外部システムのインターフェースのチェックは、システムおよびUATの段階で広範囲に実行する必要があります。稼働前に満たす必要がある終了基準の必須事項である必要があります。

＃6。レポート：

ソフトウェアアプリケーションからのレポートは、アプリケーション内のデータが集計されていることを示すための重要な方法です。

例：すべての請求関連データは、貸方と借方の残高で集計する必要があります。

  • ソフトウェア内のすべてのデータを調整する必要があります。ソフトウェア内のデータのこの調整はレポートを通じて示され、意図したとおりに機能している必要があります。
  • これは、古いシステムから新しいシステムへのデータ移行が現在のリリースの主な目的である場合に特に当てはまります。

＃7。データ移行：

古いシステムが新しいシステムに置き換えられる場合、古いシステムのデータは新しいシステムに移動されます（新しいシステムを使用して締切日が到来した後）。 移行されたデータはサポートされている必要があります 要件収集中に定義された新しいシステムによって。

すべての古いデータが新しいシステムで利用できるとは限りません。ただし、古いデータのスナップショットを新しいシステムで利用できる可能性があります。このデータは、合意されたとおりに利用できる必要があります。

注意 ：上記のリストはすべてを網羅しているわけではありません。アプリケーションの種類によっては、検証する必要のあるものがさらにある場合や、上記のすべてが適用できるとは限らない場合があります。したがって、包括的な終了基準を作成するには、ソフトウェア、ビジネス目的、ユーザーの期待、およびアーキテクチャまたはハードウェアの依存関係を完全に理解する必要があります。

稼働開始の終了基準の例：

これはほんの一例です。プロジェクトごとに異なる場合があります。

  • 優先度1の欠陥は1​​00％クローズされます（重大度クリティカルおよび優先度1）
  • 優先度2の欠陥の90％はクローズされ（重大度が高く優先度2）、残りの10％の欠陥に対して論理的な回避策が利用可能です。そして、残りの10％の欠陥を閉じるための計画が利用可能です。
  • 本番環境の展開と健全性のチェックリストの準備が整いました。
  • 制作サポートチームが結成され、チケットを閉じる準備が整いました。
  • 優先度3の欠陥の70％がクローズされ、残りの30％の低欠陥をクローズする計画が立てられています。

注意すべきいくつかのポイント：

  • すべての重大度と優先度の定義は、プログラムの開始時に顧客とベンダーの間のビジネス会議で決定されます。
  • すべてのUAT欠陥がログに記録され、他のすべての欠陥がクローズされた後、UATコーディネーターとビジネススポンサーが集まり、保留中の未解決の欠陥を確認します。 1日目の運用開始に必要なすべての欠陥が解消された場合、ビジネススポンサーは、運用開始の準備ができていることを確認し、ソフトウェアを本番環境に移行します。

結論として

この記事で、本番環境での潜在的な障害からソフトウェアを保護する堅実な終了基準を作成する際の重要な考慮事項について、いくつかの洞察が得られたことを願っています。

著者について： これはクリシュナン・ベンカトラマンによるゲスト記事です。彼はソフトウェアテストで18年近くの経験があります。彼は多くの大規模で複雑なソフトウェアテストプロジェクトに取り組んできました。

以下に質問/コメントを投稿してください。

推奨読書

^