Two things have helped me succeed in the IT Quality Assurance world: curiosity and humor. Being curious is a requirement; QA must go above and beyond the written requirements to ensure the product is at its best quality. And as with almost any undertaking, having a sense of humor enables me to have good productive relationships with my team members.
Being curious is a requirement in many IT jobs, lots of “What-ifs” and “What happens if I do this?” As a software testing professional, it's imperative that I understand every aspect of the software lifecycle. I need to know what the stakeholders need/want, I need to understand the written requirements, I also need to know about decisions the developers have made. I have heard it said more than once that QA also stands for Question Asker
One of the primary roles of a QA consultant is to ensure that everyone on the team has the same understanding of the software and the change being requested. By remaining curious and asking good questions, our team gets beyond the requirements and code. As a result, the team becomes more aware of the importance of quality and begins anticipating our QA consultant's questions throughout the build process. I’ve heard more than once on a dev team, “Did you code for this, because you know QA will test it.” They learned from the questions the QA team asked during story refinement and also when testing the stories. The dev team was able to start finding issues earlier, rather than having to do rework.
Curiosity once led me to an innocuous issue where a span of time should have been displayed as 20 minutes, but instead, it showed up as '1+403E.' Excuse me? So, I decided to ask the developer about it. Turns out, my data decided to take a wild ride from AM to PM and then back to AM again, spanning over 12 hours. It seems the field was not large enough to handle such an adventure. Thankfully, my curiosity prevented that bug from making its grand entrance into production.
In my experience, using humor has often helped everyone involved recognize and address issues without becoming overly defensive.
The best teams I have worked on are all interested in a good quality product. Much more so than being defensive, annoyed or insulted by my questions. The inverse of this also holds true. Some of my worst projects have been when I had to face those defensive developers who insist, "That's not my code!" or “I didn’t touch that, not my problem to fix.” Well, as much as I appreciate their enthusiasm for self-preservation, it's not going to get us to the quality product we all want. We're in this together, folks!
I remember testing a report once that showcased this incredible downward trend. It was truly a sight to behold! However, upon closer inspection, I realized that the data was sorted by instance, not by time. I couldn't help but burst out laughing. The developer had been so focused on showcasing trends that he forgot the fundamental concept of displaying things chronologically. I'm pretty sure I was laughing when I asked him about it, and that laughter was contagious. He laughed, too and quickly fixed the issue.
Humor can certainly lighten the mood and make the journey towards a quality product a little more enjoyable. After all, who says testing can't be fun? Also using I statements help; “I need your help understanding this data trend” or “I’m not seeing the results I expected” will get you much further than saying “You messed this up!”
During my time at Ingage, approaching work with curiosity and humor has served me well. No matter what project (ramping up new QA teams, defining test strategies, or creating QA roadmaps) or role I have played on a project (automation, manual, BA etc.) these themes have led to project successes over the years.
So don’t be afraid to ask the questions you might have. The earlier the better. The more questions you ask, the more issue will be exposed. And if you have a defensive team, be sure to use “I” statements, your smile and your best good humor. Even if you are remote, people can hear your smile, even if they don’t see it.