Best Approach to Test Automation

Throughout the years, I’ve seen many failed test automation efforts, mostly due to poor usability of the implementation. Some companies go through four or five automation resets for a single application, mainly because of failing tests. Some blame changes in the system for the infinite loop of breaking and fixing scripts, which finally becomes unmanageable for fixing existing scripts and implementing new ones. Others fail simply because scripts are not trustworthy for anyone but the test automation team because of the high amount of false positives. Ultimately, I think the actual reason these efforts fail is due to not identifying and sticking to a clear goal.

I personally like to approach test automation with one of the following goals.

It is crucial for the success of the effort that we have a clear goal and vision, as well as sticking to it throughout the implementation.

The simple answer is we don’t know what scenarios will be automated until the development of each one. In addition, technically a percentage is calculated with two inputs: completed(numerator) and to be completed (denominator). Thus, there’s just simply not enough information to know what 100% automation would look like, let alone any percentage at all.

With the above in mind, manual testing scenarios should not be automated on a one-to-one basis either. That is just not feasible. For example, login is part of most manual testing scenarios but should only be automated once, and reused for any future implementations. Another main reason is that Test Cases are normally developed per US (user story), but automation should be implemented from a business perspective rather than a US testing perspective, mainly because of integrated flows which normally cover multiple US implementations.

The entire team must be aware of the pyramid concept. But most importantly when automating tests it is crucial to be aware that GUI Tests (Selenium tests) should represent the least number of tests in the project. Ignoring this is the main reason automated testing efforts fail nowadays: too many GUI Tests implementations. Leaving out acceptance tests at API/System level makes it really challenging to achieve the most important aspect of automated tests, TRUST!

Automated tests must be trusted by any stake holder (Dev, Business, etc.) and in order to achieve this, we need reliability and a minimum of false positives. The best way to solve it is to leave out the dependency for a GUI to perform a test. For example, when testing a specific system-generated document content, we don’t need to go through the GUI to generate that document. We can directly send a request to the system, get the document and perform tests. The GUI aspect should be tested on a specific scenario to test E2E document generation and should be run only once per execution rather than once per document.

Finally, it is crucial to understand that automated testing is a development process that requires deep technical expertise for the most crucial parts: the architecture of the framework, approach to automating and guidance on what to automate. With the right approach, the least technical team can succeed on most efforts.

Related posts:

She remarried in a hopeful year, changing the pattern, thread by thread. She sewed on angels like a prayer for clinging girls who shared a bed. They slept beneath the quilt of heaven. The mauve…

The hunt for content is the ultimate definition of a writer. Constantly seeking ways to feed your loyal readers with vital information or whatever strokes your curiosity is a firm struggle. Some days…

Although the French and English observations of the two world wars are often solemn and sometimes tragic, a bit of triumphalism does on occasion enter in. On Sunday, as I stood on the Champs…