I am very much passionate about writing code, especially the test automation code. I have worked on different test strategies and tools to achieve the test automation of complex software. And, I love it.
I have been doing lot of interviews in ThoughtWorks lately. Thanks to ThoughtWorks that I’m getting opportunities to speak with different experiences and mindsets. In interviews, one thing which I see more and more is Automation Tester. Candidates flaunt their coding skills by talking about the different frameworks they have built. They talk about, design patterns they used to make the code more clean and maintainable, they talk about dev-ops scripts, and many more things. I agree that these aspects are important to have as an automation tester. But what I miss is the QA Mindset and Product Knowledge.
What does a QA Do?
Most of the “Automation Testers” whom I speak with in the interviews are primarily focused on the conversion of manual tasks into automation scripts. The “Automation Testers” are so indulged in developing automated tests that they wish to cover the exploratory aspect of the testing in the code as well. And, they do not realize that unknowingly it is making the code more complex.
I see QAs are becoming more and more concerned about programming languages, tools, design patterns, git, and other development skills by sidelining their primary QA skills like exploratory testing, negative testing, product knowledge, etc.
QAs need to understand that writing good code is important but shipping the quality product which meets the customer expectations is much more important. When the end users consume your product they do not care about the code practices or tools used while developing the product. What they embrace that the product is built as they expected it to be.
QAs need to understand that by focusing more on development skills by sidelining your primary skill, you are risking your product to become a defective piece of code.
A good tester:
- strategies the testing only after understanding the product behavior.
- has a clear understanding of who owns which part of testing and why?
- knows what to automate and value-added by the automated script?
- plans exploratory testing.
- fosters best practices and advocates quality in the team.
- have the answer to most of the WHYs related to product and SDLC.