敏捷テストの借力DSL
5430 ワード
敏捷性がますます広く知られるにつれて、敏捷性テストも多くの注目を集めている.ここでは、敏捷なプロジェクトで出会った自動化テストに関する問題と、DSL分野の専用言語を利用して解決する方法についてお話ししたいと思います.
敏捷なソフトウェア開発方法についてよく知っている人は、敏捷なソフトウェア開発プロセスが反復的に提供されるプロセスであることを知っています.各反復は、比較的小さな納期サイクルに相当します.では、頻繁なソフトウェア配信に合わせて、迅速なテストは従来のテストに比べて調整されなければなりません.これにより、迅速なプロジェクトでのテストはいくつかの特有の課題に直面します.頻繁な回帰テストは、各反復の成果が提供可能な であることを保証する.は、品質情報のフィードバックサイクル を短縮するために、開発チーム全体をテスト活動に参加させる.お客様をテスト活動に参加させ、テストの有効性を向上させる 自動化テストは、頻繁な回帰テストという課題に対応する上で非常に重要な役割を果たしています.自動化テストがうまくいかないと、チームは最終的に反復ごとに増加する回帰テストワークロードに圧倒されます.
私が経験したチームは、このチームの中で、みんなはとっくに自動化テストの重要性を意識して、自動化テストに全力を尽くしています.自動化機能テストが十分に増加すると、手動回帰テストを指導し、納品プロセス全体が順調に進むことを保証できると信じています.
確かに、自動化テストが始まったばかりの頃、私たちは収益が多かった.自動化テストを追加するたびに、手動テストを減らすことができます.自動化テストでは、まだ自動化されていない、自動化されにくい機能点を手動でテストする時間に余裕があり、探求的なテストを行う時間もあります.この結果はチームに生活が素晴らしいと感じさせ、自動化テストを信じさせます.
しかし、良い状況は長くなく、自動化テストが増加するにつれて、私たちはこのような問題に直面します.自動化テストは、実装の詳細をめぐって展開される.数が増えるにつれて、ビジネスの輪郭は細部に迷いやすい. は、機能レベルでテストの追跡を失った.テスト担当者は、それらのテスト・ケースが自動化されたテストで上書きされていることを具体的に理解できないためです.チームは、復帰するたびにテストグループ全体に復帰する必要があります.
そこで、手動テストは自動化テストの助けを得ることがますます難しくなっています.プロジェクトの鶏の肋骨になり始めましたテストコードの読み取りが困難で、メンテナンスが困難で、テスト結果も苦労しているように見えます.これは、自動化テストを増やすだけでなく、テスト結果を読んで利用するのに多くの時間を費やすことになります.
そこで、自動化テストのやり方を見直し、より良い方法を模索し続けました.
すぐに、「走れる」ことは、テストを自動化するのに必要な特性ではないことがわかりました.テストコードを通じて、具体的に何が起こっているのか見てみましょう.
このテストでは、まずページを開き、ページの中でidがusernameの入力ボックスを探し、「myname」を入力し、次にidがpasswordの入力ボックスを探し、「password」を入力し、idがbtnLoginのボタンをクリックして、30秒後にページに現れるべき文字を断言します.
このテストの実装は,目的ではなくステップ向けの記述であるテストの操作過程を完全に記述していることが分かる.もちろん、少し分析すると、このテストの目的はユーザーのログイン成功システムを測定することであることもわかります.
しかし,このようなステップ向けに記述されたテストが多い場合,無数の微細な操作ステップに埋もれたテスト意図を抽出し,テストの結果を利用することは,それほど直感的ではないことを想像する.また,テスト中にエラーが発生した場合,問題の具体的な機能点の位置決めも容易ではない.
同時に、チーム内のすべてのメンバーがこのようなテストを読み、作成する能力があるわけではありません.これにより、チームメンバーの自動化テストへの参加度が低下することは間違いありません.お客様にとって、自動化テストはブラックボックスであり、何をしたのか、何をしていないのか、基本的には分かりません.自動化テストに参加することはできません.テストの有効性を高めるのに役立ちます.
様々な状況は、テストの可読性が悪すぎて、テストの意図が明らかではないからだ.実行可能で読みやすいテストこそ、良い自動化テストです.これにより、テスト・ケースの追跡と管理を失うことなく、いつでも保証できます.テスト担当者は、テストをすばやく読むことで、自動化されたテストで上書きされている機能を理解し、手動テストのワークロードを効果的に計画することができます.
どのようにしてテストの可読性を高めますか?
私たちの解決策はDSL分野の専用言語です.
分野専用言語とは?マーティンおじさんのブログには詳しい説明があります.大まかに言えば,領域専用言語はある領域に対する特定の目的のプログラミング言語である.Java、C#などの共通言語とは異なり、どの分野の問題も解決できます.レルム専用言語は、独自の構文構造によって、専門分野言語に近いビジネスを記述します.
テストの記述を被験システムの領域言語に近づけ、テスト意図を明確に表現することが望ましい効果である.DSLはちょうど私たちを実現することができます.
前のコードを見てみましょう.
共通言語を使用しているため、私たちの特定の使用シーンでは細部化、プロセス化されすぎて、テストの意図を明確に表現できません.
DSLに変更すると、私たちのテストは直接検収基準の言語で以下のように記述することができます.
このようにテストの内容は直感的に多くなり、ビジネス情報も含まれています.これは任意の入力情報ではなく、ログインシーンをテストし、ビジネス知識を伝える役割を兼ねていることを知っています.これらのDSLの背後で実行できるコードについても、隠されています.元のようなテストコードを読めない人(需要分析者でも顧客でも自動化コードに関心の少ないテスト者でも)が自動化テスト活動に参加してフィードバックしようとすると、DSLの背後にあるコードによる「騒音」に影響されません.
もちろん、私たちの現実的なアプリケーションシーンでは、このニーズはそんなに簡単ではありません.私たちの検収基準では、異なるデータ、例えば異なる組み合わせのユーザー名パスワードを入力することも考えられます.
さらに多くのテストデータがあります.
では、この場合、比較的通俗的な言語だけでは足りません.結局、テストの数はそこに並んでいます.テスト数が減らない場合は、メンテナンスが面倒です.例えば、システムの実装が毎回ユーザー名、パスワード、ランダム検証コードを入力するようになった場合、自動化テストで複数の場所を修正する必要があります.煩雑です.したがって,比較的可読性の良い自然言語記述のテストでは,その抽象階層をさらに向上させる必要がある.
幸いなことに、私たちが選択したDSLツールはcucumberで、いくつかのテストの記述階層:Feature、Scenario、Step sのほか、非常に良い組織方法-データテーブルを提供していました.
このように、私たちのこの自動化テストは、以前のログイン機能を特性、シーンのまとめ、具体的な手順に基づいて分離し、明確に階層化すると同時に、データテーブルを利用して、私たちのテストを何度も繰り返したが、入力データが変化した一連の操作プロセスに簡素化することができます.以下のようにします.
テストはこれでもっと爽やかに見えます.まず、Featureキーワードで、私たちはテストをloginという大きな特性の下に分類し、この特性自体の業務目的について説明し、業務目標に持ち込み、業務知識を伝達します.それからScenarioキーワードを使って、私たちのこのテストシーンでやったことはテストログインが成功したことを明記し、手順を書きます.最後に、Examplesキーワードで具体的なデータテーブルを引き出し、使用したデータをすべて表示し、テストデータの変化によって同じ手順が何度も繰り返されることによる冗長性を回避します.万一、需要の変化に遭遇した場合、ユーザー名、パスワード、検証コードを同時に提供するように要求された場合、私たちのテストも少ない場所を変更するだけで十分です.
さらに素晴らしいことに、このようなデータテーブルを使用すると、チーム全体の協力効率が向上します.コードを書くのがそんなにスムーズではないテスト担当者にとって、自動化テストを増やすことは、より多くのテストデータを増やし、データテーブルに記入すればいいのです.
このように,DSLを用いて実行可能な可読性の高い文書を実現した.テストへの復帰を支援し、ドキュメントのメンテナンスの難しさを低減し、チームメンバーがテストを利用して知識を伝達する積極性を促進し、より多くの人がテストに参加できるようにします.もしあなたのチームも似たような問題に遭遇したら、試してみてください.
敏捷なソフトウェア開発方法についてよく知っている人は、敏捷なソフトウェア開発プロセスが反復的に提供されるプロセスであることを知っています.各反復は、比較的小さな納期サイクルに相当します.では、頻繁なソフトウェア配信に合わせて、迅速なテストは従来のテストに比べて調整されなければなりません.これにより、迅速なプロジェクトでのテストはいくつかの特有の課題に直面します.
私が経験したチームは、このチームの中で、みんなはとっくに自動化テストの重要性を意識して、自動化テストに全力を尽くしています.自動化機能テストが十分に増加すると、手動回帰テストを指導し、納品プロセス全体が順調に進むことを保証できると信じています.
確かに、自動化テストが始まったばかりの頃、私たちは収益が多かった.自動化テストを追加するたびに、手動テストを減らすことができます.自動化テストでは、まだ自動化されていない、自動化されにくい機能点を手動でテストする時間に余裕があり、探求的なテストを行う時間もあります.この結果はチームに生活が素晴らしいと感じさせ、自動化テストを信じさせます.
しかし、良い状況は長くなく、自動化テストが増加するにつれて、私たちはこのような問題に直面します.
そこで、手動テストは自動化テストの助けを得ることがますます難しくなっています.プロジェクトの鶏の肋骨になり始めましたテストコードの読み取りが困難で、メンテナンスが困難で、テスト結果も苦労しているように見えます.これは、自動化テストを増やすだけでなく、テスト結果を読んで利用するのに多くの時間を費やすことになります.
そこで、自動化テストのやり方を見直し、より良い方法を模索し続けました.
すぐに、「走れる」ことは、テストを自動化するのに必要な特性ではないことがわかりました.テストコードを通じて、具体的に何が起こっているのか見てみましょう.
selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))このテストでは、まずページを開き、ページの中でidがusernameの入力ボックスを探し、「myname」を入力し、次にidがpasswordの入力ボックスを探し、「password」を入力し、idがbtnLoginのボタンをクリックして、30秒後にページに現れるべき文字を断言します.
このテストの実装は,目的ではなくステップ向けの記述であるテストの操作過程を完全に記述していることが分かる.もちろん、少し分析すると、このテストの目的はユーザーのログイン成功システムを測定することであることもわかります.
しかし,このようなステップ向けに記述されたテストが多い場合,無数の微細な操作ステップに埋もれたテスト意図を抽出し,テストの結果を利用することは,それほど直感的ではないことを想像する.また,テスト中にエラーが発生した場合,問題の具体的な機能点の位置決めも容易ではない.
同時に、チーム内のすべてのメンバーがこのようなテストを読み、作成する能力があるわけではありません.これにより、チームメンバーの自動化テストへの参加度が低下することは間違いありません.お客様にとって、自動化テストはブラックボックスであり、何をしたのか、何をしていないのか、基本的には分かりません.自動化テストに参加することはできません.テストの有効性を高めるのに役立ちます.
様々な状況は、テストの可読性が悪すぎて、テストの意図が明らかではないからだ.実行可能で読みやすいテストこそ、良い自動化テストです.これにより、テスト・ケースの追跡と管理を失うことなく、いつでも保証できます.テスト担当者は、テストをすばやく読むことで、自動化されたテストで上書きされている機能を理解し、手動テストのワークロードを効果的に計画することができます.
どのようにしてテストの可読性を高めますか?
私たちの解決策はDSL分野の専用言語です.
分野専用言語とは?マーティンおじさんのブログには詳しい説明があります.大まかに言えば,領域専用言語はある領域に対する特定の目的のプログラミング言語である.Java、C#などの共通言語とは異なり、どの分野の問題も解決できます.レルム専用言語は、独自の構文構造によって、専門分野言語に近いビジネスを記述します.
テストの記述を被験システムの領域言語に近づけ、テスト意図を明確に表現することが望ましい効果である.DSLはちょうど私たちを実現することができます.
前のコードを見てみましょう.
selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))共通言語を使用しているため、私たちの特定の使用シーンでは細部化、プロセス化されすぎて、テストの意図を明確に表現できません.
DSLに変更すると、私たちのテストは直接検収基準の言語で以下のように記述することができます.
Given I am on login page
When I provide username and password
Then I can enter the systemこのようにテストの内容は直感的に多くなり、ビジネス情報も含まれています.これは任意の入力情報ではなく、ログインシーンをテストし、ビジネス知識を伝える役割を兼ねていることを知っています.これらのDSLの背後で実行できるコードについても、隠されています.元のようなテストコードを読めない人(需要分析者でも顧客でも自動化コードに関心の少ないテスト者でも)が自動化テスト活動に参加してフィードバックしようとすると、DSLの背後にあるコードによる「騒音」に影響されません.
もちろん、私たちの現実的なアプリケーションシーンでは、このニーズはそんなに簡単ではありません.私たちの検収基準では、異なるデータ、例えば異なる組み合わせのユーザー名パスワードを入力することも考えられます.
Given I am on login page
When I provide ‘david’ and ‘davidpassword’
Then I can enter the system
Given I am on login page
When I provide ‘kate’ and ‘kate_p@ssword’
Then I can enter the systemさらに多くのテストデータがあります.
では、この場合、比較的通俗的な言語だけでは足りません.結局、テストの数はそこに並んでいます.テスト数が減らない場合は、メンテナンスが面倒です.例えば、システムの実装が毎回ユーザー名、パスワード、ランダム検証コードを入力するようになった場合、自動化テストで複数の場所を修正する必要があります.煩雑です.したがって,比較的可読性の良い自然言語記述のテストでは,その抽象階層をさらに向上させる必要がある.
幸いなことに、私たちが選択したDSLツールはcucumberで、いくつかのテストの記述階層:Feature、Scenario、Step sのほか、非常に良い組織方法-データテーブルを提供していました.
このように、私たちのこの自動化テストは、以前のログイン機能を特性、シーンのまとめ、具体的な手順に基づいて分離し、明確に階層化すると同時に、データテーブルを利用して、私たちのテストを何度も繰り返したが、入力データが変化した一連の操作プロセスに簡素化することができます.以下のようにします.
Feature: authentication
In order to have personalized information
I want to access my account by providing authentication information
So that the system can know who I am
Scenario Outline: login successfully
Given I am on login page
When I provide ‘<username>’ and ‘<password>’
Then I can enter the system
Examples:
|username |password |
|david |davidpass |
|kate |kate_p@ssword|テストはこれでもっと爽やかに見えます.まず、Featureキーワードで、私たちはテストをloginという大きな特性の下に分類し、この特性自体の業務目的について説明し、業務目標に持ち込み、業務知識を伝達します.それからScenarioキーワードを使って、私たちのこのテストシーンでやったことはテストログインが成功したことを明記し、手順を書きます.最後に、Examplesキーワードで具体的なデータテーブルを引き出し、使用したデータをすべて表示し、テストデータの変化によって同じ手順が何度も繰り返されることによる冗長性を回避します.万一、需要の変化に遭遇した場合、ユーザー名、パスワード、検証コードを同時に提供するように要求された場合、私たちのテストも少ない場所を変更するだけで十分です.
さらに素晴らしいことに、このようなデータテーブルを使用すると、チーム全体の協力効率が向上します.コードを書くのがそんなにスムーズではないテスト担当者にとって、自動化テストを増やすことは、より多くのテストデータを増やし、データテーブルに記入すればいいのです.
このように,DSLを用いて実行可能な可読性の高い文書を実現した.テストへの復帰を支援し、ドキュメントのメンテナンスの難しさを低減し、チームメンバーがテストを利用して知識を伝達する積極性を促進し、より多くの人がテストに参加できるようにします.もしあなたのチームも似たような問題に遭遇したら、試してみてください.