The demand for automation skills when hiring testers has increased dramatically in the time I’ve been involved in the industry.
Back when I started, it was a “nice to have” skill set that would at most be listed under the desired skills but never the list of required.
Now though, it’s rare to see a job listing for a test role where there isn’t at least the demand for an understanding of test automation and at least one scripting language. More and more roles are being advertised where the top requirement is a good automation skill set. This will likely be followed by other mentions of good programming experience, CI/CD experience, framework creation experience or at the very least the experience of working with frameworks and source control knowledge.
But worryingly, what you’ll see less of on these job ads are a list of actual testing skills that in days gone by served as the template of any testing role. Now the tables have turned, and instead it’s the understanding of manual test processes that seem to be desired instead of required.
It’s this worrying trend that is seeing a big risk being bought into these companies testing practises. Simply being experienced in automation does not make someone a good tester. And creating a test with the most technical and most efficient code does not make it a good test case.
In an ideal world, everyone who has solid automation experience will have come from a background in testing and have experienced all aspects of testing to get an appreciation of the process. But the reality is, that those who have the most experience in automation most likely have the least experience when it comes to manual testing. So how can you be confident that your QA team, now fully made up of experienced SDETs, is maintaining a high standard of testing across the entire testing lifecycle.
We all know that despite our best efforts to do so, you can never fully automate anything. 100% automation is a fantastic objective to aim for, and it sounds good in project meetings, but it’s a target that you’re only going to achieve in exceptional circumstances. For most projects, there’s always going to be that manual requirement, and this will likely be across all stages of testing. From functional testing to integration testing, and especially regression testing, you’ll need to have at least some manual effort.
So, if your automation testers have little to no manual experience, it brings more risk in to your project. There’s nothing to say that these testers can’t do a good job and won’t keep software quality as high as a team of experienced manual testers would, but it’s that element of risk you introduce that should be considered.
There’s no easy solution to this, I’ve never had to deal with the stress of hiring and building a team with limited budget and headcount, so it wouldn’t be fair for me to just say the solution is to hire both. Obviously, that would be ideal, but nothing is ever ideal in the world of software. But I think that companies should remember the most important goal of having a QA team is to ensure software quality, and not to get caught up in the idea that everything must be automated because that’s what everyone else seems to be doing.
There are so many skills involved in a good QA team, and while it’s not always possible to have specialists for things like performance testing or penetration testing, it’s important to at least have experience of these areas. Something that might be difficult to achieve in a team where the main focus is automation.
Hire brilliant SDETs, but not at the cost of testing experience. As I said earlier, being able to create brilliant frameworks, write the most brilliant code and write clean scripts does not mean that you can write good tests. You still need to have that testing mentality of what a good test case is before you can start automating. Otherwise, you’ll just end up with hundreds of low return test cases that aren’t even close to identifying any meaningful bugs.
The key distinction to me is that a coder that tests will have the mentality of “This works, I just need to prove it”, whereas a software tester that can code will have the mentality of “This is broken, I just need to prove it”.
The post Trends – The Demand for Automation and The Risk for Testing appeared first on Learn Automation.
