BDD方法論に従った自動化。 成功した実装の経験

この記事は、Vadim Trubanov、 @ vonaburtを代表して公開されてい ます



BDD方法論は、テスト自動化へのアプローチを含む、プロジェクトテストへの従来のアプローチの開発における論理的なステップとして、IT業界の注目を集めています。 情報技術の現在の時代は独自のルールを規定しており、この技術競争では、あらゆる変化に迅速かつ効率的に対応する方法を知っている人が勝ちます。 これは、たとえば、銀行などの銀行業務に関連する企業に特に当てはまります。たとえば、銀行は、リリースまでの1時間ごとに、顧客が作成したサービスの品質の全体像に影響を与える可能性があります。 BDD方法論を正しく使用すると、製品のテストに費やされる時間を短縮し、テストの品質を向上させ、プロセスをすべての人にとって透明で理解しやすくすることができたため、使用を促されました。 現在、BDD方法論は2つのWeb製品に実装されており、積極的に開発されており、すでに成果を上げています。 テストの自動化の一環としてBDDを実装した経験を共有し、この方法論を簡単に、迅速に、そして最も重要なことに、その使用を効果的にするための基本原則についてお話したいと思います。

1.適切で便利なフレームワークを構築する

BDDケースが後で記述されるフレームワークは、方法論全体の中心であり、その主要な要素です。 そのため、フレームワークの注目度を高める必要があります。 これがあなたの出発点です。 私たちのソリューションはJavaで記述されており、jBehaveライブラリに基づいています。 BDDはWebプロジェクトで使用されるので、Selenium WebDriverはどこにもありません。 PageObjectパターンを使用する場合、要素とページの操作に大きな役割が与えられます。 セレニティがレポートジェネレータとして選択されます。 フレームワークが順守しなければならない3つの明白な主な原則を挙げます。 まず、 信頼できるものでなければなりません。 時間をかけて、プロジェクトの中核を書きましょう。 30分の作業を費やすと、BDDチームのダウンタイムが数時間になります。 第二に、フレームワークは可能な限り使いやすくする必要があります 。 フレームワークの主なユーザーはあなたではなく、自動化チームでもありません！ このフレームワークは、BDDケースを作成しようとする人にとって友好的で、快適で、理解しやすいものでなければなりません。 第三に、フレームワークは柔軟でなければなりません。 急速な変化への対応に戻ると、あなたは理解しています-テストされたプロジェクトが明日どのように変化するかはわかりません。 最初に、フレームワークの基本的なメカニズムを常に再構築できるように、BDDフレームワークを構築します。









優れたBDD自動化フレームワークは、次の概念に関連付けられています。

• BDDケースを作成するためのメカニズム。
• BDDケースを起動するメカニズム。
• テストデータを操作します。

これら3つの項目はすべて、フレームワークのユーザーにとってできるだけ便利なものでなければなりません。 ユーザーは開発者ではないことを忘れないでください。開発者であるあなたにとって明らかなことは、彼らにとって明らかでないかもしれません。



BDDケースを記述するメカニズムは非常に単純です。 IDEA Intellij CEはフレームワークのユーザーごとにインストールされ、プラグインがインストールされます。これにより、ユーザーは既存のBDD命令を自動完了できます。 ほとんどすべての命令には独自のエイリアスがあり、ユーザーは自分のケースを好きなように書くことができます。









ほとんどの命令にはパラメーターがあります：ページの名前、要素、以前に保存された値、関数。 それらはすべて、ケースを柔軟かつ効率的にすることができます。



