Transitioning from manual to automated testing

In the dynamic landscape of software development, the shift from manual to automated testing has become a crucial aspect of ensuring quality and efficiency. For experienced Quality Engineers (QEs) who’re proficient in manual testing, making the transition to automated testing opens new avenues for improving testing processes, reducing time-to-market, and enhancing overall product quality. It also opens up new career opportunities. However, this transition comes with its challenges and pitfalls that need to be navigated effectively, especially for those with little or no programming background.

For those who don’t know, automation testing is all about translating the manual test steps (a human would do) into scripts that can be run automatically. Thus, QEs who started out in manual testing should invest time in learning programming languages commonly used in automated testing. Learning the programming language first (with its ins-and-outs) is crucial before choosing an automation framework.

We recommend choosing a framework with English-like statements, such as Playwright (JavaScript), for beginners to understand easily.

An example of a Playwright testing script.
Easy to understand, right? …right?

Alternatively, check out our previous article for other popular frameworks.

Now that the automation framework has been selected, it’s time for the planning!

Writing and testing the plan

Since the idea is to have the automation script perform the steps a human would do, we (as QEs) will, first, have to figure out what the test steps are. This is where we make use of the Cucumber method to plan out the steps for executing each test.

Syntax for the Cucumber

From there, the automation scripts can be written relatively easily.

So how do we map from the Cucumber scripts to the Playwright (Javascript)?

All the pre-conditions (the Given statement) goes before the test-block. All test steps to be executed goes (the When statement) into the test-block, where the required actions are performed. Finally, the expected results (the Then statement) are to be performed after the test-block, which are represented as assertion or the expect() statements.

Cucumber syntax to Playwright syntax

Store these test documents in a centralised storage (e.g. Confluence) so that they can be easily accessed by all team members. Ideally, the documents would contain links to the steps for running each manual test.

Cool. I’m gonna automate EVERYTHING!

Slow down, buddy. Not everything can be, or even needs to be automated!

Consider criticality, frequency of execution, regression testing needs, time consumption, UI complexity, and maintenance effort when deciding which tests to automate. Prioritise tests that offer a high ROI in terms of time saved and improved test coverage.

It’s best to automate tests for which the product requirements will not change (at least within the next month). Automation scripts are particularly useful for regression testing, especially if your product team has frequent releases (say, every 2 weeks. Yay Agile development!).

Automation should be used for the following:

• Security testing
• Functional testing
• Regression testing

As the tests may be on the Frontend (UI) or Backend (API), we’d recommend choosing a single framework (like the Playwright (JavaScript)) that covers both UI and API testing. This creates a unified test environment where all tests use the same “coding style”. It also makes for integrated test reporting, where a single report can display the result of all tests at once. Playwright (JavaScript) for example, has built-in reporters.

Transitioning from manual to automated testing is a significant step for experienced QEs seeking to enhance their testing capabilities. By addressing the common pitfalls, adopting effective strategies, determining the appropriate tests for automation, and leveraging recommended automation frameworks like Playwright for UI testing, QEs can successfully navigate the transition and contribute to more efficient and effective testing processes in software development.

However do note that automation should not be used for exploratory testing or smoke testing. It also should not be used if the product requirements are not properly confirmed, or they are constantly changing.

Continuous learning and hands-on practice is the key to mastering automated testing and achieving higher levels of quality standards in your products.

🧙🏼‍♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.