開発者がいる場合は、近くにテスターがいるはずです。そして、システムが複雑になるほど、後者の役割はより重要になります。しかし、すべてのテスターが同じ方法で同じ機能を実行するわけではありません。今日は、クロスシステムテストを扱うM.Video-Eldoradoの特別なユニットの出現についてお話したいと思います。テスターの別のカーストを作成することにした理由、それがビジネスにどのように役立ったか、そしてカットの下でこの決定に至った経緯についてお読みください。
更新が本番環境にロールアウトされた後にシステムが機能するかどうかを確認しない場合、小さなバグがクライアントサービス全体またはバックオフィスプロセスなどを「置く」可能性があります。これを防ぐために、アジャイルチームには、基本的なシナリオの実行をチェックし、開発者にバグを報告する独自のテスターが必要です。サービスがシステムの他のコンポーネントと相互作用する場合、チームは統合テストを実施することがよくあります。つまり、サービスエコシステムの最も近いコンポーネントが相互に及ぼす影響をチェックします。
しかし、私たちの時代では、ビジネスプロセスははるかに複雑であることが多く、望ましい結果を達成するには、1ダースほどのサービスの作業が必要です。この場合、2つまたは3つの隣接するシステムだけでなく、ストリーム全体の変更の互換性をテストする必要があります。
したがって、統合テストはエラーのない動作を保証しなくなりました。次に例を示します。モバイルアプリケーションの開発者がリリースをリリースすると、最大で、Bitrix（Eldorado Webサイトが実行されている）との互換性がチェックされます。これにより、サービス自体の作業のみを評価できますが、注文が履行され、商品が顧客に提供され、発行価格がアプリケーションの価格に対応することなどを保証するものではありません。
実際、複雑なプロセスは現代の標準です。たとえば、M.VideoとEldoradoでは、オンライン注文には20以上のシステムの参加が必要です。クライアントの側から見ると、すべてがシンプルに見えます。購入者は、モバイルアプリケーションまたはオンラインストアのWebサイトにアクセスし、製品を選択してバスケットに入れ、次の都合の良い日に配達を割り当てるだけです。宅配業者は、購入者が指定した時間に指定された住所に商品を配達します。
しかし、ITサービスの側でこれらすべてを可能にするために、承認システム、サイトエンジン、価格計算モジュール、支払いゲートウェイ、CRMシステム、会計などの相互作用があります。また、コンポーネントの1つに何らかの変更を加えると、購入プロセスの「故障」が発生するかどうかを評価するには、すべてのシステムの相互作用を確認する必要があります。
- ?
一方では、各チームにはすでに独自のテスターがいます。そして、彼はエンドツーエンドのテストに関与できるように思われます。しかし、私たち自身の経験から、このアプローチは最も効果的ではないことがわかりました。システム間テストは、定義上困難です。実行するには、各システムからテスターを取り出して指示し、運用する必要があります。
テスターNは、ステージを完了した後、ステージが完了したことをテスターN +1に報告する必要があります。男性は通常、自分のビジネス（機能テストと統合テスト）で忙しく、システム間のテストプロセスは遅いです。
実際のケース：テスターは昼食に行きましたが、彼が戻ったとき、彼は自分のステージを完了しなければならないことを忘れていました-彼は他の多くの仕事をしています。彼が思い出されるまで、プロセスは価値があります。
ある段階で問題が見つかった場合、すぐに「どちら側にあるのか」という疑問が生じます。たとえば、テスターN +1は前のスペシャリストにエラーを返します。そして、テスターNは憤慨しています：「私たちのシステムと私はそれと何の関係があるのですか？」彼らが真摯に「彼ら」とは考えていない問題がどちらの側で起こったのかを彼らが理解するまで、それは数日かかるかもしれません。その結果、締め切りに間に合わず、プロセスを絶えず推進する必要があります。
最後に、このようなテストを実施するには、プロジェクトを立ち上げ、プロジェクトマネージャーを接続し、定期的に1つの部屋（システムごとに1つ）に20人を集め、次のステップに進むときにどちらの側で問題が発生するかを把握する必要があります。これは非常に労働集約的で非効率的であり、人々が彼らの主な仕事であると正当に考える仕事から人々の気をそらします。
クロスシステムテスト部門を作成する方がよいと判断しました。この部門では、すべての主要な更新を本番環境にリリースする前に、ビジネスプロセス全体をテストします。
自身の経験-プロモーションアクション
これを行うことにしたとき、大きなプラスは、クロスシステムテストの内部経験の存在でした。2017年に、M.Videoブランドの連邦広告キャンペーンをサポートするために、新しいエンドツーエンドのテスト手法の実装を開始しました。「お値段」「テレビを買うとプレゼントがもらえる」など、さまざまなプロモーションを行っています。
このようなプロモーションは、特別価格、キット内のギフトの存在、およびギフトの発行を意味します。プロモーションは同時に開催され、特定の購入で相互に結合または除外されます。
しかし、集荷の過程で、たとえば、販促品の購入は1つのシステムで行われ、コールセンターの従業員の作業は別のシステムで行われ、商品の受け取りは3番目のシステムで行われました。その結果、テレビがプレゼントなしで放置されたり、レシートに別のアイテムが追加されたりすると、メインポジションのプロモーション価格がキャンセルされました。明らかに、システムの更新は何かを壊す可能性があり、連邦プロモーションの開始前にプロモーションのエンドツーエンドのテストに特に従事する小さなチームを作成しました。
約1年後、このチームは効率的な作業プロセスを構築し、連邦政府の昇進のエラーやトラブルのない運用に取り組みました。そして追加のボーナスとして、ビジネスは開始された広告キャンペーンの技術的な実現可能性と有効性に関するフィードバックとレポートを受け取り始めました。
会社が他のプロジェクトで本格的なシステム間テストプロセスを必要としていることに気付いたとき、この経験は非常に有益であることがわかりました。M.VideoとEldoradoが統合された時点では、新しいタイプのテストの必要性が特に明確でした。複雑でボリュームのある変更の数が増え、2つのブランドのプロジェクトを同時に実行する必要が生じ、1つの変更に含まれる製品とバックオフィスシステムの数が20を超えました。
新しいアプローチの利点
現在、クロスシステムテスト部門は3人のテストマネージャーと6人のテスターを雇用しており、将来的にはM.Video-Eldoradoのクロスシステムテストに約40人を恒久的に雇用する予定です。
私たちの部門の仕事は、会社のプロセスと製品で開始された変更の本番環境にリリースする前に、機能テストと統合テストでは気付かなかった可能性のあるバグをキャッチして、エンドツーエンドのテストを実行することです。この部門は、各コンポーネントの更新が内部プロセスと外部プロセスに与える影響を評価します。このために、テストを準備して実行するための統一された方法論と、各開発チームの内部テスターと対話するためのルールが開発されました。
2021年半ばまでに、M.Video-Eldoradoはすでに100以上の製品とバックオフィスシステム/サービスをサポートしており、それに応じて100以上のチームが開発に取り組んでいます。毎週、ますます多くのソフトウェアコンポーネントがあり（結局のところ、私たちはマイクロサービスの時代に生きています）、変更はほぼ継続的です。同社は、一度に数十のシステムに影響を与える5〜6の大規模プロジェクトを常に実行しています。
このような状況では、サービスの相互作用のタイムリーなチェックを確立し、互換性のない更新が製品に入るのを防ぐことができるため、継続的なシステム間テストのプロセスが必要になります。
特定の指標について話すと、次のことができます。
- , -, - end2end 2 ;
- 15%;
- 20%;
- end2end 10%;
- 50%;
- , -, Jira
パイロットプロジェクトをどのように実施し、どのビジネスプロセスでテスト方法論を作成したかについての話は、別のテキストに値します。したがって、次の投稿では、ユビキタスクロスシステムテストへの道について説明するとともに、私たち自身の経験から開発した、社内でのend2endテストの実装を成功させるための既存の方法論と基準を共有します。
PS私たちのチームにはいくつかの興味深い欠員があります 。ようこそ！