I’ve blogged about test automation before but I never touched on exactly how this is put into action. I’ll get out of jail early and say this is all based on what I’ve seen/heard/experienced and it won’t be the same for everyone.
As I’ve said before I was given a choice back in the day – did I want to become a developer or a tester – it never really occurred to me that you could be both (in a manner of speaking). The illusive hybrid individual I refer to can be called all sorts of things out there in the big wide world e.g. a Developer-in-Test, an Automation Tester, QA Automation Engineer, etc. Though these folks usually only ever get involved in or get swept up in all things test automation whether setting up frameworks, writing tests, maintaining the environment, etc. It can quickly become all consuming. Many companies seem to be recruiting heavily for these roles of late (let’s call them Unicorns) but you have to wonder whether their alleged needs are at best short-sighted and worse, run the risk of diluting the true skill of manual testing. Like I’ve said before, a healthy mix of both manual & automation can be fairly powerful when done right.
Dependent on the particular testers background, then they may have had prior experience of writing code. This would (I guess) make the transition over to being able to write automated tests that bit easier. Since from what I’ve seen automated tests often require the ability to write code. Moreover, in addition to writing code, there needs to be an appreciation for knowing whether the code is doing what you want it to do. Is it actually testing whatever it is you’re wishing to test. The word ‘assertion’ is often used to describe this aspect of behaviour. Plus, has the automated test been written as well as it could be written? Will it run fast? Will it garner reliable results? Will you trust those results?
But hang on a tick. What if your experienced, highly skilled, highly motivated, love-what-they-do testers, defect finding geniuses don’t come from a background ridden with setting variables, writing methods and asserting x, y, and z? Are these (and I hate to christen them) ‘manual testers’ now dinosaurs roaming the earth in search of coffee? I think not.
Companies can come to many realisations. Such as ‘wow’ this automation testing business is more trouble than it’s worth and back out of it completely. Others, may come to realise they initially went with the wrong tooling or wrong strategy. Nothing wrong with that I guess though it could become a costly mistake – but here’s the thing – let’s say you have a bunch of great ‘old fashioned’ and ‘wise’ manual testers who really know their onions. You also have equally great developers. You may have the budget to ‘recruit’ in a Unicorn-in-Test to come and miraculously implement all your automation needs (*your sarcasm radar should be bleeping by now*) but sooner or later there’ll be a stumbling block owing to your manual testers being unable to write automated tests, read and understand automated tests, maintain and trust automated tests.
So what do you do? I’ve yet to read anything online about the definitive answer to this dilemma. Some may have a genuine desire to learn how to code – but learn which language, do they learn in work time, how will they learn, who will support them, etc. Some may have dabbled in writing code and want to learn more. Others might not wish to have to re-train to become a developer. Some might feel pressurised to learn but have no idea where to start. Maybe it might be better to have your manual testers pair with developers and create them together. The developer can do what they do best – write code – whilst at the same time the tester can offer an insight into what needs to be tested, keeping a close eye on coverage and regularly assessing risk.
It’s a tough one. I get inundated with recruiters contacting me and several have suggested companies ask for heaven and the earth without really thinking about it. If a job description comes across as overly automation centric then they may be shooting themselves in the foot and inadvertently losing out from hiring truly great testers who are likely to shy away in fear of not ticking all the many (seemingly never ending) desired skills checkboxes.
Ultimately, it should be a team effort and companies should never really expect to have a single Unicorn-in-Test come in and do everything single handedly. Nor should companies under-estimate the very real threat of focussing too much on automation at the expense of manual testing.
Personally, I hate having the word ‘manual’ as a pre-fix. ‘Manual’ testing is so much more than a ‘manual’ tester manually running a test. Long may they roam planet Earth!