QnA with Ajay Balamurugadas
Here’s a quick QnA session with the one and only witty and sharp, Ajay Balamurugadas.
Ajay is an esteemed speaker, conducts multiple training sessions, learning activities, and testing initiatives. He is always ready to help and suggest thoughtful ideas(no doubt why people call him the “idea guy”!)
Ajay leads delivery at Qapitol QA, a QA services’ company that topped the GTR Leaderboard.
Here’s what we discussed.
Do you have a different strategy for your automation and your testing? Or one strategy to rule them all?
Automation and testing should not be compared. It is like comparing physics and science, baking, and cooking. Automation is part of testing. You need to check if certain things are as expected and a tool can do that faster. That is where automation will help.
There are certainly other areas and aspects of testing where it helps if you have a tester test, explore the application. You choose automation (tools) or humans based on what would help you achieve your mission, save time and cost (in that order most of the time).
How can manual testers and automation engineers complement each other when testing?
We need to first get rid of the terms – manual and automation engineers/testers. Maybe, let us call everyone testers – some specializing in functional testing and some good with automation tools.
We should understand the goals of testing – discover information related to the quality of the product. I recommend everyone read this thread by Ben Simo where he highlights how automation can help in testing.
What do you think is important for any team that is already working on automation or planning to start?
All the automation that is done should help everyone in the project. Imagine you have built the best scripts but no one is using it, what is the use? So, use automation not to replace testing as some claim, but to enhance the powers of testers
People say they can only know the maintenance cost once they have put the tool to use for some time, what scenarios should we keep in mind to get to know these sooner?
Discuss internally, use the trial version on the real project, ask people who have already used the tool. Do not think short term. See how you would use the tool for your projects in future.
Analyze the costs throughout the cycle.
What factors can help a team decide if they are mature enough to adopt automation?
If you answer No to any of the following four questions, I would say – wait, maybe you are not ready yet.
- Are you and the product, development teams in sync about the release cycles and the changes?
- Does everyone understand the current pain points and feel that automation can help remove the pain points?
- Do you have the buy-in from the management?
- Do the teams have the freedom to choose the tool for automation?
Are there scenarios when automation is not a solution? Can you give us an example?
Any team where automation is done just to prove that people are working on automation, trying to automate everything, automating the incorrect things are all examples where automation is more harmful.
One scenario where I think automation should be used to execute scenarios but used to help in other activities is when the product is undergoing a lot of changes, frequently.
Please do not automate if all the teams are not in sync about the value of automation else you will waste a lot of time and money.
To reduce learning costs, what would you say is better – a tool that has a good support team or a tool that has a good forum presence?
The ultimate goal should be achieved. The team should be able to learn the tool quickly. It could be through the support team sometimes and sometimes by a good forum presence. My personal preference is the forum presence for open source. Support is not always available and I would learn quicker from someone who has gone through the struggles similar to mine.
In cases of commercial tools, you can be confident of a better support system that will guide you from onboarding to first tests to solving any problems and helping achieve your goals. With commercial tools, I prefer the support teams.
It is a new challenge today. When everyone is remote and maintaining quality, how to stay demonstrably productive at this time?
Staying demonstrably productive is a wrong goal to chase. Be productive. That is enough.
At the start of the day, communicate to your team about the tasks you are targeting for the day. If any change in priority is needed, the team will let you know.
At the end of the day, highlight what was achieved and what is the plan for the rest. Do communicate a lot and agree upon catch up times.
Do you have any tips for effective testing at these testing times?
Anytime, everytime, work on your skills and do justice to the CTC you take home.
Do not lie to self.
Now we are in 2020, how far have we come in terms of testing? Also, do you think AI is the future of testing?
Patterns repeat. Those days, people were chasing Selenium. Now they are chasing AI. The chase continues. Very few have dedicated their lives to learning testing in depth. AI is the future? Ha, ha. We will test applications based on AI but AI might not be the future so soon. It will take time. The chase will continue for the next big thing. We are forgetting that we are dealing with people at the end of the day and very few can predict what people want.
At the same time, this is the time where we have so much data and computing power to analyze and predict with reasonable confidence compared to the past. People are already building applications that are heavily powered by AI and testing them brings out interesting challenges for the software testing community.
Let us enjoy the journey!
Check out Ajay’s latest book at www.leanpub.com/50mistakes that discusses 50 software testing mistakes of his career and find out more testing resources from him at Enjoy Testing.
Ajay is very approachable and always willing to give advice. Hit him up on Twitter and LinkedIn.
Thank you Ajay for sharing your thoughts with us 🙂
