Specialise, don’t overspecialise

Since I deviated from the main topic, I want to go back to that arbitrary, unfounded division of ‘automators’ and ‘manual testers’. In my opinion, automation is but another technique that a tester can employ to solve a problem. It is one that is very interesting, vast in terms of possibilities and extremely useful when used correctly, but it’s not the pinnacle of the testing world.

The reason why automation isn’t the most important or the most relevant thing you can do as a tester is very simple. Automation doesn’t provide new knowledge about the application in most cases. It doesn’t uncover new corners that you and your team haven’t yet thought about, and it will very rarely, if ever, bring any creativity or any significant finding to your team. Automation is used to confirm that what your team knew to be true, is still valid.

It will save a lot of time when you have to repeat a set of tests, but it will also take a significant amount of time to maintain, and you will need to work in a very well-organised team if you don’t want to witness your tests exploding into pieces every time there’s a change to the UI (although, in some cases, a good automation engineer will know how to prevent these sorts of things).

There shouldn’t be a specific role for an ‘automation engineer’ — it’s making a very rich discipline awfully specific and focused on one thing. To extrapolate this idea, imagine if you hire a gardener and he says he’s great at lawn mowing, but he doesn’t really prune any plants or he doesn’t see the value in removing the weeds… or imagine a chef who only cooks ‘schnitzels’ and finds the rest either boring or not worth his effort. It wouldn’t happen. Testing for me is an art, it is something you either really like, or you find pretty dull. The really driven testers are the ones who discover their applications thoroughly using various tools and techniques. They will gather knowledge about their domain which will then help them make informed decisions on what the most effective approach is, rather than just trying to write as many automated tests as possible. They believe in the idea that they’re there to help their team build an amazing product, something that they — in collaboration with their team— own, in the same way their customers and stakeholders do.