Testing Principle 4: Role
We believe testing is an activity of cognitive thought and experience and cannot be replaced by tools even though it can be helped by them.
From my observations over the last decade I have seen a huge emphasis on Automation skills in typically testing roles. Job descriptions are covered with things like selenium, scripting and being able to automate. It is as if they are trying to replace the testing role with an activity of automating. There seems to be a lack of understanding that testing is an activity of cognitive thought. We are using our brains and thinking a lot of the time to investigate and dig deeper.
Automation is an activity not a role
I attended a fantastic talk by Bas Dijkstra at ExpoQA on his keynote talk “Do we really need a Test automation engineer?” There was a quote on his slide which I felt articulated my thoughts on this topic.
It was on the lines of how Test Automation is NOT a role, but an activity.
Automation has value if the right strategy is in place
I have to be clear that I am in no way anti-automation. I believe it has huge value if done in the right way. In my experience and observations I have noticed that some of the Test Automation we do is a waste of time. For example, we are automating in too much detail or automating at the wrong level (e.g. should be api level instead of UI) or automating functionality that no one is even using in production (more on that in Principle 6). We need to be thinking about our Automation Strategies. Without people who can critically think about what we’re doing — the automation we are doing might be simply a waste of time.
Industry pushing for more Automation skills
In the past as a Test Manager I have had stakeholders above push for automation. Requesting all the new people we bring in have automation experience and skills. Also, pushing for the upskill of our existing team. It is an interesting direction because they still question production bugs and ask how we can prevent them in future.
I’ve personally felt pressured in the past to upskill and focus all my efforts in automation. I did a fair amount like learning about Object Oriented Programming (OOPs), selenium, specflow/cucumber and so on. I can download the code and make sense of it. I find that this type of activity is all consuming, so I find it difficult to do both the testing skills and automation. We only have so much time in a day!
In the past, and I’m sure I’m not the only one with this. I have questioned my value. If I’m not an expert coder do I have a place at the table? The answer is simple — yes we do! As I said before we need people who can direct on a sensible approach to automation. This is where our prime testing skills come into practice where we can critically think about automation. Like understanding what level to put automation — if any at all — and question the value it has. I also believe if we absolutely have to automate — with our testing brains, we can achieve anything.
Overall though I feel l I’ve personally got to a point where I know my value. I’m not going to waste time justifying my role. I am going to demonstrate my role by doing. As the saying goes ‘The proof is in the pudding”. You can show your effectiveness by demonstrating what you do.
What has helped me lately is coming up with some mantras. One of my favourite is “fight the good fight”. I’m doing the right thing by the company, project and team. There is more on mantras in my previous blog post. https://fishouthebox.medium.com/fight-the-good-fight-d485890f54bc
Thanks for reading the 4th in the series. Next I will be going over the theme of visibility.
Previous in the series:
- Risk > https://fishouthebox.medium.com/principle-1-looking-at-the-bigger-picture-with-risk-46feddd8f827
- Purpose > https://fishouthebox.medium.com/principle-2-purpose-why-are-we-building-this-product-and-who-are-we-building-it-for-cd765f020e91
- Empathy > https://fishouthebox.medium.com/testing-principle-3-empathy-fc63b0680793
