私の名前はMariaSnopokです。X5RetailGroupのBigDataProductsの開発およびサポート部門のテスト部門の自動化ディレクションのマネージャーです。この記事では、自動テストの実装と関連コストの削減に関する経験を共有します。この情報が、自動テストへの移行に苦労しているチームに役立つことを願っています。
自動テストに来た経緯
自動化が登場する前は、当社の製品の1つでテストマネージャーとして働いていました。そこでかなり大きなテストモデルが形成されたとき、私たちは回帰テストのプールを開発チーム全体に配布し始めました-彼女がリリースを担当している場合、彼女もテストを行っています。このようなチーム回帰は、次のタスクを解決しました。
- 以前に個別の機能を扱っていた開発者は、製品全体を見ることができました。
- これにより、回帰が速くなり、リリースが頻繁になりました。
- リコースを減らすことはもうありませんでした。品質が向上しました。
しかし、テストは高価なスペシャリスト（開発者やアナリスト）によって実行されたため、コストがかかり、自動化に移行し始めました。
煙のテストが最初に行われました-ページが開いて読み込まれ、クラッシュしないこと、およびすべての基本機能が利用可能であることを確認するための簡単なチェック（これまでのところロジックと値をチェックしていません）。
次に、ポジティブエンドツーエンドスクリプトを自動化しました。このステップは最大のメリットをもたらしました。テストにより、ネガティブ、代替、および二次的なシナリオでミスがあった場合でも、製品の主要なビジネスプロセスが機能していることを確認できました。
そして最後に、高度な回帰チェックと代替シナリオの自動化に取り掛かりました。
これらの各段階で、私たちは深刻な速度低下とプロセス全体の複雑化をもたらす多くの困難に直面しました。オートマトンの作業をスピードアップして促進するのに役立った実用的なソリューションは何ですか？
自動テストのコストを削減する4つの方法
1.海岸でのテスト属性の形式について合意する
開発者と自動テスターは、自動テストでロケーターとして後で使用するためにHTML要素に名前を付けるためのルールについて事前に合意する必要があります。すべての製品で同じ形式であることが望ましいです。機能が開発に移される前であっても、属性に名前を付ける方法を理解するための要件を作成しました。この理解は、開発者側とテスター側の両方に存在します。表示されている各html要素にカスタムdata-qa属性が割り当てられ、それによってテスターがそれを検索することに同意しました。属性には、次のパターンに従って名前が付けられます。
[画面名] [フォーム/テーブル/ウィジェット名] [要素名]
例：
data-qa = "plu-list_filter-popover_search-input"
data-qa = "common_toolbar_prev-state"
このような属性は、ドキュメントやレイアウトから簡単に分離でき、誰もがその意味を知っています。開発者がタスクを実行すると、これらのルールに従って、表示されているすべてのページ要素（ヘッダー、ボタン、リンク、セレクター、テーブルの行と列など）にdata-qa属性を割り当てます。その結果、テスターは、機能の開発中でも、に基づいて自動テストの作成を開始できます。属性の命名方法をすでに知っているため、レイアウトとドキュメントのみに適用されます。
テスト属性の導入により、テストの更新と自動テストの要素のローカライズのコストを削減することで、自動テストの開発とサポートのコストを前の期間と比較して平均23％削減することができました。
2.自動化が容易になるように手動テストを作成します
手動テスターと自動化エンジニアは、さまざまな世界に住んでいます。手動のものは、1つのスクリプトでいくつかの異なる近くのテストオブジェクトをチェックすることを目的としています。一方、オートメータは、すべてを構造化し、1回のテストで同じタイプのオブジェクトのみをチェックする傾向があります。このため、手動テストは必ずしも自動化が容易ではありません。自動化のための手動のケースを受け取ったとき、それらは生きている人が簡単に実行できるように書かれているため、結果のスクリプトを一語一語自動化できない多くの問題に直面しました。
オートマトンが製品に深く没頭している場合、「手動」のケースは必要ありません。自動化用のスクリプトを自分で作成できます。彼が「外部から」製品に来て（私たちの部門では、テスターに加えて、チームも専用サービスとしてテストを行っています）、手動テスターによって準備されたテストモデルとスクリプトがすでにある場合は、自動テストを作成するように彼に指示したくなるかもしれません。これらの「手動」テストケースの基礎。
これに屈しないでください。オートマトンが手動のテストケースを使用できる最大値は、ユーザーの観点からシステムがどのように機能するかを理解することだけです。
したがって、自動化できるように、また一般的な問題に対処するために、最初に手動テストを準備する必要があります。
問題1： 手動の場合を単純化する。
解決策：ケースの詳細。
手動ケースの説明を想像してみましょう。
- リビジョンバージョンリストページを開く
- 作成ボタンをクリックします
- フォームに記入する
- 「作成」ボタンをクリックします
- リビジョンバージョンが作成されていることを確認してください
これは自動化にとって悪いシナリオです。何を正確に開く必要があるか、どのデータを入力するか、何を正確に表示するか、どのフィールドで表示するかが指定されていないためです。 「バージョンが正常に作成されたことを確認する」という手順は、自動化には不十分です。マシンには、アクションが成功したことを確認するための特定の基準が必要です。
問題2：ケースの分岐。
解決策：ケースには線形シナリオのみが必要です。
「または」が付いた構造は、ハンドヘルドの場合によく見られます。例：「ユーザー1または2でリビジョン184を開く」。これは自動化には受け入れられないため、ユーザーを明確に示す必要があります。 「または」の結合は避けてください。
問題3：ケースの無関係。
解決策：ケースを自動化に送信する前にチェックしてください。
これは私たちにとって最大の問題です。機能が頻繁に変更されると、テスターはテストケースを更新する時間がありません。しかし、手動テスターが無関係なケースに遭遇した場合、彼がスクリプトをすばやく修正することは難しくありません。オートマトンは、特に製品に没頭していない場合、これを行うことができません。ケースが適切に機能していない理由を理解できず、テストバグとして認識します。開発に多くの時間を費やします。その後、テストされた機能が長い間カットされており、スクリプトは無関係であることが判明します。したがって、自動化用のすべてのスクリプトの関連性を確認する必要があります。
問題4：十分な前提条件がありません。
決定：ケース実行用の補助データのフルスタック。
手動テスターはぼやけてしまい、その結果、前提条件を説明するときに、彼らには明らかであるが、製品にあまり精通していないオートマトンには明らかではないいくつかのニュアンスを見逃します。たとえば、「計算されたコンテンツでページを開く」と書いています。彼らは、このコンテンツを計算するには、計算スクリプトを実行する必要があることを知っています。プロジェクトを初めて見たオートマトンは、すでに計算されたものを取得する必要があると判断します。
結論：前提条件では、テストを開始する前に実行する必要のあるアクションの完全なリストを作成する必要があります。
問題5：1つのシナリオでの複数のチェック。
決定：シナリオごとに3つ以下のチェック（コストがかかり、再現が難しいシナリオを除く）。
手動テスターは、特に重い場合にケースの費用を節約し、1つのシナリオで可能な限りテストし、12個のテストを詰め込みたいと考えることがよくあります。手動テストと自動テストの両方で、このアプローチは同じ問題を生成するため、これは許可されるべきではありません。最初のテストが失敗し、自動化の場合、残りはすべて合格しないか、まったく開始されないと見なされます。したがって、自動テストスクリプトでは、1〜3回のチェックが許可されます。例外は、時間のかかる事前計算を必要とする非常に難しいシナリオであり、再現が難しいシナリオでもあります。ここでルールを妥協することができますが、そうしない方が良いです。
問題6：チェックが重複しています。
解決策：同じ機能を何度も自動化する必要はありません。
たとえば、標準フィルターなど、複数のページで同じ機能がある場合、回帰テスト中にどこでもそれをチェックすることは意味がありません。1つの場所を調べるだけで十分です（もちろん、新しい機能について話している場合を除きます）。手動テスターは、スクリプトを作成し、すべてのページでこの種のことをテストします。これは、ページの内部の仕組みに触れることなく、各ページを個別に確認するためです。しかし、オートマトンは、同じことを繰り返しテストすることは時間とリソースの無駄であり、そのような状況を検出するのは非常に簡単であることを理解する必要があります。
上記の問題を解決することで、自動テストの開発コストを16％削減することができました。
3.「テーブル上」でテストを記述しないように、リファクタリング、再設計、機能の大幅な変更の問題に関する製品チームとの同期
13の製品が開発されているビッグデータ部門には、2つのグループのオートマトンがあります。
- 製品チームのオートマトン。
- 製品チーム外の自動化ストリームサービス。フレームワークと共通コンポーネントの開発に従事し、既製の機能テストを使用して製品からの要求に対応します。
ストリームオートマトンは、最初は製品にそれほど深く関わっていません。また、毎日のチームミーティングに参加する前は、時間がかかりすぎるためです。このアプローチで失望した場合、サードパーティのソースから、あるチームが製品をリファクタリングする（モノリスをマイクロサービスに分割する）ことを誤って知りました。そのため、作成したテストの一部がアーカイブに送信されます。とても辛かったです。
将来これが起こらないようにするために、少なくとも週に1回、ストリームからのオートマトンが開発チームの会議に来て、製品で何が起こっているかを把握することが決定されました。
また、テストは、本番環境の準備ができており、頻繁な変更（リグレッション）を受けない機能に対してのみ自動化されることに同意しました。少なくとも今後3か月以内に、リファクタリングや大規模なリワークが発生しないことを確認する必要があります。そうしないと、オートマトンにテストの時間がないだけです。
これらの対策の実施によるコスト削減は、計算がより困難です。機能の一部をマイクロサービスに移行する計画があったために価値を失った自動テストを基礎として開発するために時間をかけました。この移行について事前に知っていれば、自動テストで可変機能をカバーすることはできません。総損失（潜在的な節約とも呼ばれます）は7％です。
4.手動テスターを自動化エンジニアにアップグレードする
労働市場にはテストオートマトン、特に優れたものはほとんどなく、私たちは積極的にそれらを探しています。また、自動化の基本的な知識を持っている既存の手動テスターを積極的にアップグレードしています。まず、本格的なオートマターと本格的な自動テストが必要であり、レコーダーからはメリットよりもデメリットの方が多いので、プログラミング言語のコースにそのような人を送ります。
プログラミング言語の学習と並行して、ポイント2から問題なく正しい構造化されたスクリプトを作成し、自動テストレポートの結果を読み取って分析し、ロケーターの小さなエラーを修正し、簡単な方法を実行し、既成のテストを維持してから、独自のテストを作成する方法を学びます。すべての開発は、ストリームサービスの経験豊富な同僚のサポートを受けて行われます。将来的には、フレームワークの完成に参加できるようになります。すべてのプロジェクトに対応できる独自のライブラリがあり、独自のライブラリを追加することで改善できます。
このコスト削減の方向性はまだ始まったばかりであるため、節約額を計算するには時期尚早ですが、人材育成が運用コストの大幅な削減に役立つと考える理由は十分にあります。同時に、手動テスターに開発の機会を提供します。
結果
これで、5つの製品のテストの約30％が自動化され、回帰テスト時間が2分の1に短縮されました。
時間は私たちにとって非常に重要であるため、これは良い結果です。無期限にテストすることはできず、検証なしで製品を譲渡することもできません。一方、自動化により、必要な量の製品チェックを最適なタイミングで提供できます。将来的には、リリースをできるだけ頻繁にリリースするために、自動テストの割合を80〜90％に増やす予定ですが、同時に、手動テストの方が収益性が高い自動テストのあるプロジェクトはカバーしません。