エレメント、そのロケーター、エレメントのコレクション、エレメントを含むページの操作をより便利で透明にする方法を疑問に思っている人は多いでしょう。 ページとその要素の完全な階層の説明に決めました。 このアプローチは、プロジェクトでPageObjectパターンを使用したすべての人に馴染みがあるはずです。 ポータル全体はページに分割されており、ページ内にはそれらに配置されているすべての要素が説明されています。 重複するページブロックは、たとえば「メニュー」や「右のボード」などの「ウィジェット」または「サブページ」に配置されます。 現在、銀行のメインポータルの要素の2200以上のロケーターと法人のポータルの1000以上の要素を保存しています。これらの数は、新しい機能のリリースとともに絶えず増加しています。 方法論に関与する自動化機能と機能テスターは、疑問に思っています。多くの要素をどのように扱うのでしょうか？ 解決策が見つかりました。IDEAIntellij用の独自のプラグインを作成します。これにより、データファイルがツリー構造に解析され、新しいページと要素を追加および編集できるようになります。









指示は、特定のページを「ダウンロード」した後、ユーザーがロードされたページのすべての要素を操作できるように構成されています。 このおかげで、私たちのフレームワークのユーザーは、必要な要素、ページまたはウィジェットの選択との混乱を避けています。



BDD命令の機能を強化するために、次の機能を実装しました。

• 命令の本体と「Meta」ブロックの変数の両方で、独自の小さな補助スクリプトを作成する機能（ランダム値の取得、数学演算など）。
• 変数に必要な値を保存し、これらの変数を使用する機能。

<!--         > Meta: @profile #{AutoPayments} @region .  @code 916 @phone #{random{1000000,9999999}} @sum #{random{100,200}} @sum2 #{random{100,200}} @level 150 @level2 600 @limit #{random{650,999}} @limit2 #{random{650,999}} @dateStamp #{now(ddMMyy HHmmss)} @preName EditMAP <!--   > When   "name"   "#{script{ String temp = "#{preName}" + " " + "#{dateStamp}"; RESULT = temp}}" <!--   > When    ""   "" When  : |field|value| |    |#{code} #{phone}| | |#{name}| ||#{sum}| |  |#{level}| | |#{limit}|
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BDDケースの起動は、Apache Mavenおよび修正された標準StoryRunnerを使用して実装されます。これにより、マルチスレッドモードでBDDケースを実行できます。 機能主義者は、作業マシンから必要なテストを直接実行し、テストの進行状況を表示できます。 すべての自動テストは、TeamCityを介して手動で実行されます-非常にまれです。









テストと自動テストは、テストデータ（TD）と密接に関連しています。 これは、品質保証プロセスの基本的な柱の1つです。 高品質のテストデータとその適切な使用は、テストを新しいレベルに引き上げます。 BDDの指示に戻ると、BDDフレームワークのユーザーはテストデータを送信します。 指示にテストデータを直接ハードコードします。マナーが悪いため、APの更新が困難になります。 その結果、次のタスクに直面しました。



-単一の場所でAPのストレージを取り出します。

-BDD命令で保存されたAPとの便利な作業の可能性を実現します。

-APの便利な更新とそれらの制御の可能性を実現します。



決定方法：



-データベースに入力されたすべてのテストデータ。

-データベース内のデータを操作できる内部テストAPIを実装しました。

-命令の形式でBDDフレームワーク内のテストAPIを操作するメカニズムを実装しました。

-フレームワークのユーザーに、テストデータの更新、更新、および編集を直接行うためのインターフェイスを提供するWebポータルを作成しました。









テストデータを操作するためのWebポータルは、SkalovのPlayで作成され、BDD自動化を使用するWebプロジェクトに分割されています。 また、テストデータのカテゴリ（フィールド、値、正しい/正しくない検証のパラメーター、テストユーザー）の内部区分もあります。









テストユーザーは、 テストデータ生成メカニズムが実装されているため補充されます。詳細については、おそらく別の記事になります。 このメカニズムにより、任意の製品セットおよび必要なパラメーターを使用してクライアントでテストできます。



これはまさに、私たちの意見では、便利で効果的なBDDフレームワークの必要な技術要素の簡単な説明のように見えます。 簡単に要約すると、BDDフレームワークの作成者、ページ要素の操作方法、ユーザーが指示やテストデータと対話する方法を忘れないでください。



