|Excercise from the TestLab at Eurostar 2014
Should Testers be able to code?
Funnily enough this topic was just reinvigorated since I started to write this a few days ago. There is an interesting and in depth article here from Simon Knight and also an interesting perspective (that I share) from the designer community.
Why did I want bring this topic up?
Well I went to my first meet up organised by http://www.codebar.io In their own words this is their goal:
“Our goal is to enable underrepresented groups to learn programming in a safe and collaborative environment and expand their career opportunities. To achieve this, we run free weekly workshops, regular events and try to create opportunities for our students making technology and coding more accessible.”
I decided to to go because my good friend and awesome tester Emma K (@EmJayKay80). said she was going and if she was going to sit on a 1 hour bus journey on one of the hottest days of the year I could do the 5 mins train journey down there. (that was my thinking and my own kick up the butt to go).
How does codebar work?
Codebar holds their weekly Brighton meetup all over town, often in software companies’ offices which is also great from a nosey perspective! I love seeing other people’s work places.
The structure is that people turn up, mentors and students, and chat and mingle for half hour while eating delicious pizza (I think it came from pizzaface and was amazing.)
I had an awesome time, learned a lot and will definitely go again!
Why do I want to learn to code/about code?
Now I am a tester by trade, a manual front end tester who only recently started along the way into the realms of API testing and performance testing. Why do I want to learn to code.
Mostly to aid my manual testing. If I can create throwaway automation or scripts to do stuff for me which will save me time and free me up to do more manual testing then I have won.
Understanding or knowing about code, its quirks, weaknesses and strengths can help in test design, in my opinion.
The referenced articles also talk about empathy. Understanding what your colleagues do and understanding about their tools and therefore being empathetic can help the team work together better. I fully agree with this. Hence I also try to encourage developers to listen to test talks and share other literature around.
Currently we are moving towards a continuous delivery model and this means there will be an element of a testing consultant role that we as testers may need to fulfill as the developers will automate a lot of the tests and if I understand more about the code I can potentially advise more on what tests may be appropriate/relevant and ask the better questions.
Domain knowledge be it of the field we are in or the tools we are using is very important for testers to gather to be effective, in my experience.
But there is a fine line where testers may become bad coders and should we not just let the experts (programmers) deal with it? Also maybe you end up spending so much time with code at not do anything else?
I have certainly experienced this moment of “oh I automated this thing, now let me just do this other thing… oh it is 6pm and the office is empty and I haven’t tested the story that is waiting”. We can get distracted by new skills, and being a tester I can get quite involved in trying to understand something beyond the reaches of which I may need to, just because I am being nosey.
We currently are using the analogy of the swiss army knife a lot in house and it just so happens this is also echoed in one of the articles above.
We want to avoid to become swiss army knives as this means would have a lot of basic knowledge but do nothing particularly well or effectively.
However doing just enough (which will depend on your context) to understand some of the concepts of the coding languages your teams use means that you will share a common language and hence be able to communicate better.