学校に戻る: 自動テストに対処できるように手動テスターをトレーニングする方法

QA 応募者の XNUMX 人中 XNUMX 人は、自動テストの操作方法を学びたいと考えています。 すべての企業が勤務時間中に手動テスト担当者のそのような要望を満​​たせるわけではありません。 Wrike は従業員向けにオートメーション スクールを開催し、多くの従業員のこの願望を実現しました。 私はまさにQAの学生としてこのスクールに参加しました。

私は Selenium の使い方を学び、現在では実質的に外部からの助けを借りずに、一定数の自動テストを独自にサポートしています。 そして、私たちの共同経験の結果と私の個人的な結論に基づいて、最も理想的な自動化の流派の公式を導き出そうとします。

学校運営における Wrike の経験

オートメーション スクールの必要性が明らかになったとき、その組織はオートメーションの技術責任者である Stas Davydov に委ねられました。 彼らがなぜこの取り組みを思いついたのか、成果を上げたかどうか、費やした時間を後悔しているかどうかを説明できるのは彼以外に誰でしょうか？ 彼に発言権を与えましょう:

— 2016 年に、私たちは自動テスト用の新しいフレームワークを作成し、テストを簡単に作成できるようにしました。通常のステップが表示され、構造がより理解しやすくなりました。 私たちは、新しいテストを作成したい人全員を参加させる必要があるというアイデアを思いつきました。それを理解しやすくするために、一連の講義を作成しました。 私たちは共同でトピックの計画を立て、将来の講師がそれぞれ自分でトピックを取り上げ、それに関するレポートを作成しました。

—学生たちはどんな苦労をしましたか？

—もちろん主に建築です。 テストの構造について多くの質問がありました。 フィードバックでは、このトピックに関して多くのことが書かれており、より詳細に説明するために追加の講義を開催する必要がありました。

—学校の成果はありましたか？

- はい、間違いなく。 彼女のおかげで、多くの人がテストの作成に携わるようになり、平均して、病院内では誰もが自動テストとは何なのか、どのように作成され、どのように起動されるのかをよりよく理解できるようになりました。 自動化エンジニアの負担も軽減されました。テスト担当者と開発者がほぼすべての状況で自分たちでテスト分析に対処し始めたため、テスト分析に関する支援を求めるリクエストが何倍も減りました。 そうですね、部門にとってはいくつかの内部利点があります。プレゼンテーションや講義の経験が増えました。そのおかげで、一部の自動化エンジニアはすでにカンファレンスでプレゼンテーションを行うことができました。また、新人研修のための強力なビデオやプレゼンテーションのセットも受け取りました。

私自身を代表して付け加えさせていただきますが、私たちの部門間のコミュニケーションは、まったくばかばかしいほど簡単なレベルまで簡素化されました。 たとえば、現在では、どのケースをどの原子性のレベルで自動化するかを考える必要がなくなりました。 その結果、関係者全員がテスト範囲に最大限の注意を払っており、テスト範囲は常に拡大しています。 他人に不可能なことを要求する人はいません。

一般に、チームの仕事への影響は間違いなくプラスです。 おそらくこの記事を読んでいる同僚も同様のことを考えているのではないでしょうか? その場合のアドバイスはシンプルです。自動テストが優先事項である場合は、そうする価値があります。 次に、より複雑な問題について説明します。それは、すべての関係者のコストを最小限に抑え、成果を最大化するために、これらすべてをできるだけ正確に組織する方法です。

整理のヒント

この学校は役に立ちましたが、スタス氏が認めたように、いくつかの困難があったため、追加の講義を手配する必要がありました。 そして、最近の学生として、無知な自分と現在の自分を比較しながら、私の意見では、自動テストの理解をテスターに​​教えるための理想的な方法を作成するための次の手順を策定しました。

ステップ 0. 辞書を作成する

もちろん、このステップは QA だけに必要なわけではありません。 ただし、ここで明示しておきたいのは、自動化コードベースは読み取り可能な形式に保たれなければならないということです。 プログラミング言語 - 特に 言語, ここからダイビングを開始できます。

以下は、要素の名前を含むタスクビューのスクリーンショットです。 あなたがタスクビューをブラック ボックスとしてテストしていて、これまで Selenium を見たことがなかったと想像してください。 このコードは何をするのでしょうか?

(スポイラー - タスクは管理者に代わって REST 経由で削除され、ストリームにこれの記録があることがわかります。)

このステップだけで、QAA 言語と QA 言語がより緊密に連携します。 自動化チームは実行結果を説明するのが容易になり、手動テスターはケースの作成に費やす労力が減り、ケースの詳細を少なくすることができます。 それでも、みんなはお互いを理解し合っています。 実際のトレーニングが始まる前から賞金を受け取りました。

ステップ 1. フレーズを繰り返す

言語との並行作業を続けましょう。 子供の頃に話すことを学ぶとき、私たちは語源や意味論から始めません。 私たちは「お母さん」「おもちゃを買って」と繰り返しますが、これらの言葉のインド・ヨーロッパ祖語のルーツにはすぐには立ち入りません。 それはここにあります。機能するものを作成しようとせずに、自動テストの技術的機能の奥深くまで掘り下げても意味がありません。
少し直観に反して聞こえるかもしれませんが、うまくいきます。

最初のレッスンでは、自動テストを直接記述する方法の基礎を説明する価値があります。 私たちは開発環境 (私の場合は Intellij IDEA) のセットアップを支援し、既存の手順を使用して既存のクラスに別のメソッドを記述するために必要な最小限の言語ルールを説明します。 私たちは彼らと一緒に XNUMX つまたは XNUMX つのテストを作成し、宿題を出します。私なら次のようにフォーマットします。マスターから分岐したブランチですが、そこからいくつかのテストが削除されています。 それらの説明だけが残っています。 私たちはテスターに​​これらのテストを復元するよう求めています (もちろん、show diff ではありません)。

