I recently found myself retweeting a tweet by Alan Page on Twitter which struck a chord with me. It led to some interesting discussions and misunderstanding as to what point I was attempting to make. I tried to explain my reasoning but the micro-blogging platform didnt prove to be an appropriate space to air these views so I have decided to get my thoughts down in a blog post.
DISCLAIMER: Alan went on to say some other things in this thread that is not aligned with my way of thinking. Testers can and should be involved in writing test automation. Test Automation – or on a more high level, writing code, is great skill for anyone to add to their toolkit.
So why did I retweet this? Test Automation is supposed to be what we all strive to work towards, right? Well, I think the key line in this tweet was “expert in testing”. Coding is not testing. It never has been and never will be.
My keys to expertise
Testers need to explore, testers need to identify risks and most importantly testers need to talk about testing. The last point seems so obvious but getting better at talking about testing, helping product owners and developers to understand what value testers can bring to the table is so important.
How does this tie into automation?
Test Advocacy encapsulates talking about automation with the team. Questions like the following are what we, as testers, can help answer: –
- What should we automate?
- What shouldn’t we automate?
- What level of automation should we employ? (Unit, Integration, UI)
None of the answers to these questions needs a low level understanding of “how to write code”. They need an understanding of testing as a whole (see my blog on what is testing?). I have worked with developers who would quite happily try to automate me out of a job (and perhaps, themselves) but that really isn’t what automation is about. Testers are the voice of reason that allows us to stay focused on keeping the testing we do valuable.
If I have tests I want to automate then I can automate them (if I think it is valuable to do so). However in an agile development team I should be able to rely on members of my team who write code on a daily basis to assist me in putting my ideas into practice meaning they can help bridge any potential skills gaps I may have.
The important thing to note here is that the critical thinking we do as testers in terms of deciding what we should/shouldn’t automate was done before a line of code was even written. If aspiring testers focus on learning “how” to automate tests the understanding of “why” we automate tests may never develop, leading to poorly conceived automation.
Learn to write code, yes. Learn new skills, absolutely! but do not neglect the art of studying software testing as a craft in order to better inform our test automation decisions.