devops testing tutorial
DevOpsテストチュートリアル: 最近のRightScaleの調査によると、企業の54%がDevOpsを採用しており、DevOpsに関する関心が急速に高まっています。
jsonファイルを開くにはどうすればよいですか
この記事では、この新しいソフトウェア開発方法論がQAにどのように影響するか、そしてこの変更を受け入れるためにQA機能全体がどのように進化するかを学びます。
チェックアウト=> 完全なDevOpsチュートリアルシリーズ
この記事では、DevOpsと、それがQAとその機能にどのように影響するかについて詳しく学びます。
学習内容:
DevOpsとは何ですか?
DevOps –の組み合わせです 開発者駆け落ち&オンerations –これは、開発から運用までのすべてのソフトウェア開発機能を同じサイクル内で統合することを目的としたソフトウェア開発方法論です。
これには、ソフトウェア開発プロセスのさまざまな利害関係者内でのより高いレベルの調整が必要です(つまり、 開発、QA、運用 )
DevOpsサイクル
理想的なDevOpsサイクルは、次の場所から始まります。
- コードを書く開発者
- QA環境でのバイナリの構築と展開
- テストケースを実行し、最後に
- 1つのスムーズな統合フローで本番環境にデプロイします。
明らかに、このアプローチでは、ビルド、展開、およびテストの自動化に大きな重点が置かれています。継続的インテグレーション(CI)ツールの使用、自動化テストツールは DevOps サイクル。
なぜDevOpsなのか?
間に微妙な違いがありますが アジャイルおよびDevOpsテスト 、アジャイルを使用している人は、DevOpsを使用するのに少し慣れている(そして最終的には採用する)ことに気付くでしょう。アジャイルの原則は開発とQAの反復でうまく適用されますが、運用側ではまったく別の話です(そして多くの場合、論争の骨です)。 DevOpsは、このギャップを修正することを提案しています。
現在、継続的インテグレーションの代わりに、 DevOpsには「継続的開発」が含まれます 、コードが記述され、バージョン管理にコミットされた場所は、エンドユーザーがすぐに使用できる本番環境でビルド、デプロイ、テスト、およびインストールされます。
環境とプロセスが標準化されているため、このプロセスはチェーン全体のすべての人に役立ちます。 チェーン内のすべてのアクションは自動化されています。 また、すべての利害関係者が、さまざまな構築、運用、およびQAプロセスについて心配することなく、高品質の成果物の設計とコーディングに集中できるようになります。
これにより、コードが記述されてコミットされてからエンドユーザーが消費するための本番環境への展開まで、存続時間が約3〜4時間に大幅に短縮されます。
一言で言えば、DevOpsはアジャイルの拡張であるか、私はそれを「ステロイドのアジャイル」と呼んでいます。
DevOpsでのQAの役割の変更
従来、QAは指定された環境にデプロイされたビルドを取得し、QAはその後 機能的 & 回帰試験 。ビルドは、理想的には、ビルドのQAサインオフの前に数日間QAと一緒に座っています。これらのステップはすべて、DevOpsで変更されます。
DevOpsテストのQA変更:
- QAは、DevOpsサイクルでの取り組みを調整する必要があります。
- すべてのテストケースが自動化され、ほぼ100%のコードカバレッジを達成していることを確認する必要があります。
- 環境が標準化され、QAボックスへの展開が自動化されていることを確認する必要があります。
- テスト前のタスク、クリーンアップ、テスト後のタスクなどはすべて自動化され、継続的インテグレーションサイクルに合わせて調整されます。
すでに述べたように、DevOpsには、成果物チェーンのさまざまな機能間の高レベルの調整が必要です。これはまた、チェーン内の貢献者のさまざまな役割の間の境界が多孔質になることを意味します。
DevOpsは、すべての人がチェーンに貢献することを奨励しています 。 したがって、とりわけ、開発者はデプロイメントを構成できます。展開エンジニアは、QAリポジトリにテストケースを追加できます。 QAエンジニアは、自動化テストケースをDevOpsチェーンに構成できます。
総称して、チェーンの全員が成果物の品質と適時性に責任があります。
DevOpsとテスト自動化
このような速度と敏捷性を実現するには、すべてのテストプロセスを自動化し、QA環境での展開が完了したときに自動的に実行されるように構成することが重要です。この統合を実現するために、専用の自動化テストツールと継続的インテグレーションツールが使用されます。
これには、新しいテストケースをすばやくスクリプト化できる成熟した自動化テストフレームワークの構築も必要です。
DevOpsテスト戦略:DevOpsを成功させるためのヒント
- 特定のビルドで実行する必要のあるテストケースを特定する必要があります。
- テストの実行は本質的に無駄のないものでなければなりません。
- QAと開発者は一緒に座って、特定のビルドによって影響を受ける領域を特定し、それらの関連するテストケースと健全性テストパスを実行する必要があります。
- また、ほぼ100%のコードカバレッジを確実に達成するために、専用のコード分析およびカバレッジツールを構成する必要があります。
- 実行の概念 すべて テストパスの回帰テストケースは間もなく廃止されます。
- 新機能のテストに関する戦略を形式化する必要があり、暫定ビルドをQAに提供して、QAがテストスクリプトを作成し、コードが本番環境にデプロイできるほど安定するまで、暫定ビルドでこれらの自動化テストを実行できます。 。
- テストに必要なすべての環境を標準化し、展開を自動化する必要があります。
- QAは、さまざまな自動化手法を使用して、さまざまなクロスプラットフォーム(およびWebアプリケーションの場合はクロスブラウザー)環境で自動化テストの実行を実行できる必要があります。
- テストの並列実行は、有効期間の短縮に役立ちます。これは、DevOps実装を成功させるための核心です。
- テストの結果がチェーンにフィードバックされるときに、本番環境への合否の決定が行われるように、実行ごとに終了基準を設定する必要があります。
- 見つかったブロッカーまたは重大なバグは、コードを本番環境にデプロイする前に、報告および修正し、同じ一連のイベントを通過させる必要があります。
アプリケーションの監視
QAは、問題を早期に検出し、事前に報告できる必要もあります。これを実現するには、本番環境で監視を設定して、バグが発生する前にバグを公開できるようにする必要があります。
応答時間、メモリとCPUの使用率などの特殊なカウンターを設定すると、エンドユーザーエクスペリエンスに関する多くの洞察を得ることができます。
例えば 、ログインの平均応答時間がさまざまなビルドで徐々に増加している場合、QAはログインコードを最適化するためにこの問題を積極的に報告する必要があります。そうしないと、将来のビルドで応答時間が長くなり、エンドユーザーのフラストレーションが生じる可能性があります。
QAは、既存の優先度の高いテストケースの小さなサブセットを使用して、本番環境で定期的に実行し、環境をアクティブに監視することもできます。 「このバグは時々現れる」や「 再現できません 」は、この戦略を通じて捉えることができます。これにより、最終的にはアプリケーションがより安定し、エンドユーザーの満足度も高まります。
繰り返しになりますが、これらのモニターは、豊富なレポート(ログや障害のスクリーンショットなど)で自動的に実行されるように構成する必要があります。
結論
ウォーターフォールはV-Modelに取って代わられ、ソフトウェア開発の優先選択肢としてアジャイルに置き換えられました。
DevOpsは未来です。 これは、ソフトウェア開発モデルが時々受ける継続的な改善サイクルです。あなたはそれを受け入れ、理解し、教え込む必要があります。
さまざまな自動化ツールと継続的インテグレーションツールを習得して、自動化の取り組みがチェーンに付加価値をもたらし、変化にすばやく適応できるように無駄を省く必要があります。あなたは関与するかもしれないプロジェクトに取り組んでいるかもしれません アルファ 、 ベータ そして UAT 本番環境にデプロイする前の環境。
コンセプトは基本的に同じです。 自動化とさらなる自動化は、成功するDevOpsサイクルの中核です。 ただし、QAとして、自動化が多すぎるという点についても線を引くことができるはずです。
著者について: Aniket Deshpandeは、でQAマネージャーとして働いています。 AFour Technologies 、Puneは、さまざまなドメインおよびプラットフォームで過去9年以上ソフトウェアテストの分野で働いてきました。彼はDevOpsに情熱を注いでおり、DevOpsテスト戦略を採用する際に組織を指導するコンサルタントとして働いています。
詳細を知りたい場合、または組織にDevOpsと関連するテストアプローチを実装したい場合は、お気軽に 連絡先 著者。
DevOpsテストについてどう思いますか?開発者と運用担当者を協力させることで、プロジェクトに利益をもたらすことができると思いますか?
この記事についてのコメント/提案を教えてください。