DevOps方法論はテスターに​​とって何を意味しますか？

Paul Gerrardの記事「DevOpsはテスターに​​とって何を意味するのか？」の翻訳を読むことをお勧めします。

Paul Gerrardは、TestOpera LimitedのCTOであり、EuroSTAR European Testing ExcellenceおよびEuropean Software Testing Awards（TESTA）の受賞者であるUK Test Management Forumのディレクターです。

許可を得て行われた翻訳と出版

背景

この記事では、テストとテスターの観点からDevOps方法論の実装について説明します。 「DevOps Movement」（より良い名前はまだありません）は急速に発展しています。 この方法論に革新を導入する速度は、この業界で行われている他の多くの変更と同様、非常に高速です。 ただし、ムーブメント自体の名前はまだ明確に定義されていません。



チームの構造、話し相手に応じて、DevOps方法論は問題の解決策と独立した目標の両方になります。 一部の企業では、目標はデジタルテクノロジーへの移行であり、DevOps方法論は、定期的かつ高品質の展開を確保するための一般的なアプローチの一部です。 この意味で、この記事でDevOpsを検討します。 ただし、DevOps方法論に関連するテクノロジーおよびサービスのマーケティングを実装する場合、この目標は完全には理解されない可能性があります。 成功するために必要な文化的変化（または行動の変化）の問題は、しばしば過小評価されています。 私が始めているもう1つの前提は、DevOps方法論のフレームワーク内で作業しているテスターに​​とって、その影響下でこの方法論は新しいということです。



この記事は、このようなテスター向けのDevOps方法論の紹介として、またテスト方法への影響についての議論として作成しました。 DevOps方法論を使用した経験豊富な開業医である場合、この記事も役立ちます。 テスターでない場合は、少なくともテスターの観点から質問を見てください。

一般の読者向け：DevOps方法論とは何ですか？

簡単に言うと、DevOpsは、より密接に連携する開発グループとシステム運用グループを指定する概念です。 いわゆる展開パイプライン（ソースプログラムコードから運用環境での運用まで）で、開発者は運用グループのアクションを自動化します。 運用チームは、開発者のアクションを追跡し、それらに何らかの影響を与えることができます。 目標は、ソフトウェアの展開と実装を加速することです。 運用チーム（Ops）と開発者（Dev）（実際にはアジャイルメソッドを使用するチームの形で）の組み合わせにより、「アジャイルオペレーションベースのオペレーション」（アジャイルオペレーション）と呼ばれるアプローチを実装できます。



DevOps手法の実装が成功したことの明らかな結果は、ソフトウェアの変更がアイデアから運用環境での運用までのすべての段階を経るのにかかる時間を短縮することです。 開発者がソフトウェアの変更が「完了」したと言うと、本番環境での変更の使用への移行は包括的な自動化によって行われます。 自動化されたツールとプロセスは、システム構成中、アセンブリプロセス中、テスト中、テスト環境、中間環境および運用環境での展開、展開完了後の監視、評価および運用中に使用されます。

それでは、DevOpsは単なるツールですか？

一方では、DevOps方法論の目標は、自動化を使用して展開パイプラインのボトルネックを排除することです。 しかし、多段階プロセスの自動化は依然として管理する必要があります。 多くの自動化されたプロセスは実際には自律的ではありません-それらは人間の介入なしに実行できません（メンテナンスを実行し、非標準的な状況を処理します）。 完全に自動化されたDevOpsプロセスは、人的要因の影響を考慮しないと意味がありません。 自動化ツールは多くの大まかな作業を行うという事実にもかかわらず、プロセスを管理するのはプロセスの成功（または失敗）を保証する人々です。

では、DevOpsは、自動化と密接に連携する開発者（Dev）と運用チーム（Ops）にすぎませんか？

いいえ、間違っています。 自動化されたプロセス間での制御の移行には、多くの場合、他のプロセスが含まれます-通常、何らかの種類のテスト 自動テストは、開発者とテスターに​​よって作成されます。 これらのテストの結果は、他のプロセスを実行するために必要な、または多くの場合、コンベヤーのあるステージから別のステージに移動する人々に必要な十分な情報を提供することを目的としています。 テストを実施するテスターと開発者は、DevOpsプロセスを確実かつ確実に実行できるようにします。



