Cucumber
132 views | +0 today
Follow
Cucumber
BDD through Cucumber
Curated by Monogeo
Your new post is loading...
Your new post is loading...
Scooped by Monogeo
Scoop.it!

Orders of Magnitude in Test Automation

Orders of Magnitude in Test Automation | Cucumber | Scoop.it
Many teams focus on automation at the level that’s easiest to automate given the team makeup and the readily available tools. For some teams, that means lots of automated unit tests. For others, it can mean large suites of GUI-level automation tests.
more...
No comment yet.
Scooped by Monogeo
Scoop.it!

Cucumber jargon

Cucumber jargon | Cucumber | Scoop.it
Step-by-step guide for Cucumber, a tool that is quickly becoming the weapon of choice for many agile teams when it comes to functional test automation, creating executable specifications and building a living documentation.
more...
No comment yet.
Scooped by Monogeo
Scoop.it!

The Three Layers of UI Automation

The Three Layers of UI Automation | Cucumber | Scoop.it

The closer tests are to business rules, the more stable they are.

 

Business rule or functionality level: what is this test demonstrating or exercising. Ideally illustrated with realistic key examples. For example: Free delivery is offered to customers who order two or more books, illustrated with an example of a customer who orders one book and doesn't get free delivery and an example of a customer who orders two books and gets free delivery.

 

User interface workflow level: what does a user have to do to exercise the functionality through the UI, on a higher activity level. For example, put the specified number of books in a shopping cart, enter address details, verify that delivery options include or not include free delivery as expected.

 

Technical activity level: what are the technical steps required to exercise the functionality. For example, open the shop homepage, log in with testuser and testpassword go to the /book page, click on the first image with the book CSS class, wait for page to load, click on the ‘Buy now’ link and so on.

 

From the bottom up, the technical level of tests decreases. At the technical activity level, you need people who understand the design of a system, HTTP calls, DOM and such to write the test. To write tests at the user interface workflow level, you only need to understand the web site workflow. At the business rule level, you need to understand what the business rule is. Given a set of third-level components (eg login, adding a book), testers who are not automation specialists and business users can happily write the definition of second level steps. This allows them to engage more efficiently during development and reduce the automation load on developers.

 

More importantly, the business rule and the workflow level can be written before the UI is actually there. Tests at these levels can be written before the development starts, and be used as guidelines for development and as acceptance criteria to verify the output.

 

The business rule level is not tied to any particular web site design or activity flow, so it remains stable and unchanged during most web user interface changes, be it layout or workflow improvements. The user interface workflow level is tied to the activity workflow, so when the flow for a particular action changes we need to rewrite only that action. The technical level is tied to the layout of the pages, so when the layout changes we need to rewrite or re-record only the implementation of particular second-level steps affected by that (without changing the description of the test at the business or the workflow level). To continue with the free delivery example from above, if the login form was suddenly changed not to have a button but an image, a ninja would only need to re-write the login action at the technical level.

more...
No comment yet.