Lessons Learned Navigating the Conflicting 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?

User Comments

Antonio Gutierrez's picture

Everyone thanks for the feedback and support! It is much appreciated!

July 5, 2016 - 3:43pm
Janet Gregory's picture

Tony, I've read this a few times now, and it serves as a great reminder to all of us to be open to ideas of those around us, and watch what we say because we never know the impact we have on other people. Thank you.

July 9, 2016 - 9:16am
Jackie Nichols's picture

Great article Antonio - very insightful and positive with valuable lessons to be learned.  

There are definitely many different schools of thought on software testing.  Lack of respect for it, corporate culture, different platforms, made for different industries, are all factors, among other things.

In my position, I cannot automate much of the software testing I do - because I have to test it with the proprietary smart-cell driven industrial printers our softwares print to, and with many different label materials (heat shrink, permasleeve,  static dissipative, chemical & heat resistant, metalized, RFID, etc).  Here quality does matter - are the barcodes scanable?  Does the print come off easily? Does the label come off easily?

I too found a conference (StarWest) extremely beneficial.  I remember talking to a tester for insurance software.  I thought to myself that it would be much easier to learn and become an expert software tester if I didn't have to worry about print drivers, printers, labels, print quality - and the many different industries our products are sold to.  We make labels for Military, Aerospace, Manufacturing, Datacomm, Electrical, Medical Laboratories, Facilities Management, Food & Beverage, Chemical manufacturing, etc.  And labels and signs for these industries need to meet many different regulations (MIL Specs, OSHA, CFR, ATA2000, etc). 

Being open to learning, other perspectives and trying new things makes for being a much better tester (as well as a person). 

July 12, 2017 - 10:42am


About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.