I had a chat with a chap who used to work for me.
He was looking for a new contract, but the latest filters installed contained the key word “Automation” and his CV wasn’t getting through.
“What should I be doing?”, he says.
“Hmm…”, says I.
pause… I could have said many things, lie, learn, read, try it out, but… time on…
“Why not have a chat with the relevant people? Why not make a statement in your CV/initial contact about where you place automation in your skills toolbox? Why not write the skills profile in one page that describes you with a one-liner or two from different organisations you have worked with about the value add?”
Were all the things I thought about saying, but didn’t.
“Then”, I said, “Check out the likes of TeamCity, Octopus, Jenkins etc. to see what’s happening in the build, deploy, test, rinse and repeat area”
“After that”, I continued, “Look into Selenium, Fiddler, Python, Perl etc. and how they are applied in this area of Test Automation”.
“Oh”, he said… Pause…
“Jaysus Ivor, I’m just looking to get a contract testing, I’m no developer”, he said.
“I know! But if you’re looking to do that you need to look for the right role and not beating yourself up about Automation”, says I.
The truth is, testing is evolving. Traditional test roles, where test cases are written against large requirements sets and encased in reviews, approvals and sign offs, are disappearing. Testing adds value up and down the chain of an application/products development, whether in an Agile. Kanban, Waterfall or any other methodology we can throw out there.
Except, now Business/System/Product Analysts are building testing into what they do. Now, good developers are building good quality tests into what they do. ETL developers are working hard at verifying the data pipelines they are laying down. We’ve brought the user closer to us for testing purposes in UAT. We’ve cut our product/products up into self managed deliverable chunks and it seems to work.
As testers we now have a role to play by asking the hard questions (usually at the wrong time , by designing tests to be executed on a regular basis that are more about our insight than making sure the software works, by automating the tests that will be executed again and again, but most of all for thinking outside of the normal box, connecting thoughts, design and more with people and making things work.
As I see it, after going round the houses, the testing roles are evolving and have become more technical. The traditional testing roles have been dissipated and incorporated into other functions. The sapient tester is identified as a “Test Analyst”, while the more technical tester is a “Software Developer in Test”. Specialist roles of “Performance Testers” are more like DevOps and provide detailed insight into what happens to the product under duress. “Release Engineers” make sure the automated tests are run, the process executed faithfully to deliver a working product. The “Test Manager” is more of a supporting role, as cross functional teams form and disband to meet the needs of the organisation. This particular role is most at risk as testing becomes more embedded with the political clout once associated with it being taken up by “Product Owners/Managers”.
I do realise that I posit a view that is relatively narrow in its scope. I don’t include Governmental organisations or Banking/Financial institutions. These have typically been well behind the curve in adopting new and ultimately better ways of doing business internally.
Maybe this post should have been in the “Rants” section
Anyways, tis my €0.02c.