向こう！ そして、DevOpsとはどういう意味ですか？ これは、進歩的な最新の分野です。 この問題については、 「DevOpsとは？」という記事で詳しく説明されています。この記事は、この記事を書く数週間前に登場しました。 既に理解したように、DevOpsの定義はまだ確定していません。 おそらくそれは決してないでしょう。



これはテスターに​​とって何を意味しますか？ これは、これまで「唯一の正しい方法」がなく、絶えず進化している（そして各モードは常に進化している）DevOpsモードでの役割がまだ最終的に確立されていないことを意味します。 実装できる2つのポイントがあります。



1）痛みのポイントに注意を払い、そのマイナスの影響の程度を減らす努力をします。

2）DevOpsプロセスを最適化できる機会を特定します。



DevOps方法論への移行を最もよく説明する単一のマントラがある場合、次のように聞こえます。「これが不快な場合は、より頻繁に行ってください。」 それは決まり文句のように思えるかもしれませんが、この表現は、DevOps方法論を使用して実用的なテストスキルを導入および改善するためのコンテキストとして使用します。

不快な場合は、より頻繁に行います。

特定の仕事をしているときに経験する困難や不快感は、マイナスの影響を与えます。 タスクが気に入らない場合は、延期に努めます。 私たちがついにこの不快なビジネスに乗り出すとき、それはさらに耐え難いものになります。 歯科医への訪問、ガレージでの清掃、ソフトウェアの統合、テストなど。経験から、こうしたタスクを実行する頻度が低いほど、不快であることが示唆されています。 マーティンファウラーは、頻繁な（または継続的な）タスクによって不快感を軽減できる3つの理由を提案しました。



最初の理由は、大規模で複雑なタスクは計画が難しく、管理が難しく、制御が難しいことです。 大きなタスクをいくつかの小さなタスクに分割すると、タスクを完了してリスクの程度を簡単に減らすことができます。何か問題が発生した場合、すべてを以前の状態に戻すのが簡単になります。 2番目の理由は、多くのタスク（およびこれに関するテストが最良の例）がフィードバックを提供することです。 このフィードバックは、早い段階で十分な頻度で届く場合、時間の無駄になる前に発生する問題にすばやく対応できます。 そして、3番目の理由：アクティビティをより頻繁に実行する場合は、より適切に対処する必要があります。 この作業を効率的に行う方法を学びます。 さらに、何らかの方法で自動化する方法を見つけます。



テスターの観点から、このマントラは、テストプロセスの実装における自動化の概念に対するより深刻なアプローチを強制します。 手動の介入が実行される場合（通常、DevOpsプロセスの自動化された段階間）、それは問題点であると見なされる必要があります。ボトルネック、遅延の原因、プロセスの潜在的に信頼性が低くエラーが発生しやすい側面です。



手動テストは不快です。 はい、研究テストを実施するのは楽しいことがあります。自動化では決して見つけられないような複雑なエラーを人だけが発見でき、テスターとしてのあなただけが大惨事を防ぐことができると信じることができます。



あなたは、テスターとして、開発者または自動化されたツールに委託された場合、テスト作業が適切に実行されるかどうかを心配するかもしれません。 これが不快な場合は、より頻繁に実行してください。

テスト、自動化、信頼

たとえば、 テストとテストの意味、およびテスター、チェック、自動化ツールにどれだけ依存できるかについて、多くの論争があります（ 新しいモデルとテストvチェック ）。



自動チェックに完全に頼るべきだと言っているのではありません。 より複雑なアプローチを適用する必要があります。 ただし、この記事の目的上、少なくともテストとテストアクティビティを4つのコンポーネントに分割できます。



1）チェックおよび継続的統合プロセスの一部として開発者が自動化できるチェック。



2）API、通信回線、またはシステム全体のレベルでトランザクションを実行するために自動化できるチェック（通常はシステムテスターに​​よって）。



3）互換性チェックを含むテスト、およびブラウザー、オペレーティングシステム、プラットフォームとの互換性の実証



4）人によってのみ実行できるテスト。



この記事では、このような分離を行う方法のみを想定しています。各環境には独自の特性があります。 この記事の最も適切な質問は、テスターが手作業による後期チェックから「自由になる」方法です。 以前、手作業による遅いチェックの除外について書きました。 これには先入観と信頼が必要です。



次の点に注目する必要があります。



1.可能であれば、コンポーネントレベルで実行できる手動チェックを開発者に割り当てる必要があります。 テスターとして、ペアまたはチームセッション中にこれらのテストの実行を提案できます。 それらを自分で記述し、継続的統合モードで有効にすることができます。