おそらく、別の記事でフレームワークについて詳しく説明します。

2.従業員の環境を設定する

フレームワークが作成されたか、作成の最終段階になったら、BDDフレームワークのユーザーがフレームワークをどのように使用するかを考えます。 ソフトウェアとネットワークアクセスをインストールするために必要な権利を付与することは、多くの大企業で漠然とした将来を伴う壮大なものになる可能性があります。 幸いなことに、当社の官僚的な遅延は最小限に抑えられており、将来のBDD自動化装置の選択されたグループに必要なすべてのソフトウェアを迅速にインストールすることができました。 もちろん、特定の問題が発生することもありましたが、すぐに解決されました。 スタッフ/アウトソーシングの同僚にとって、必要な「戦闘セット」を備えた事前に準備された仮想マシンの形で、シンプルで効果的なソリューションが見つかりました。 問題が発生した場合は、いつでも仮想マシンにアクセスして問題を確認できます。









この短いが非常に重要な章の教訓：BDDフレームワークの将来のユーザーがそれをどのように使用するか、ローカルマシンに必要なソフトウェアを完全にインストールする場合でも、フレームワークを使用して仮想マシンを事前に構成してコピーする場合でも、事前に注意してください。 同僚がフレームワークの使用を迅速に開始するほど、待望のフィードバックを迅速に受け取ることができます。これは、BDD自動化の開発の開始時に特に役立ちます。

3.ワークフローを構築します。 方法論を使用するためのオプション

適切に編成されたワークフローがなければ、BDD方法論を使用した自動化が有益であるとは考えられません。 ここでは、この方法論の使用をプロジェクトに組み込む方法について説明する価値があります。 オプションは非常に柔軟で、目的の製品の開発プロセスにすべての参加者をどの程度関与させるかによって異なります。 おそらくこれは、テスターと自動化エンジニアのみが関与する最初の不完全なオプションになるでしょう。 この場合、自動化テストケースの形で自動化エンジニアと機能テスターの間の「レイヤー」を削除することで時間を節約できます。









アナリストを含むプロダクトマネージャーは、このプロセスに間接的に参加することもできます。これは、どの機能に特別な注意が必要かを示し、機能のビジネス上の重要性の観点からまず自動化されます。



次のユースケースはいっぱいです。 このオプションには、開発プロセスのすべての参加者（製品マネージャーからテスター、オートマトンまで）のBDD方法論への完全な参加が含まれます。 この開発段階またはその開発段階の各参加者は、最終的なBDDケースの形成に参加します。これにより、合計で本格的な自動製品回帰が行われます。 また、このオプションを使用すると、製品の「受け入れ」のすべての基準がテスターだけでなく、よくある開発プロセスのすべての参加者によって形成される場合、本格的な受け入れテスト（ATDD）にスムーズにつながります。 このアプローチは、自動化の観点から最も有用で効果的であり、最終的な自己回帰を迅速かつ非常に高品質に補充します。