その結果、耳を傾けてすべてを実行した人は、次のことができるようになります。

1. 開発環境インターフェイスの操作方法を学びます。ブランチ、ホットキー、コミット、プッシュを作成します。
2. 言語とクラスの構造の基本をマスターします。ステップ以外に、インジェクションを挿入する場所とインポートする場所、アノテーションが必要な理由、そこにあるシンボルの種類などです。
3. アクション、待機、チェックの違い、どこで何を使用するかを理解する。
4. 自動テストと手動チェックの違いに注意してください。自動テストでは、インターフェイスを通じてアクションを実行する代わりに、XNUMX つまたは別のハンドラーをプルできます。 たとえば、タスクビューを開いて入力を選択し、テキストを入力して [送信] ボタンをクリックする代わりに、コメントをバックエンドに直接送信します。
5. 次のステップで回答される質問を作成します。

最後の点は非常に重要です。 こうした答えは事前に簡単に与えることができますが、質問が明確にされていない答えは記憶に残らず、最終的に必要になったときにも使用されないということが重要な指導原則です。

この時点で、QA チームの自動化エンジニアが彼に戦闘でいくつかのテストを作成するタスクを割り当て、ブランチにサブコミットできるようにするのが理想的です。

与えてはいけないもの:

1. 開発環境の機能とプログラミング言語自体についてのより深い知識。ブランチを独立して操作する場合にのみ必要となります。 二度も三度も説明しなければならないため、覚えられませんが、私たちは自動化エンジニアの時間を大切にしています。 例: 競合の解決、git へのファイルの追加、クラスを最初から作成、依存関係の操作。
2. xpath に関連するすべて。 真剣に。 それについては、一度、非常に集中して個別に話す必要があります。

ステップ 2. 文法を詳しく見てみる

ステップ #0 のタスクビューのスクリーンショットを思い出してください。 checkCommentWithTextExists というステップがあります。 テスターはこのステップが何を行うかをすでに理解しているので、ステップ内を調べて少し分解することができます。

そして内部には次のものがあります:

onCommentBlock(userName).comment(expectedText).should(displayed());

onCommentBlock の場所

onCommonStreamPanel().commentBlock(userName);

今、私たちは「おもちゃを買う」ではなく、「上から XNUMX 番目の棚の青いキャビネットにある Detsky Mir ストアでおもちゃを買う」と言うようになりました。 大きな要素から順に要素を指定していることを説明する必要があります (ストリーム -> 特定の人からのコメントが含まれるブロック -> 指定されたテキストが存在するこのブロックの部分)。

いいえ、まだ xpath について話す時期ではありません。 これらすべての命令はそれらによって記述され、継承はそれらを介して行われることを簡単に述べてください。 しかし、これらすべてのマッチャーとウェイターについて説明する必要があります。これらは特にこのステップに関連しており、何が起こっているのかを理解するために必要です。 ただし、負荷をかけすぎないでください。生徒は後で、より複雑なアサーションを自分で学習できます。 おそらく、 should 、 waitUntil 、displayed(); 、exist(); 、not(); で十分でしょう。

宿題は明らかです。一定数のテストに必要ないくつかのステップの内容が削除されたブランチです。 テスターに​​それらを復元させて、実行を再びグリーンに戻してもらいます。

さらに、テスト チームの作業に新機能だけでなくバグ修正も含まれている場合は、それらのバグに対するテストをすぐに作成してリリースするようにチームに依頼できます。 おそらく、すべての要素はすでに説明されており、いくつかのステップが欠けているだけかもしれません。 これは完璧なトレーニングになります。

ステップ 3. 完全な浸漬

引き続き直接の職務を遂行するテスターのために、可能な限り完全なものを提供します。 最後に、xpath について説明する必要があります。

まず、これらすべての onCommentBlock とコメントがそれらによって記述されていることを明確にしましょう。

合計：

"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"

話の順序は非常に重要です。 まず、既存の xpath を取得し、要素タブに要素が XNUMX つだけ含まれる様子を示します。 次に、WebElement を使用する必要がある場合と、新しい要素用に別のファイルを作成する必要がある場合の構造について説明します。 これにより、継承についてより深く理解できるようになります。

単一の要素がタスクビュー全体であること、子要素が含まれること、子要素を含むストリーム全体、別のコメントなどが含まれていることを明示的に記述する必要があります。 子要素は、ページ上と自動テスト フレームワークの構造の両方の親要素内にあります。

この時点で、聴衆は、それらがどのように継承されるのか、そして onCommentBlock のドットの後に何を入力できるのかをしっかりと理解したはずです。 この時点で、/、//、.、[] などのすべての演算子について説明します。 使用に関する知識を負荷に追加します @class その他必要なもの。

学生は、この方法で xpath を変換する方法を理解する必要があります。 統合するには、そうです、宿題です。 要素の説明を削除し、テストの動作を復元させます。

なぜこの特定のパスなのか?

複雑な知識を人に与えすぎないようにする必要がありますが、一度にすべてを説明しなければならないため、これは難しいジレンマです。 この方法により、まず聞き手に何か分からないことを質問させ、次の瞬間にそれに答えることができます。 アーキテクチャ全体について話す場合、ステップや xpath のトピックが分析されるまでに、その最も重要な部分は理解できないため、すでに忘れられているでしょう。

ただし、プロセスをさらに最適化する方法についての経験を共有できる人もいるでしょう。 コメントで同様の提案を喜んで読みます。

出所： habr.com