Why talk about Design so early in the track?
The answer is simple. Of all the activities you engage in the automation life-cycle, the initial creation of Automation scripts is the easiest of the tasks. In fact, there are many record & playback utilities that allow you to just record your application interactions and play them back. While this gives instantaneous results, the outcome is also equally short-lived. It is impossible to maintain such scripts, and repairing them for proper design (as an afterthought) is way too cumbersome.
Plus, Design is not all that complicated. We will introduce the basic building blocks of design and see how these concepts evolve naturally without ever overwhelming you.
We will follow design-first as a core driving principle.
Three key constructs
To implement the ideas of design-first and ensure a modular automation development, we will be using the following three key constructs throughout our course. This is just an introductory text to get you started. We will learn a lot more about these concepts with every exercise we solve and understand how the 3 simple ideas can transform the way you look at automation design.
This is simply a use case (or test case) you want to validate in your application.
A Scenario is made up of a series of Actions (Steps).
Verify Funds Transfer on Qbank is an example for a Scenario
A Scenario reflects on a business process and provides a clean, functional, and non-technical view of your test case. It gives you the ability to assemble a test case as a series of pluggable steps rather than a monolith logic.
This is what you do in a Page (Context), to accomplish a meaningful application functionality or to test a certain function of your application.
An Action consists of logic (set of Statements) describing the interactions and verifications required for your testing.
Login to Qbank is a good example.
The concept of Action is central to modularity and reusability. As you will see with various examples, you can use the same Action in multiple Scenarios and achieve reusability including parameterization, etc.
If you are automating a web application, Context is simply a Web Page.
A Page may have multiple “visual states”, which we will call “Views”.
For non-UI testing, Context may be a container to group together related functionality.
QBank Login Page is a good example of a Context.
Context provides an effective way to "encapsulate" your core test logic so that various functional areas are clearly separated. This eases out maintenance significantly, as you can target ongoing updates in a more localized fashion.
Here is a simple example that shows these 3 concepts coming together to build a test case. For now, it is sufficient if you are just able to identify these concepts, and have a basic idea to differentiate. We will be continuously enhancing our understanding with various examples.