方法論に機能テスターと自動化エンジニアのみが関与する最初の不完全なバージョンから開始しました。これは主に、方法論の長所と短所を実際に示す実験の形で行われました。 テストへのこのアプローチは実を結び、すべての開発参加者を方法論に引き付ける方法について考え始めました。 {x} DDのクラシックバージョンは、すべてのテストが最初に記述され、その後直接開発が開始されると、初期状態でのクイックリリースサイクルに大きく影響します。これは、銀行サービスにとって容認できない贅沢です。 さらに、開発段階のすべての参加者がBDDフレームワークを操作するためのトレーニングは言うまでもなく、BDD自動化に必要なすべてのソフトウェアのインストール、構成、およびサポートにより、方法論のさらなる開発が大幅に遅くなります。 ソリューションは、BDD方法論の「ルーツ」にありました。 この方法論は、ビジネス状況（動作シナリオ、ユーザーストーリー）を使用して機能を記述するシステムの動作を記述するための人間が読める言語であるDSL言語（ガーキン）の使用に基づいていることを思い出させてください。 シンプルなスクリプトルールのおかげで、多数の従業員をGherkin言語の形式のタスクとその後の改良にすばやく引き付けることができます。 プロセス全体は、使用しているプロジェクト管理およびバグ追跡ソフトウェアのフレームワーク内で実行されます。この場合、Atlassian Jiraです。 マネージャーとアナリストは、古いタスク設定形式から離れ、BDD形式でタスクを設定し始めています。 デザイナーと開発者はBDD形式でタスクの説明を受け取りますが、開発中に使用されるインターフェイスまたはライブラリの機能に基づいて、ユーザーストーリーのリストに自分で追加できます。 その結果、タスクがテストに分類されると、テスターはユーザーストーリーのリストを確認し、それを分析して、テスターの位置に基づいてユーザーシナリオを補完します。 各ストーリーはテスト用の完全なスクリプトです。 これは製品のライブドキュメントです。 そして最も重要なことは、タスク記述からのすべてのシナリオがテスターに​​よってBDDフレームワークに迅速に転送され、実際に既製の自動テストになることです。









その結果、開発のすべての段階が製品受け入れ基準の準備に関与する場合、これは実質的にBDD方法論の完全受け入れテスト（ATDD）への移行です。



これは、実際のBDD方法論による自動化の説明です。 そして、下位レベルで何が起こるか、自己回帰補充プロセスはどのように構築されますか？ この質問に答えるには、BDDフレームワークの基礎に戻る必要があります。 ユーザーとBDDフレームワークとの対話のメカニズムは、指示に基づいています。 BDDフレームワークで使用可能な命令のリストと、説明されているページと要素のツリーにより、ほとんどのユーザースクリプトを自動化できます。 命令のリストと説明されているページと要素のツリーでは、特定のシナリオを常に自動化できるとは限らないと想定するのは論理的です。 特に、自動化されていない新しい機能のスクリプトを自動化する場合は、要素との相互作用のレベルで最小レベルの抽象化で可能な限りアトミックに構築されるという事実にもかかわらず。 さらに、要素とページの階層でまだ説明されていない新しいページとその新しい要素が表示される場合があります。 したがって、BDDケースが表示されますが、その自動化については、命令、ページ、およびそれらの要素が十分ではありません。 この状況により、テスターは「必要な指示がまだ利用できない場合はどうすればよいですか」というカテゴリーからfrom迷者になりました。 プロセスを構築する方法には2つのオプションがあります。 1つは、新しいBDDケースを作成せず、すべての指示が十分ではない、またはすべての要素が説明されていないことを自動化チームに通知することです。 ケースを自動化するのに十分であるかどうかをすぐに評価することは非常に困難です。 または、2番目の、より合理的なオプションは、指示、ページ、要素がないにもかかわらず、ユーザーが望むようにケースを書くことです。 テスターに指示を書く自由を与え、彼らに都合の良い方法でケースを書く機会を与え、指示や要素の説明が欠けているケースがJiraで自動化の「入力に行く」タスクを生成するようにプロセスを構築しました。 Automatorsは欠落している命令を実装し、欠落している要素とタスクを記述し、テスターの自動テストは自己回帰の作業ブランチに分類されます。









新しいBDDケースの品質を確保するために、強制的なコードレビューのプロセスが設定されています。 BDDケースのメインブロックがどのように見え、どのように設計されるべきかを記述する具体的なルールが策定されます。 これらのルールに従って、書面によるケースが機能テストの同僚によってチェックされます。 規則は、ケースの場所とその意味内容、必要なラベルの存在、その他の重要なポイントの対応に影響を与えます。 これらのルールがなければ、自己回帰補充プロセスは混oticとし、予測できません。 しかし、それについては記事の以下の部分で詳しく説明します。

