品質保証の中心的な目標
実際のプロジェクトやチームでの品質保証の中心的な目標は、明確な合意や能力を持っていることはめったにありません。実際の経験という点では、オンライン障害の削減に帰することができます。この経験から得られた目標は、実際には非常に広い目標ですが、チームメンバーの努力により、この目標は「去るなら」のままです。
さまざまな担当者の観点から見ると、テストの目的には、故障の減少と人間の効率の向上、反復サイクルの短縮という共通の期待があります。しかし、テスト結果への期待とオンライン障害の削減は、中核的な目標と言えます。
製品故障の幅広い定義
大まかに言うと、障害には、ハード品質に起因する問題、ソフト品質に起因する問題、および要件定義に起因する問題が含まれます。
ハード品質に起因する問題
オンライン/構成の変更によって直接引き起こされるオンラインの利用不可の問題を指します（ユーザーは直接利用できません）
ソフト品質に起因する問題
新機能の起動/改訂によって引き起こされた使用できない問題を指します（もちろん、ユーザーは直接不快に感じますが、実際のプロジェクトのこの部分は、バージョンをロールバックすることによってオンラインの障害として直接扱われることはあまりありません。）
要件定義に起因する問題
これは、新機能が起動/改訂された直後に新機能が再起動されることを意味します。以前の実装を覆す、戻る、Big Bossが実装を3週間転覆するなど。
障害の発生にはさまざまな状況が考えられますが、ここでは障害を狭い視点で定義する、つまり、利用できないという問題をユーザーに提示し、ハードの品質に起因する問題に対応するためにバージョンをロールバックして対処することが多いです。
オンライン障害を減らす方法は？
障害を減らすために検討すべき研究開発段階
障害は、要件、技術設計、開発、テストの失敗、オンラインの不規則性のプロセスで発生する可能性があるため、障害の制御は各段階から開始する必要があります。
既存の障害について、再開するときに最も根本的な理由を見つけます
オンライン障害の最も一般的な形式は、エッジ関数の検出漏れ、新しいオンライン関数の問題などですが、これらの問題が発生した場合は、さらに掘り下げる必要があります。たとえば、関数のテストが欠落している場合、QA /開発者は影響ポイントの評価が不十分である可能性がありますが、頻繁で急速なオーバーロードの反復であるため、訪問する時間がなく、新しい関数の問題は開発者/ QAスタッフが原因である可能性があります。オンラインチェックリストの評価の失敗は、プロジェクト管理の混乱や、オンライン環境とオフライン環境のギャップが原因である場合もあります。
ビジネスの成熟度とチームメンバーの特性に基づいて的を絞った対応
ビジネスの段階によって品質へのフォーカスのレベルは異なります。たとえば、製品の残酷な成長の期間では、製品のプロトタイプを迅速にリリースするために、使用に影響を及ぼさない問題が発生する可能性があります。
チームメンバー（製品、R＆D）によって協力の方法は少し異なります。たとえば、一部のチームメンバーは特に経験豊富で、ニーズと品質が非常に高いです。このとき、チームメンバーと協力して、より成熟した製品品質データを作成することができます。 ;逆に、少しずつ開始するには、最も基本的な需要の変更、テスト、およびその他のプロセスから開始する必要があります。
プロジェクト全体の成熟度の具体的な評価
- 反復サイクル全体が品質のリスクを引き起こさないことを保証するために適切かどうか。
具体的には、需要の変化、開発サイクル、テストの遅延、オンラインサイクルの観点から時間がかかりすぎるかどうか。時々回線に追いつくことはそれほど問題ではないかもしれませんが、長い間、問題は避けられないかもしれません。
- 人材の効率をテストします。
主に、テストの深さと幅にコストパフォーマンスの高いテスト実行方式を採用するかどうかを指します。もちろん、自動実行は手動実行よりも効率的である必要があると言わざるを得ません。重要なのは、効率が高い特定のシナリオにあります。
- カバレッジをテストします。
テストプログラム全体が、テストカバレッジを確保するのに十分な深さと幅があるかどうかを示します。
- 需要特性。
需要に基づいて特別な考慮が行われます。たとえば、コードの書き換えが楽観的すぎることが多い場合、結果は楽観的すぎます。現時点では、周志チームメンバーは特別な注意を払う必要があります。
- ビジネスの結合。
密結合ビジネスが開発/テストにおいて妥当かどうかを検討する必要があります。ずっと前に、ビジネスBと接触していたことを覚えています。ビジネスAに強く依存していて、ビジネスAとBは2つのチームに属しています。問題は、開発中によく知られている必要があるだけでなく、テスト時にビジネスAを見つける必要があることです。もちろん、スタッフがシーンを作成したため、カップリングが高すぎるためにテストが不十分になり、オンライン障害が発生しました。
- リスク管理。
主に障害の劣化、グレースケールリリース、反復頻度/リリースサイクルなどが含まれます。さまざまなビジネス特性に応じて、さまざまなリスク管理計画を策定する必要があります。たとえば、一部のビジネス自体は複数のビジネスに大きく依存しています。問題が発生すると、その原因のトラブルシューティングは特に困難になり、デバッグツール/ソリューションを提供して問題をより正確かつ迅速に特定できます。一部のビジネスには新しい機能/サービスがあります次に、オンラインの問題/誤操作/環境のギャップによって引き起こされる問題を最小限に抑えるために、オンラインの演習/リリース前のソリューションを提供する必要があります。（終了）
この記事の著者は、上級テストテクノロジの専門家です。
