ご来場いただきありがとうございます。月曜日から金曜日まで、TNS の最高のコンテンツが届き、最新ニュースやゲームでのトップの座を維持できます。
受信トレイで確認メールを確認し、設定を調整したり、追加のグループに参加したりすることができます。
お気に入りのソーシャル メディア ネットワークで TNS をフォローしてください。
LinkedIn で TNS のフォロワーになりましょう。
最初の TNS ニュースレターを待つ間に、最新の特集記事やトレンド記事をチェックしてください。
これは2部構成の第1部です。
シフト レフト テストとは、開発プロセスの早い段階でテストを行う方法です。従来の開発サイクルでは、テストは機能の完成後、または開発フェーズの最後に行われることがよくあります。シフト レフト テストでは、テスト アクティビティを開発プロセスの最初から最後まで統合することで、この状況に対処します。
まず、シフトレフトのオプションを選択した理由について説明します。これは、ソフトウェア開発ライフサイクル (SDLC) のスケーリング問題を解決する唯一の方法ではないためです。
プロセスの開発側にさらに多くのテストを移行することを決定する前に、リーダーがそもそもなぜこの決定を下すのかについて説明しましょう。
「シフト レフト」には、「従業員にもっと仕事をさせて、給料はそのまま」という皮肉な解釈もあります。ストレスのたまった開発チームは、自分たちの案件にさらに懸念事項を追加するという考えに反発するかもしれません。しかし、テストをシフト レフトする本当の動機は、行き詰まったソフトウェア リリース サイクル、開発者がコンテキスト スイッチを強いられ、フロー状態に入ることを決して許されないこと、そして開発速度が遅いことに対する不満です。
スタートアップ段階を過ぎて規模を拡大している会社にいると想像してください。機能が数週間、あるいは数日でリリースされた時代を皆さんは覚えているでしょうが、そんな時代はもう過ぎ去りました。現在、複数のチームが同時にブランチをリリースしようとしており、QA は本番環境にリリースする前に問題を見つけようとストレスを感じています。
さらに悪いことに、マイクロサービス アーキテクチャの複雑さにより、開発者はコードを QA に出荷する前に効果的に統合テストを行うことができません。契約テストの改善については多くの議論がありますが、繰り返しになりますが、状況は急速に拡大しており、明確なサービス内契約を記述してそれに合わせてリファクタリングするには数か月かかると見積もられています。その間、開発者はユニット テストを記述し、支払いプロバイダーなどの外部サービスや他のチームのサービス用の粗雑なモックを作成することに追われています。これにより、ステージングなどのリリース前の環境にコードをデプロイするときに、さらに驚くような結果になります。
そこで、当社のエンジニアリング リーダーは、開発の速度を向上させながら、本番環境にリリースするバグを減らすにはどうすればよいかという選択に直面しています。選択肢は 2 つあります。
これは、あまりスケーラブルな選択ではありません。すでに、チーム間では、誰がステージングにデプロイするか、環境をどのくらいの期間予約しておく必要があるかについて、時折衝突が起きています。さらに、QA エンジニアを増やしても、開発者はコードを書いて、限定的なテストを実行し、プッシュして、検出された問題を人間が書き戻すのを待つことになります。その結果、「外側のループ」フィードバック サイクルが発生し、開発者は QA フィードバックを受け取るまですべての作業を一時停止するか、2 つのブランチ間でコンテキストを切り替えて次の機能に取り組もうとしているときに、最後にプッシュしたものに戻って問題を見つける必要があります。QA チームに無制限の予算があったとしても、これが何百人もの開発者に拡張されることは絶対にありません。
エンジニアリング チームがテストをシフト レフトする中で、QA はテストの戦略的ビジョンとアーキテクチャの決定において重要な役割を果たします。しかし、より多くのリリースを成功させるという目標は、QA チームを拡大するだけでは完全に達成されません。それはなぜでしょうか。
その属性のリストは配列ですか、それともオブジェクトですか? また、そのロケータは 0 からインデックス付けされていますか? これらの小さな統合エラーは、QA がテストしているときにリリースをブロックする可能性があります。開発者が自分のコードで小さな問題を見つけてすぐにエラーを修正する代わりに、QA は問題を文書化して伝える必要があります。さらに悪いのは、QA が誰と連絡を取ればよいかわからない場合です。
開発者として user_state_controller を更新しますが、QA として「ユーザーがログインを更新できる」などのテストを行う場合があります。チームの目標が異なるため、これは不一致ではありません。ただし、QA がユーザー フローでエラーを見つけた場合、開発部門の誰に相談するのが最適かは必ずしもわかりません。これにより、さらに遅延が発生します。
実行する最適なテストのセットを決定するエンジニアのチームがなければ、QA はテストを低い頻度で実行することになり、大規模なグループでのみ問題が見つかることになります。
これは、さらに議論する価値があると思う基本的な内訳です。QA チームによる大規模なテスト スイートの実行は、すべてが設計どおりにエンドツーエンドで動作していることを確認するための魅力的な方法です。ただし、高忠実度のテストは高頻度で行う必要があります。そうしないと、ソース管理の基本的な利点が失われます。コミットごとにテストを実行しないと、簡単にロールバックして修正できなくなります。これは、「シフト レフト」テストが古い標準に戻る多くの方法の 1 つです。開発者は、現在の変更グループによって何かが壊れたかどうかをすぐに判断できる必要があります。最初に問題を見つけるために QA に頼るということは、どのコミットが原因であるかを判断するために、長い失敗リストを精査することを意味します。
ここでも、2005 年のコーディングおよび配信標準からの退行についてお話します。ウォーターフォール モデルでは、本番環境への真の継続的配信は不可能になります。
ここで重要な考え方の 1 つは、QA だけがバグを発見すると、エンジニアの権限が奪われるということです。
速度への影響に関するリーダーシップ レベルの懸念がなくても、ほとんどのフィードバックが外側のループで行われる設定は、エンジニアにとってフラストレーションがたまり、苦痛になることは想像できます。私自身のエゴはさておき、自信のないコードをプッシュしたくはありません。これがオプション 2 につながります。
このシナリオでは、開発者として物事を壊すことが再び楽しく感じられるようになります。私たちは実験し、他のサービスがサポートできるものを確認し、うまく機能することがわかっているものだけをプッシュします。この設計では依然として QA が重要な役割を果たしますが、手動でテストして個々のバグを見つけることはそれほど重要ではありません。むしろ、QA チームは自動化戦略の定義、テスト フレームワークの選択、開発者がコードに自信を持てるようにすることにおいて戦略的リーダーになります。毎日すべてのエンジニアがテストを利用できるため、作成および実行されるテストの数が増えますが、そのフィードバックはフィードバックの内部ループを通じて開発者に直接送られます。
プラットフォーム エンジニアリングの Lean Coffee グループでの最近の議論で、数人の参加者が言及した 1 つのアイデアが印象に残りました。
「マイクロサービスには多くの利点がありますが、マイクロサービスはテストが非常に困難です。この問題は非常に深刻であるため、多くのチームはマイクロサービスから実際のメリットを得ていません。」
これについては以前にも書きましたが、要約すると、モノリスの時代には、システム全体またはその複製をラップトップで最小限の摩擦で実行する方法がよくありました。つまり、開発中に重要なテストを実行できるということです。
つまり、テストを左にシフトするということは、テストを後ろにシフトするということです。QA チームの役割は依然としてありますが、最初の一連のテストは、機能を作成するエンジニアの手に委ねたいと考えています。
この記事の続きでは、テストの実行責任を開発チームに移管する際に QA が担う役割と、今後も担う役割について書きます。簡単に言うと、開発者がより多くのテストを実行する場合、QA の役割は依然として大きく、QA の役割は減るどころか増えることになります。この記事やシフト レフト テストのアイデアについて議論したい場合は、Signadot Slack にご参加ください。皆さんのアイデアをぜひお聞かせください。
コミュニティが作成したロードマップ、記事、リソース、開発者向けのジャーニーは、あなたの進路の選択とキャリアの成長に役立ちます。
元記事: https://thenewstack.io/why-we-shift-testing-left-a-software-dev-cycle-that-doesnt-scale/