Leave Your Ego at Home: 99 Ways Workshop #77

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

Suggestion #77: Leave your ego at home - maybe that amazing bug won't get fixed before go-live. Trust that the person making the decision knows better than you. - Amy Phillips

What are we really asking here? This is an important aspect, not just of testing, but of anything that we would want to do. It's imperative that we learn how to be more effective with each other and to give each other the ability to do the best work that we can do. 

There's a little bit of ego in all of us. Let's face it, we all want to be acknowledged for doing good work. We all want to know that what we do matters. We want to feel like the time we spent on a bug, configuration issue, usability test, or "fill in the blank" was worthwhile. When we are told "thanks for that information, but we've decided to go and do something else" or "that's very helpful, but it's out of the scope of what we need to be doing", it's natural to feel frustrated.

While it's important to "check the ego", there's more to it. When we actually do check the ego, we can start to look at the situation more objectively, and then we can ask "why did that issue get deferred?". Often, the reason is "it's not important enough to those that matter to prioritize". 

Let's think about that for a second. Who are "those that matter"? We naturally think "our customers, of course"… but remember, we have more than one set of customers. Learning how to get the attention of the closest group "that matters" can help us considerably.

Workshop #77: Get in the habit of reading and researching the announcements that are made from the "Chief" list (C-List) of officers in your company or organization. Check to see what the priorities really are. Look over the Engineering reports made to the C-List, and see what the replies back are. Focus on understanding the priorities from these communications, then act as though the C-List are your customers… because they are.

This may be challenging for a front line tester. You may not necessarily have this information directly shared with you. If you don't, ask your test lead or the test manager to share this information with you. Learn the Domain Specific Language (DSL) of the Executive suite. Learn to see the nuances and the little details that can help you determine what is really going on, and what really matters to them.

Why is this important? It puts us in the mindset of looking at what is most critical to one of our most important customers. Wait, isn't our most important customer our users? In many ways, yes, but ultimately, the top consumer of our work is our own company, so learning what gets the top brass' attention is vital.

Once we have a clear (or as clear as possible) understanding of what the business actually values, then start looking at your application from that perspective. Instead of thinking "this is an issue that our customers will be frustrated with" try to see if, along with that, there is also the possibility that the executives would also be irritated/frustrated if this were to be seen. 

What areas will really get their attention? Performance is a big area to consider. Security is hugely important. User experience is valuable, but is often one of the first areas to be deferred (unless, of course, it's one of the execs that considers it unusable). Spelling errors are often items that really get an executive irritated, especially in things like End User License Agreements. I learned this a number of years ago when, because of misspellings and typos in the legal agreement, the net result was the fact that we had created a loophole where we were making a tacit agreement that was never intended (and that we would be liable if something were to happen if the users did not do the steps necessary). 

These areas are not glamorous, and sometimes they can be quite tedious. While that may be true, these are also areas that are considered most likely to impact revenue, and therefore will be given close scrutiny by executives. If we are taking the time necessary to look in these areas and report on what we see, we will probably get more traction and movement on these issues. Why? Because these are the issues that really matter. It may not seem fair or intuitive, but you can almost never go wrong reporting and championing bugs that the CEO has mentioned will be problematic for them if they were to be released.

Bottom Line:

This particular suggestion may feel a little cynical, but it's not meant to be. The fact is, we need to be able to anticipate and consider the issues that matter to our customers, and we have more customers than just our users. By looking up a few layers, and getting used to the language and the real concerns of the executives, we can focus our view, and start looking at issues that will really get attention.


Even if we do this, we may find that our "brilliant bugs" will be deferred, pushed to a later release, or dealt with in a different way than we might hope. Ultimately, we need to be dispassionate, not take it personally, and see where we might need to retrain our vision to get to the bugs that won't be deferred.