2.ユーザーインターフェイスのテストと複雑なテストには、自動化ツールの使用が必要になる場合があります。 このようなテストは、時間がかかり、不安定で、多くの場合メンテナンスが必要なので、最小限に抑える必要があります。 プログラムコードをチェックするたびに実行する必要があるかどうか、または大規模で頻度の低いリリースでのみ使用するために遅延させることができるかどうかを検討します。



3.プレリリース版にまだ統合されていないコンポーネントで実行できる自動化されていないテストは何ですか？ 開発者とのペアリングセッションで手動テストを実行できますか？ そのようなテストに代わるものはありますか？ BDDアプローチを使用したプロトタイピングは、アーカイブドキュメントで作業できますか？ レイアウトまたはワイヤフレームでユーザーインターフェイスチェックを実行できますか？



4.回帰テストのために残す必要のあるチェックとは対照的に、手動でのみ実行する必要があるチェックはどれですか（自動テストの候補です）。



上記で信頼について言及しました。 もう1つの問題は、後期の手動テストがない場合にシステムを確実にテストする方法です。 すべてのテストが自動化ツールによって実行される環境を想像してください。 開発者がテストを適切に実行すると思いますか？ テストの心配を左にシフトすると、疑念が払拭されるはずです。 テスターとしてパスファインダーのように振る舞う場合：リスクを識別および評価し、テストを選択し、それらが開発および自動化プロセスに統合されていることを確認するために、懸念を最小限に抑えることができます。



当然のことながら、自分自身を質の高い警備員、防衛の最後のフロンティア、気にする唯一の人と考えるのをやめるべきです。 もっと先見の明のある、リスク識別子、リスク管理者、レンジャー、コーディネーター、インストラクターまたはメンターとして考える必要があります。

練習、監視、改善

望みどおりに、遅い手動チェックに頼るのをやめると、まだエラーがあるかもしれません。 ソフトウェアが実稼働環境にリリースされると、問題が発見されます。 操作に関するDevOps方法論の重要な分野の1つは、より詳細な監視です。

アプリケーションのコンポーネントや単純なトランザクションから、統合やメッセージング、そしてもちろんインフラストラクチャ自体まで、あらゆるレベルで監視します。 監視の目的の1つは、ユーザーが結果を経験する前にエラーメッセージを生成することです。 これはかなり野心的な声明ですが、最終的な目標を定義しています。



本番環境で問題が発生した場合、タスクは、監視中に取得した分析情報を使用して、原因を追跡してそれを排除するだけでなく、テストプロセス（自動または手動）を明確にし、そのような可能性を減らすことです将来の問題。 パイプライン全体の操作におけるテストおよび分析情報の役割は、記事「Thinking Big：Introducing Test Analytics」で定義および説明されています。



DevOpsプロセス監視の自動テストを呼び出すことができます。 監視を実稼働環境と組み合わせた場合、DevOpsプロセス全体を監視して実稼働環境に移行すると、テストの範囲が広がると言えます。 したがって、DevOps方法論はテスターの役割を減らすものではありません。

おわりに

最近、「どの場合に、DevOps方法論を組織に適用しようとすべきではないのですか？」 これはいい質問です。 これは、DevOps方法論が標準になるべきか、テスターがこれに注意を払うべきかという恐怖に基づいていると思います。 私の答えは簡単です。

開発者とオペレーターが互いに会話できるようにしないのはなぜですか？ テスト環境と運用環境で、より信頼性の高いビルドと展開を開始してみませんか？ より正確で効率的で有益なコンベヤに最高の技術を使用してみませんか？ DevOps方法論は良いことですが、必要なレベルの使用を達成することは必ずしも容易ではありません。 文化の変更が必要なことは言うまでもありませんが、それほど単純ではありません。



テスターの観点から見ると、DevOps方法論はプロジェクトの初期段階でより大きな影響を与え、テストの自動化、情報の提供、意思決定についてより真剣に考えさせます。 テスターは、DevOpsメソドロジの使用に努める必要があります。これは、プロアクティブなモードでアクションを実行する機会を提供し、プロジェクトチームの幅広い権限と尊敬を得るためです。



11月11日、ポールジェラードはモスクワで「デジタル時代のテスト：DevOps、ChatOps、テストをサポートする自動化」というトピックについてマスタークラスを開催します。