There was recently a debate on LinkedIn about a subject which seems to raise the blood pressure of even the most placid tester – whether it is necessary for testers to be able to write code. I’ve tended to avoid getting too involved in these discussions although I’ve been aware of them going on. I was interested in how much of a hot topic this was, so I opened Google for a quick look.
I searched for ‘testers should be able to code‘ and was presented with many pages of results; mostly blogs, articles and forum discussions. The opinions offered can broadly be placed into three categories:
- Testers must learn to write code
- Testers do not need to learn how to write code
- I’m sick of us talking about whether or not testers need to learn how to write code
I’m not going to add to the pages of results by writing about testers and code. I think there is another subject worth discussing which gets far less consideration from testers; design.
For the purposes of comparison, I tried searching for ‘testers should understand design‘. There were no heated debates or polarized views. In fact I struggled to find much at all. There were a few links to Test Driven Development articles and lots of mentions of test case design but I was hoping for more because I believe we can learn a lot from greater exposure to how things are designed.
Last week I was involved in a usability testing session in our eye-tracking labs. We have some great equipment for usability sessions which allows us to observe and record exactly what the participants do when they are using a website or application. We even have a one way mirror (like the ones you see in cop shows) so that people like me can observe the session without upsetting the participants too much.
We were testing a web based survey which we have been developing in-house. We have designed it through an evolutionary process; piloting some elements, discussing what was or wasn’t working and then making improvements. It isn’t a complex website. In fact I had thought it was pretty simple to use. There are a couple of drop-downs, some widgets for capturing numerical responses to questions and some free text fields for comments.
This was the first time we had run a proper usability session on the website and we had four participants, all of whom are likely to be asked to use the website once it is fully launched. Their responses were fascinating. From just four participants we got some substantially different approaches to completing the survey.
From the first session I realised how easy it is to make mistakes in design:
- We had made many assumptions based on our knowledge and understanding of what the website was to be used for.
- We hadn’t clearly communicated instructions on how to use the website to the people who would use it.
- We hadn’t clearly indicated where responses were mandatory.
- Questions were worded ambiguously and invited misinterpretation.
We have lots of changes to make and lots of thinking to do about how people will interpret the elements of the website.
Why is this so important?
The debate about testers and coding is being played out on relatively comfortable ground for those of us with a background in IT. Whatever stance we take, we are talking about something we are familiar with and something with a technical focus. It is an insular debate. Go out into the street and ask the first person you see whether testers should be able to write code. You will probably get a blank expression at best. They may quicken their pace to get away from you.
But ask that person about a website or an app that they use and whether they like the design, and you may just find them engaged and willing to talk. Technology underpins so much of what we do that pretty much anyone you talk to will know what they like and what they don’t like.
When we are testing I believe it helps to keep this in mind. Understanding how people will use technology and what their expectations are will help us develop empathy. Understanding design will help us to focus on how well those expectations are being met.
Remembering that there is no such thing as ‘the user’, that there are in fact many different ways in which people will try to use something, might also help. The four participants in our usability session demonstrated this to me perfectly. Try thinking about different people and how they might use whatever it is that you are testing. Using personas to help determine the actions you take is a common technique in usability testing and one I think can be very useful.
I read a fantastic book a while back called ‘Don’t Make Me Think‘ by Steve Krug. I would encourage testers to read it and to broaden their understanding of simple and effective design. The book is focused on website design but there are lessons which I believe are valuable for many testers.
It would be great to hear about testers learning more about design. I hope that if you’ve made it this far you will look into it too. Maybe you can capture your thoughts on the subject, or if you are feeling particularly invigorated, start a heated debate on LinkedIn.
2 thoughts on “Designed to test”