The testing community can be divisive. We all have various ideas about what we think is the best way to test. But it's important to get along with people who don’t hold opinions identical to yours—and maybe even participate in an exchange of ideas. One tester looks back on his early days and imparts some lessons he's learned navigating the different schools of software testing.
I had been a tester for around three years, mostly testing the front end. After that much time testing from documents and test cases, I found I was no longer learning, and I yearned for more.
Someone left Lessons Learned in Software Testing on a desk and allowed me to borrow it, along with a few other useful books. Suddenly I had my first taste of context-driven testing. I felt like I had found a gold mine; I devoured the text.
As I read the other borrowed books, I realized they conflicted on theory and approaches. Still a new tester, I figured I needed to synthesize the ideas in order to see what would work for me. This is probably where I got my first glimpse into the fact that there is division among the testing community—although I wouldn’t realize this until later.
Over the next few years, I read more about the context-driven testing movement. I roughly agreed with a lot of what they said, but I still had no contact with anyone who practiced it. I had discovered Twitter but didn't really use it; most of the online communities I’d found were in Europe, and I wanted contact with someone more local. I’d started attending various testing meetups, but each had its own agenda and I did not really see any cohesion amongst them all. People were nice, but there was a lack of unity and purpose.
As I read blog posts and subsequent comments, it became more obvious that there was conflict between different schools of testing; some of it even reminded me of the flame wars so prominent in online forums. It was a little disheartening, and I still knew no one in any large testing community who could educate me about the different ways of thinking or help me grow as a tester.
One day, I finally got my chance: There was large testing conference being held in my city. It was my first conference, and it ended up being one of the best experiences of my career—and also one of the worst.
At last I’d found a place with people who were like-minded in their hunger for testing and bettering themselves as testers, but at the same time I quickly learned that I had to watch which words I used, or else I would be burned at the stake. If I said I was a QA engineer, for example, I could expect heavy criticism. People would tell me that there was no way I could assure quality unless I was actively changing the code, so the title itself was an oxymoron and anti-intellectual. In hindsight I now understand why, but to essentially berate a novice for not knowing something was a quick turn-off.
These folks were, by and large, not malicious. In fact, they were trying to help. But I do think they were a bit too zealous and rather quick to judge. On the plus side, I did meet a bunch of great people, learned a lot about testing, and left feeling renewed. I chalked those negative experiences up to the cost of doing business.
Today, it still amazes me just how divided the testing community can be. We all have various ideas about what we think is the best way to test. Some defend; some attack; some teach their beliefs via blogs, Twitter, or web seminars. I know that when dealing with large groups of people, there are bound to be disagreements, but that is no excuse for animosity. Testers face enough adversity from other roles that do not respect the profession; we don’t need to fight among ourselves!
It’s good to know how to handle stressful situations and get along with people who don’t hold opinions identical to yours—and maybe even participate in an exchange of ideas. In my short career, I have picked up many simple lessons:
Books are a wonderful source of information, but when you know little to nothing about a topic, be discerning about what you accept as gospel.
Don’t be afraid to blaze a trail and start your own thing. When I was looking for resources, I should have been more active online and contributed there until something local developed. If I was feeling alone and discouraged, chances are there were other testers that were as well.
Don’t berate someone who may not have the same knowledge as you, and don’t flip out if someone uses a term you don’t agree with. Instead, work with them, and if they are meek, teach them. Chances are they could even teach you something; you can learn from anyone, either what to do or what not to do.
Try to find a common ground with other people and work from there. Either elevate yourself to where others are, or work to elevate those around you.
Lastly, recognize that you don’t know it all. The mightiest CEO can learn humility from the maintenance man—plus the fastest way to sweep!
One of the sayings often attributed to Mahatma Gandhi is “Be the change you want to see in the world.” Testers might enjoy debating the accuracy of the quote, but the theme is clear.
This isn’t meant to be a rant to the masses, but more of an observation. If all the distinct testing communities were to unite under one banner, we could achieve so much more than we can fighting.
To reach toward that dream, I wrote this article.
What are you going to do?
Thanks Antonio! I really appreciate this post and I have felt the same way as you. This was really refreshing to read!
Tony, thank you for the reminder that I need to keep an open mind and that we can all learn from our peers - even those who are new to testing or new to conferences! I'm guilty of chiding people for using terminology like "QA". And I see that it is quite counter-productive and rude.
I *try* to share my experiences, rather than to preach my opinions, but I'm sure that I am guilty of the latter sometimes. I need to come back and read your post from time to time to remind myself that there's no reason for "schools" or divisiveness. We can all learn from each other, practice new techniques, try new experiments, see what works for our own teams in our own contexts.
Wise words, Antonio! Thanks!
Personally, I have a very strong opinion on the terms "test automation" or "automated test" because IMO they are the products of an unfortunate, yet understandable, historical accident, and they can lead people to make unfortunate choices that create risk and leak business value. (I've seen it happen in multiple settings.)
That's why I prefer to use the phrase "quality automation" which might seem subtle, but the implications are huge to what people can do for creating and shipping quality software that matters to people.
I definitely get your point that usage of these term does not reflect on an individual. Words are just labels.
Thanks Antonio, I have a similar story-- books, conferences and all. I found the path to survival is to read and listen to as many of the different schools and pull what resonates with you to use and share with others. I love the message - good for you for challenging the statis quo!
Great post! I love this idea: "...you can learn from anyone, either what to do or what not to do".
Very well put, Antonio. Communication is a lot more effective than infighting.
Good article, Antonio! I feel the same way. People can be quick to judge or dismiss someone without taking the time to listen and understand. We've all had a different journey as a tester, quality engineer, or analyst. The companies and industries we have worked in influences our choice of words and description about the work we do and we may gravitate towards differing experts and methods. That's part of what makes the field of testing and quality interesting to me - it's diverse and full of options. Let's all keep learning from each other and become better practioners of the discipline.
Nicely stated, Tony. Congrats on your first article!
If there is a type of work where efficiency is more essential than anywhere else, I would say it is software testing. It is always a challenge to defend the business value generated by the test effort, and you must achieve as much as possible, as cheaply as possible. To my understanding, context-driven testing says: don't stick to your beliefs religiously, but pick the test type, method, strategy, approach etc. that fits the context best, keeping focused on the bottom line goal, i.e. to have the highest probability of detecting the important faults with the available resources (time, budget and manpower). So context-driven testing is not really a "school", it says you should consider all possibilities and select what's best in the circumstances.
In my shop I always tell my team to keep thinking and don't worry too much about SOPs, policies, terminology or document layout. What really matters is that we find the bugs that the developers keep creating for us ;-)