I stepped into my first QA role in 2005 or 2006 while at Warner Bros. Prior to that, I worked as a web developer. Since then I have stayed the path and remained in QA, getting more experience from various positions at Yahoo!, Universal Music Group, eHarmony and Toll Free Forwarding. Over time I’ve been given a variety of challenges, from setting up basic web automation, to automating phone call quality. Beyond the tasks given me by my superiors, I’ve also carved out niches in Cybersecurity, to continue with my work and effort in the domain of something more challenging and interesting.
Overtime I have also trained and mentored QA people. Some people take to Quality Assurance and some just drop out. Having worked with so many people in different companies I’ve looked back and asked myself what I thought was their best traits.
Eye for Detail Isn’t It
I suppose the answer depends on the company. But in general an eye for detailed analysis is key. Someone who can spot an anomaly (especially subtle variations) in a product, is very valuable. That, however, isn’t what I’d consider the most important QA trait. In my opinion, it’s a runner up trait. It’s important, but it can be automated. Using visual automation (OpenCV) can spot visual anomalies and passing textual QA through AI systems can spot detailed divergences from what is expected.
The days of a detailed manual tester are going fast. Quickly being replaced by either automation or AI.
Creativity
The most important trait, in my view, is creativity. Quality Assurance isn’t thought of as creative. Often it’s thought of like bean counters. We’re like the auditors of development teams. Someone writes code and we come along to rain pain all over them. How many times do we find development teams that absolutely detest QA? It must be nerve wracking to have someone go through your code, find issues that need resolving and repeat the cycle over and over again… meanwhile the developer’s manager is giving them the stink eye each time their code is returned, potentially putting a launch date at risk. You know what’s more stressful than finding a bug in a requirement? Finding a bug that’s off script. Imagine telling the developer, “the requirements check out, but I can do a DOS if I pass in a %5C in the url parameter.”
That stress I just described is how I remember the process at past companies. I’m thankful that today I work with people who respect the QA & DEV process. However, companies that have fast moving sprints (1 or 2 week turn arounds) tend to have stress put on teams to deliver and managers are always looking to replace poor performers – which adds to the whole stress and enmity between QA and development.
Creative without Requirements
While it is important for QA to analyze requirements and compare what is delivered to said requirements, what if the requirements are not delivered? What if development was by word of mouth? What if the requirements changed verbally and were not updated? What if the requirements couldn’t be implemented due to technical constraints? If one is too analytical then like a robot, they stop and throw a red flag on the field of play. A creative QA person will roll with it. They’ll check with the appropriate people and make sure what was delivered is good to go.
Creativity Beyond Requirements
Requirements may be delivered, but the creative QA may dig between the lines and find faults outside the initial scope. Example: A developer has the requirement to implement a file upload from customers. Customers can upload JPG, PNG and PDF files. An analytical QA person will go over the upload process, validating that no other file formats are possible, and insure that the requirements are met to a tee. But a creative QA person will try something out of the box, like: adding a trojan backdoor to a PDF and see if it uploads without being compromised by server-side antivirus. That wasn’t even in scope. It’s a creative work.
Being creative is future proofing.
Analytical QA is replaceable by automation. Ultimately the analytical manual QA tester’s role is turned over to a machine. No matter how technical, if the role is a step by step process, well it can be coded and automated away. Today, there’s still a role for the Software Developer in Test – or Automation QA. That person can keep writing scripts and test harnesses to validate quality control. Yet it’s the creative QA member that I believe will be better future proofed.
Maybe at some point creativity will be inspired by AI testing scripts, but right now it’s something very human. The “what happens if I do…” question is very valuable, but almost never probed in an interview. Interview questions are typically mind-busting code questions, complex automation questions, questions pertaining to the SDLC or some archaic Waterfall Test Plan document. When’s the last time someone asked an open-ended, “here’s a set of requirements to test a file upload, what do you think you should test,” and is looking for something more than the basic use-cases or edge cases?
Many years ago I had a job to automate something complex. The QA team had a Java developer in test. She was good. Very good. But because this new automation goal was outside her wheelhouse it stumped her. The solution turned out to be creative and not analytical – she said, “it can’t be done.” But we did it. It just took a bit of “out-of-the-box thinking.”
QA evolved from manual testers, to Jr. Developers writing test scripts, to Sr. Developers writing automation frameworks or even reviewing code… but now I think we need more creatives. People who think like penetration testers, but have a scope in software quality. Where the mindset is back to the green fields of “what if,” and less about “this is what.”