Having The Right Mindset to Choose Between Manual and Automated Testing

The Diwali holiday is just around the corner 💫 For Hindus all over the world, this is the time to remove all dirt from their heart and light a candle to spread happiness all around!

This blog is dedicated to the entire testers community. Just like Diwali, I aim to remove any confusion in the minds of testers who are in the dilemma of choosing between manual and automated testing. This article will shed light on the typical mindset a tester develops to perform any of these two testing streams.

Manual testing is often considered a boring task and feels like walking on a dry and dusty road 🥱 On the other hand, automated testing seems exciting and challenging. It gives the impression that someone is driving a fast car on a freeway.

Many testers want to do both or want to switch from manual to automated testing. This is good if they have the right mindset to do this switch. Manual testing requires an approach that is quite different than the mindset required to do automated testing.

What is a manual testing mindset?

A manual testing mindset means constantly thinking: “how can I break it” 🪓 The tester will ask the following:

• What can go wrong?
• What can I do to break the application?
• How can I find the weaknesses in this system?

By saying “How can I break the application?”, the tester doesn’t sound destructive. Rather he helps the application not to break when deployed to the production server. He puts himself in the end user’s shoes and tests the application for all possible scenarios. So he is not “destructive” in nature, but he is “destructively constructive”.

He plays an important role at each stage of the software development life cycle. In waterfall methodology, he comes late in the SDLC, but Agile has put him in the front with the developers.

So while developers work on the design of their solution, a tester works in parallel to develop his cases, to ensure he also finishes his tests within the sprint 🏃‍♀️

If we divide the SDLC within the Agile framework into 5 distinct phases, the manual tester has a specific role to play in all. His mindset should remain focused and calm to deliver test results in each phase. Here is a table depicting each SDLC phase and the manual tester’s mindset status:

What is an automated testing mindset then?

Let’s begin with a few common statements:

• “We just need automation to make things better”
• “Automation is the solution for us”
• “Just create more UI tests”

More automation plans fail than they succeed because the mindset to do them is not correct ❌ The organization needs to develop a mindset favoring automation and the teams need to develop a mindset where they can think of coding frameworks and automate tests.

Automation is a process where the engineers need to think like developers yet need a QA-like eye to look out for any defects.  An “automation mindset” is a way of thinking where the engineer is constantly re-imagining doing a task, process, or an entire workflow more efficiently through continuous analysis and automation.

Most importantly, they need to understand that doing automation is no longer trying to find bugs, but trying to prevent them from happening. Automation is one of many things that needs a mindset change; if you don’t have a good team or company culture, it will be hard to get things done.

You should choose your automation framework carefully and do your research to understand what suits you and your team 🔍 Here are important  things to consider before planning for automation:

• If the framework is continuously maintained and updated to keep pace with the latest trends
• If it suits your needs to automate
• If you’re working with the backend, it doesn’t make sense to create a different test project, as it will only create confusion between you and the developers
• Plan to use the same programming language that the team is using to create the tests; it will remove the knowledge gap and reduce maintenance costs
• If automating mobile apps, you have different options using black-box frameworks such as Appium, Espresso, EarlGrey, XCTest. Choose carefully, and don’t get too excited or you will overload the UI layer with tons of tests
• If you’re thinking of using any BDD framework to write your specifications, validate it first with your team. It has a HUGE benefit but everyone should agree to it
• You should be able to write useful unit tests and help the team to develop them if necessary

Think like a QA but act like a developer 👩‍💻 It’s constructive development but it doesn’t have a UI as against a development exercise. It will still remain behind the curtain job or a thankless job.

People will only praise what they see, and that is what a developer works with. QAs understand this, but often an automation engineer thinks of himself as a developer but doesn’t get enough respect as one. Hence he should remember that automation is essentially a QA task only.

The idea behind the “automation mindset” is to not only continuously evolve IT but also constantly automate processes using all the available tools. At a broader level, the mindset requires organizations to invest in people who have a talent for automation 💡

You can try to train developers or business users to develop automation, but unless there is a formal program (Center of Excellence or COE) within an organization, the results will not be optimal.

Conclusion

Automation is not just a “nice to have” exercise. It requires a mindset to develop it, and not any QA can become an automation QA. An “automation mindset” cannot be adopted overnight, rather it needs a program that is developed and nurtured by people who view automation as an essential part of today’s business operations.

I hope you learned something new, and I want to wish you all a happy Diwali! ✨