In software testing, in order to prepare a successful test automation project, one must understand first its components and how to ensure sustainability and maximize performance. These are 20 fundamentals every software engineer has to complete in order to achieve a high quality test automation infrastructure for an automation project:
*By completing the steps below, you’ll be able to also write the functionality in Selenium, Appium, Winium or any code library supporting automation testing.
1. Identify Page Elements (text fields, buttons, link etc.) and configure them in a certain class, in which you can implement functions that will perform several operations. For example: inserting text and clicking on a button by identifying the element beforehand – which is called Page Object.
2. Write a mechanism that will be activated when a test fails.
3. Write another mechanism to return the page to a certain point (for example: the main page) in order to create independent tests.
4. Develop a report module and implement a report module for the executed automated tests.
5. Add to the reports screenshots and recordings when tests fail.
6. Implement the project in a way that will allow reading all parameters from external configuration files (for example: the location to save the reports).
7. Incorporate Visual Testing for image comparison to test if the site looks as it is supposed to (for example: if a field moved by 6 pixels to the right, the test will fail).
8. Create Cross-browser compatibility.
9. Write log files to save information for the developers which will also include stack trace and other details from the exceptions, which will show up in case of a failed test.
10. Object Repository – implement also a central place in which you’ll identify all of the elements’ properties in the application.
11. Connect the system’s database to execute queries and draw information (Despite not having access to the application’s database, we can easily create a simulation for a portfolio).
12. Implement the Data Driven Testing (DDT) method to read from CSV/ Excel files.
13. Implement the Keyword Driven Testing (KDT) or BDD methods with Gherkin language.
14. Create support for parallel testing on different environments.
15. Connection to external libraries (for example: interface cloud services API such as YouTube)
16. Create support for scheduling execution and interface CI systems (it’s possible to install Jenkins CI server on the computer and working with it).
17. Compatibility with Mobile device platforms.
18. Expand to a compatibility with Desktop Apps.
19. The test automation infrastructure should be written according to known Design Patterns, Clean Code methods, coding conventions that must be configured at the design level.
20. Finally, documentation of the entire procedure from A to Z.
The list clearly shows how Selenium is a very small component of the automation testing project.
My rule of thumb is – if our test automation infrastructure consists of more than 20% Selenium code, then we did it wrong!
In order to demonstrate this practice, the following diagram presents the components of a test automation project:
*Notice the execution arrow that connects the automation project and the Application Under Test, this small arrow (and only this arrow) is Selenium.
Please comment, your thoughts, advice and how you turn your automation testing project to be successful 🙂
It’s easy to (grossly) underestimate the time, effort, and expense of establishing a successful automation program. This post provides an antidote along with a sort of checklist that even some graybeards like myself could appreciate.
I say “sort of” because I think it would be unwise to treat the twenty components as a literal checklist because doing so would violate the YAGNI (“You Ain’t Gonna Need It”) principle of agile software development. Even if we are pretty sure that we will need all twenty sooner or later, we won’t know exactly how they should behave until we write some tests, get some feedback from stakeholders, and learn about our actual needs.
a perfect husband and an automation framework is a myth..
Hey, I just wanted to add that instead of a common object repository it is IMO a better practice to include element locators in the page object file/class
It is easier to maintain the framework and you can know immediately what to update if a feature / page changes. In the case of common object repo, you can tie one locator to multiple pages which can make the maintenance harder.
Just my opinion. You
This is one of the best blogs on automation testing I have read. Outcome of every project shoulders on the people who put in their heart and soul to make it successful. I want to add Performance Testing as another aspect which is a very crucial factor which can’t be neglected.