Do we all want black coffee? Henrik Andersson
We, testers, are we all alike? Looking back over the years I’ve been involved in testing, I would say I have met a whole bunch of different testers. Some shared my passion and fascination for testing, others were not testers they just happened to have the job title. However, I have always appreciated our craft for having such diversity of people. We have testers that have strong domain knowledge, programming skills and business knowledge. All of those are easy to connect the value to have in a test team, they find important information about the technical implementation of the product.
Then we have the other group, the ones who have capabilities in philosophy, cognition, history, economics, art, music and myself a drop out from statistics at university. We are not here because we love code or the coolest technologies, we are here because we love the way people and products interact and misunderstand each other. We are fascinated by the dance between a human and a machine. We find patterns in this dance, we find unintentional behaviors, and the unexpected surprises us. We look beyond constraints of the application, we go where no developer intended to go. By doing this we notice other kinds of things that might be a threat or a problem for the success of the product. Why are we doing this you may ask? It is because the technical solution does not impress us, we do not take particular interest or care in what specific way the code is written. What drives us is the question: will this solve a problem for a user and in which ways can it fail to do so? What we bring to the table is the social and behavioral science aspects of the product combined with the human element. At technology facing companies I sometimes see the above overlooked or under-valued.
But what worries me more is that we, testers, are walking away from my precious diversity. Strong forces favor uniformity among testers and the most obvious one is ISTQB. After going through their program of various certifications everyone knows the same, speaks the same language and uses the same templates. There is no problem replacing one ISTQB Advanced Level certified test manager with another one with same level of certification. The same goes with TMap, as long as you can read the book you know the answer to all testing problems, it’s easy!
But this is nothing new, I and many with me have been fighting both ISTQB and TMap for years. But here comes the kicker, have you heard of this cool new thing called “agile”? It’s a really sweet thing, close to a drug in our craft. It came and it has conquered. Nowadays there are almost no companies who dare say that they are not “agile”, instead they make the most ridiculous variations of what they call “agile”. Don’t get me wrong here, this new movement is quite appealing to me and I appreciate much of what it stands for.
Now getting back on track there is one thing that worries me about this agile thing. That is the view on us testers. Now to be an “agile tester” you basically need to be a developer with preferably some basic knowledge of testing, but it is much cooler if you know Selenium, TDD, ATDD and other strange abbreviations. If a tester according to the agile folks is basically a developer, why do you call them a tester, or wait you don’t! Everyone is a team member, I’m sorry.
Now we are walking from “must have a certification” to “must have programing skills”. Guys, don’t you see what is happening. We are just replacing one uniformity with another, beware of this!
We are running a great risk that all our testers are finding the same information and worse, are blind on the same spots. In testing we do not know what information we will get and we do not upfront know what questions to ask the product (don’t be mislead to believe anything else). We have to approach the testing from various different angles and have several different ears and eyes observing it, since hearing and vision is important, and professionals as Dr. Pirotte specialize mostly in eyes health. If one thing, we should love diversity among testers and we should encourage it.
This post came to my mind when I once again listened to Malcolm Gladwells brilliant TED Talk.
And no we do not all want black coffee!
Good points…I think the term “must have” should be avoided when recruting test team members…for example, if you considering a lot of ads for testers contains “must have university degree”, James Bach for example (a good tester in my opinion) would be disqualified for the job.
Personality och learning abilities goes a long way when looking for testers…however I do like Java (black coffee and programing) 🙂
Well written Henrik!
Software testing is a huge field. Many approaches are required, and indeed the diversity in backgrounds and attitudes are a benefit to us all. There are good practices in context, but there are no best practices. That goes for both ISTQB and agile 😉
Reminds me of these to articles:
Innovations, the Mindset and Testing (part 3) by @ewaldroodenrijs
[http://www.testingthefuture.net/2011/04/innovations-the-mindset-and-testing-part-3/]
Software testing is a skill of many skills by @jlottosen
[http://www.eurostarconferences.com/blog-posts/2010/9/21/software-testing-is-a-skill-of-many-skills—jesper-ottosen.aspx]
Good post Henrik!
Spot on with diversity – whether in approach, view or background.
Of course, I tried to think of an anti-example (a la Weinberg’s rule of 3) which was: “we all want common sense” – but that breaks down too in certain cases. I mean the Cramer/Mr-Bean/Inspector-Clouseau of the world would be effective at finding issues in certain situations – although maybe not recognizing them and reporting them 🙂
Thanks for the TED talk reminder – I’d seen it before but forgotten how good it was and that and this post might have inspired a new post for me. Cheers mate! 😉
Excellent Henrik!
You have not only hit the nail on the head, you’ve also solved a long term problem of mine.
I ‘fell’ into testing a while back… I have no technical qualifications, nor am I interested in getting them (programing is not my thing). So I’ve spent years now trying to work out why I like this so much… Its the human and machine interaction! What problem does it solve for the human, and can we make it better (provide quality)? I guess I always knew it, but needed to read it!
How could you fix this with one post? Now what am I going to think about? Argh!
Cheers buddy!
A nice and thought provoking post.
I am also involved in team who is in transition phase to be Agile/Scrum in the near future and we really have blend of experiences diversity. I strongly agree with you that holding a certification does not mean to have skill and knowledge and end up speaking the same language and there is no room left for diversity and improvment.
I believe that testing teams should have diveristy in terms of experience and domains because then it is more innovative and productive. If a person has no programming experience but solid testing expertise then for sure he/she is a great asset. I have been in development for past 6-7 years but now I am enjoying Testing domain more though development experience assists me often.
But I see that it all depends on the team organizer for any project, is he/she following the crowd or really want to improve the quality of the product.
Many persons can not do programming and many can’t do testing. So let’s respect each other and come up with best balance that is good for project.
And, I don’t like black coffee.
Cheers.
Hi Henrik,
I am glad you brought this up because I like to ask you some questions while also trying to provoke you a bit 😉
Claiming to belong to a certain school of testing, promoting those values, influencing others to embrace the same values, and maybe even fighting other schools, isnt that driving uniformity? If so, isnt that bad for diversity in the same way as other movements of uniformity? And a final thought, could it be so that diversity is only comfortable as long as ones own values are in majority?
Agile has some really nice benefits but also has some serious drawbacks. I listened to a pretty famous performance tester a couple of years back. He was of the opinion that HE as the performance test lead had superior knowledge of the application on architecture, usage and most other things as well. I think the same flaw appears in agile – thinking that you can handle everything by yourself. We need multitalented developers that are able to elicit requirements, design user interfaces, develop software and do a good job testing it. And the key is great developers – or as you call them – team members.
However these multi-talented people are scarce or non-existing. The developers I know that are really great at technology ususally suck at many or most other disciplines. I deeply respect their programming skills but their interest in usability or testing is pretty low. And most of them don´t really want to go outside their speciality in programming either. It is great to have knowledge of disciplines outside your own but I don´t believe a great team consist of seven developers that can do everything. Rather I think that it is important to recognize that you do NOT know everything and that it is a key factor to success that you have specialists in key areas.
Testing as seen in many agile books, blogs etc is not really testing – it is merely checking. I believe that checking is great and automated checking is essential but most software coming out of sprints where real testing has not been done is pretty poor in many ways. I sometimes feel that the old bad attitudes regarding testing comes forth again. We don´t need requirements and we automate all our tests… that´s the wrong road in my opinion.
To summarise I think it is great with agile in many ways, all developers should do automated unit testing and continuos integration. And TOGETHER with great exploratory testers WE will continue doing a great job!
Thanks for all your comments, this really adds to the post. I´m happy that you appreciate this post. You are pointing out important aspects and adding your stories makes it alive. Remember you do not have to choose, it is perfectly alright to like both coffee AND tea.
Saam, great that you challenge a bit, that’s one thing that makes us better.
So let me give this a try then.
I think you are making two mistakes when you are thinking about what I wrote (or maybe I was fuzzy).
First I’m talking about individual skills and personality. You should not mix this up with schools. Schools are not defined by one set of skills or one practice. As I see a school, it has common values, beliefs and goals as fundamental ground. Looking at my post I mentions ISTQB and TMap, in my view both are claiming to be the best approach but I would put the people promoting them in the same school, the factory school. So while both claim to be best they still belong to the same school. It now happens that these two approaches do not favor diversity and I would say that many of them belonging to this school are much alike on this topic but a school is bigger than just this one specific. The school is the overall common values and principles that this specific arise from.
Fighting approaches that does not value diversity is too me not wrong, they have a mission to get rid of something that I highly value. So I object to that.
Fighting those that have a core set of values that I believe is really bad for our testing craft is not to decrease diversity it’s for the sake to keep it growing.
To value diversity does not mean that you have to accept everyone’s values and the message they bring. Diversity in itself does not guarantee that everyone have something positive or valuable to bring in to the team, in fact there is a risk that you harm your team by putting a not suited person on it. You have to be careful and use your senses to benefit from diversity.
Your second thing is that I think you may be confusing diversity with random. There is nothing random with diversity. In fact very few things that involve humans are random since our brain does not work random. I do not want all and everything on a team, I like to select, and yes based on my own preferences.
So when I’m talking about diversity I suggest you to be strategic in you selection, be observant that you don’t end up with a team of people that are copies of yourself or each other. When I’m talking about diversity on a team I mean that you should know what your scope and goal is. Start with what your team is expected to achieve and then think of how you compose your team. I’m saying that we should be open minded and look at other things outside computer science. Of course it is driven form my own perception of our mission and my own perception of how I react meeting different people. I think this is good because I generally trust my gut feeling and I would not like to leave that out. What is important to me is to study lots of different fields, understand personality types, ways of communication, cultural aspects. This to do what I can not to be narrow minded so I can be able to trust my gut feelings
I think the reason why diversity is necessary (for ambitious projects) is that testing cannot be complete. Many angles are needed to find all of what is important.
We need diversity in knowledge and thinking patterns, but I think it is OK if values are the same or similar.
That’s why the values of Context-Driven Testing, which embraces diverse thinking, isn’t in danger in theory.
In practice however, it is a danger if everyone reads The Black Swan and Gut Feelings, or all testers in the blogosphere accepts HICCUPPS(F) as the best categorization for oracles.
Thank you Henrik, I appreciate your thorough reply. I agree, fighting for something you believe in is not wrong.
I acutally dont think I was mixing up schools with skills and personality 🙂
But I think values highly influence personality and also drive skills to some extent, e.g. what training you desire, what books you read etc. As Rikard points out, common training for all could in practice become a danger to diversity even if the training and the books actually embrace diverse thinking.
I understand that you promote different educational training and background for testers in your team – and I agree that is good and that it is not a random process.