4.別の役割

この部分は、前の部分の論理的な続きです。

これらのプロセスの参加者がこのプロセスにおける自分の位置を知らない場合、方法論、開発、生産、労働組織へのアプローチは非常に困難です。 人は自分の役割を知っていなければならず、この役割が引き受ける責任の最終的なリストを知っていなければなりません。 さらに、これらの責任がより詳細であるほど、プロセスの参加者と他のすべての人にとって、プロセスはより理解可能で透明になります。 これらの論文は、BDDのような複雑で時間のかかる方法論を通過しません。



方法論は非常に柔軟であり、多くの場合、多くの場合、自動化とテスターのみを方法論に引き付けます。 方法論を十分に活用するには、開発へのすべての参加者の関与が必要であり、これについて検討します。 それでは、BDD方法論の主な「アクター」は誰ですか？ もちろん、これらは機能テスターであり、FTとして指定します。 FTは、BDDケースを作成して自動化する「単なるテスター」と、略語「KR」で示す新しいBDDケースのコードレビューも行うテスターに​​分かれています。 これが自動化であり、これを「AT」と呼びます。 私たちは、指定された「AN」を使用して、プロセスの他のすべての参加者のアナリスト、マネージャー、および技術者を結び付けます。 「神のような」役割を「プロジェクトマネージャー」、または略してRPと呼びます。 これらはすべて、方法論の際立った役割です。



-「FT」（機能テスター）。

-「KR」（コードレビュアー）。

-「AT」（自動化）;

-「AN」（アナリスト、マネージャー、技術者など）。

-「RP」（プロジェクトマネージャー）。



次に、方法論で考えられる主なアクションについて説明します。 これは：



-ガーキン言語で自由形式でBDDケースを作成します。

-BDDフレームワークでのBDDケースの自動化。

-自動化されたBDDケースのコードレビュー、新しいBDDケースをコンパイルするための選択されたルールへの準拠の検証。

-欠落している指示の自動化、それらのサポート; 新しいページと要素の説明、それらのサポート;

-欠落している命令の自動化、それらのサポート、新しいページおよび要素の説明のコードレビューを実施します。



方法論の役割と可能なアクションの最終マトリックスを作成します。

アクション/役割	FT	KR	AT	AN	RP
GherkinでのBDDケースの作成	X	X	X	X	X
BDDフレームワークでのBDDケースの自動化	X	X	-	-	X
自動化されたBDDケースのコードレビュー	-	X	-	-	X
指示の自動化、要素およびページの説明など。	-	-	X	-	X
自動化のコードレビューを実行する	-	-	X	-	X

したがって、プロセス内のそれぞれがその役割と機能を実行します。



-管理者、アナリスト、技術者は、新しい機能をガーキン言語で便利な形式で説明します。

-機能テスターは、テストの観点から高品質のケースを作成し、それらを自動化し、作成したケース自体のコードレビューを実施しています。

-Automatorsは、純粋な自動化と関連する作業自動化でのみ忙しく、多くの場合そうであるように、ケースを記述しません。

5.従業員を訓練する

BDDケースは人間のような言語で作成され、自動化は特別に作成されたフレームワークで実行されるという事実にもかかわらず、方法論のすべての参加者に対して最小限のトレーニングに時間を費やす必要があります。 テスターから始めましょう。テスターなしでは、BDD方法論を想像することは非常に困難です。



このプロセスにおけるテスターの役割は、高品質のBDDケースを作成してBDDフレームワークで自動化すること、または非常によくあることですが、フレームワークで直接「その場で」自動化することです。 テスターは、BDDケースを適切に構成する方法、それが何で構成されているか、そして将来どのようにそれを扱うべきかを理解する必要があります。 これにはガーキン語の知識が必要です。 プレゼンテーションを行う会議で、または企業のwikiで自習用のトレーニング資料を使用するか、またはその両方で、情報を相手に伝えることができます。



