継続的なテストとは、ソフトウェア デリバリ ライフ サイクルにおけるビジネス リスクを防止および制御することです. ビジネス デリバリの各段階は、品質保証のためのテスト活動で補完され、可能な限り自動化され、テスト結果は製品プロセスに継続的にフィードバックされます. . テスト演習活動。継続的なテスト手法が広く適用されるにつれて、テストの左右のシフトがますます言及されるようになっています。
すべてのテストエンジニアは、テストを左にシフトする慣行を実現するために、要件の品質を確保し、要件レビューに参加する必要があることを知っています。そのため、要件レビューで何をしたいのかが明確に説明されることはほとんどなく、テストを左にシフトする必要があることも非常に漠然とした内容です。実際、テストを左にシフトすることはそれほど新しい概念ではありません. これは最初に Arthur Hichen によって提案されました: ウォーターフォール モデルの欠点を補い、テストがシステム配信前の最後の唯一の品質保証方法になるのを防ぐため、テストは左側にシフトし、プロジェクトの研究開発ライフサイクル全体を通して実行する必要があります。
要件分析段階で関連する活動に参加することにより、テスト エンジニアは、設計の初期段階でシステムに存在するビジネス ロジックの欠陥、使用上の欠陥、および相互作用の欠陥を早期に発見するのに役立ちます。開発に着手する前に解決し、チームの投資を無駄にせず、チームの入出力率とデリバリー効率を向上させます。
テストを左にシフトすることは、テスターを最も重要なプロジェクト段階に関与させることに焦点を当て、テスターが欠陥発見からリスク防止に焦点を移すことを可能にし、それによって技術的およびビジネス上のリスクを回避し、同時に次のビジネス目標の達成を促進します。プロジェクト。現在、テストを左側に移動する方法はたくさんありますが、最も一般的な実装方法は、要件明確化会議で、テストエンジニアが要件のビジネス合理性、システムの完全性、コンプライアンス、および要件のテスト可能性. 包括的な評価を行い、独自の質問を提起し、要件に対応する AC (受け入れ条件) に必要な内容を追加するよう依頼します。
反復プロセス中に、カードのオープンとカードの検証を通じて、テストの左シフトの練習を完了する必要があります. チームの開発エンジニアがストーリーカードを実装する準備ができたら、テストエンジニアと製品マネージャーを集めて、ストーリーカードの説明. 受け入れ条件は、ストーリーの理解とそれを達成する方法を詳細に説明します. このとき、プロダクトマネージャーがストーリーカードに受け入れ条件が欠けていることに気付いた場合, 彼は時間内にそれらを補足する必要があります. . テスト エンジニアは、自分自身の要件の理解、システム全体の理解、および上流と下流の依存関係に基づいて、受け入れ条件に欠けている内容を補足します. この種の迅速なグループ ディスカッションは、オープニング カード アクションです (英語)キックオフ、略してKOと呼ばれます）。研究開発が完了したら、プロダクトマネージャーとテストエンジニアも一緒になって、ストーリーと実装されたシステムの受け入れ条件に従って受け入れを完了する必要があります. プロダクトマネージャーは、対応するストーリーが実現されているかどうかに立ち、テストエンジニアは完璧かどうかに立ち向かう. さまざまな角度から分析し、通過後にテスト リンクに入る. この動作をチェック カードと呼びます (英語は DesckCheck、DC と呼ばれます)。このプロセスでは、受け入れ条件はこの要件のテスト ケースであり、テスト エンジニアは機能しないテスト ケースをいくつか追加するだけで済みます。このような受入条件とカード発行・カード認証の実践が受け渡しのスムーズさを担保し、現在のテストが左に動くのは有効な実践方法です。
右へのテスト シフトは、テストの左へのシフトを指します. 右へのテスト シフトは、製品が運用環境にリリースされた後のいくつかのテスト活動を指します. ただし、ここでのテスト活動は通常のテスト活動ではありません. 、しかし、いくつかの環境モニタリング、ビジネスモニタリング、APM、およびサービスの可用性と安定性を考慮するその他の手段を通じて、本番環境で問題が見つかった場合、問題はできるだけ早く製品チームに公開されます。迅速な修理を可能にし、ユーザーに優れたエクスペリエンスを提供します。テストを右に移動することは、テストを本番環境に移動することであり、この部分のテスト アクティビティと、よく呼ばれるテスト アクティビティとの間に多くの違いがあることも決定します。従来のテスト役割分担では、本番環境の担当者は運用保守エンジニアであり、運用保守のコアワークコンセプトは「安定性」であり、テストの迅速な検証と迅速な修復方法とは相反します。エンジニア。テストの正しい移行は、テスト活動のために実稼働環境に行くことだけではありません。もちろん、実稼働環境で実行できるいくつかのテスト プラクティスがあります。テストの右シフトは、運用と保守との競合ではありませんが、運用と保守のいくつかの技術プラットフォームを使用して、テストエンジニアに判断のための入力ソースを提供し、テストのいくつかの独自の技術的な沈殿物を組み合わせて、サービス品質の保証作業を完了します。を早期に発見するために、早期予防に基づく技術的手段であり、具体的な方法は次のとおりです
。保守エンジニアは、サービスのステータスを監視して、生産リンクの早期の問題を発見し、問題に対応するトレース データ (ログ情報、監視データなど) を欠陥システムに記録して、対応する生産の解決を支援します。欠陥 (損失の原因となる場合、それ
は故障の可能性もあります) ● 自動テストの使用: 自動テスト方法を使用できます。保守エンジニア、自動テストシミュレーションの業務ロジックにより、業務の安定性も確保できる、これもモニタリングレイヤリングの考え方です。
左側と右側のテストは相対的な概念であり、従来のウォーターフォール デリバリ モデルのテスト センター モデルと区別するためのプラクティスにすぎません. これら 2 つの優れたプラクティスにより、製品プロセス全体を通じて品質保証作業を実行できます. これにより、継続的なテスト。