フレームワークを使用するテスターのスキルは、練習することで最もよく得られます。 私たちの経験は、最も「学習タスク」が最も効果的であることを示しています。 これらは一般的なものです-自動化中にテスターが遭遇する可能性が最も高い-BDDが実装されているプロジェクトのタスク。 各タスクには実装の特定の期限が与えられ、その後、タスクの結果と新たに発生する問題について議論する集合ミーティングが開催されます。



管理者、アナリスト、技術者、およびBDDケースの作成にのみ関係する他の人のトレーニングは、ガーキン言語を教えることに帰着し、機能またはその完成/修正の開発のためのタスクの説明をコンパイルするときに使用します。 トレーニングは、テスターのトレーニングとほとんど違いがありません。ここでは、新たな問題の議論の形でのインタラクティブなヘルプと、必要なすべての情報を備えた企業のwikiによる優れたプレゼンテーションが役立ちます。



原則として、オートメーターはトレーニングを必要としません。主なことは、自動化プロセスの主要なポイントを伝え、テスターの想像力の飛行を制限することは不可能であることを明確にすることです。 テスターに​​は独自の「キッチン」があり、独自の世界観があります。



方法論へのアプローチでは、ある役割から別の役割への進化が可能であることに注意する必要があります。 そのため、機能テスト担当者は、BDDケースのコンパイルとその自動化に必要な経験を積んだ後、コードレビュー担当者の役割を果たすことができます。 コードレビューアは、ケースを書くだけでなく、BDDフレームワーク内の本格的なコードを望んでおり、必要なすべてのスキルを習得すると、オートマトンになることもできます。 まだ前例はありませんが、自動化エンジニアはBDDテスターの間で自動化のトレーニングコースを開始しており、近い将来に自動化エンジニアを「成長させる」ことを願っています。 最低限の要件は、OOP言語のスキルと、何か新しいことを学びたいという強い願望です。



入ってくるすべての「新しい」テストスタッフから、BDD自動化のトレーニンググループを時々編成し、新人が方法論をよく理解するのを助けるだけでなく、チームに新人を投入する上で重要な役割を果たす訓練を受けた人々からメンターを特定します。 これは、方法論の他のすべての参加者にも適用されます。



方法論を実装した結果は、従業員を訓練するための有能で体系的なアプローチに依存することを忘れないでください。

6.結果と問題について話し合います。

自己回帰補充の結果は、いわゆる「スプリント」を要約するときに毎週議論されます。これは、製品の自動化がどのように発展していくかを記録し、新たな問題について議論する毎週の期間です。 会議では、先週の結果が要約され、自動化の定量的指標が発表されます。 BDD自動化チームにとって、これは優れた動機付けツールであり、作業が見過ごされないことを理解させます。 , «», , , , .



, BDD- «BDD-», . , , , . , BDD- , , BDD-. , , , , .



— , «» , BDD-. : , « ».



, . ; , , .









— , . . , , . , , - , , , . , , . : , , , . , . . , , .



. , , , - . , : . «» .



— . , . — , . , . : « — — ».



, , - .

, , , . open-source . , Selenium open-source «» , . . CI-: - , - , - . : — . , , .

7.

BDD- BDD-. , — , «BDD-», BDD- . , 100% — BDD- (-, , ), BDD- , . :









, BDD-, , , , . , , . , / , , . , , BDD- . BDD- , : , BDD- .



BDD- BDD-, , . BDD-. BDD-, , . . , , . . , , . , .



BDD-, , «», . , N . , . TeamCity Selenium Grid.



, , . . BDD- . BDD- . .

おわりに

BDD . , , , BDD BDD , , BDD «» .



, BDD : — , . BDD , , , , , .



, , , , , , . , , , .