A Love Story and the 5 Qualities Every QA Team Member Should Have…

On January 28, 1986, the NASA Space Shuttle Challenger broke apart 73 seconds into its flight, killing all seven brave crew members.

Did you know that a QA warning was written up, asking for a no-launch and for more evaluations, pointing out the exact o-ring component that caused the disaster? Did you know that the o-ring actually performed according to its design specifications, meaning it passed all the functional tests and if the shuttle had been launched on a warmer day or if the QA warning was heeded, it wouldn’t have exploded?

The wisdom Mythbusters gifted to geek culture states, ‘failure is always an option’, for software development that is; a space shuttle however, should be designed against all possible failures from ground-up. Shuttle engineers must be pessimistic.

I started my technology career as a curious journalist who, upon discovering, realized that the World Wide Web is a revolution he must be at the heart of. First language I learned was Shell Scripting and Perl (then HTML, CSS and JavaScript, then PHP, then System and Network engineering, then Java, then OOP, then TDD…and nowadays I enjoy myself quite a bit of MEAN stack … you get the picture.)

Over the years I have never seen a software without bugs, and a good engineer who assumes his work will fail. Even when every good unit testing start with writing tests to fail first.

I was in San Francisco, during the first ‘Dot-Com Boom’, working for Frog Design as a design technologist. When my boss asked me to describe what we do, because we were becoming more and more a software development, user experience design and digital media agency, I described our job as ‘designing and selling shovels during the gold rush!’, and got a big laughter back.

Because I was self-taught, and have never developed an app on an Amiga while my friends were playing outside, I often found myself having to translate what our client is really asking for to my developer colleagues and selling / negotiating why the developers couldn’t and shouldn’t implement a particular feature, to our client. When soon after I was captivated by the principles of Object Oriented Software Development and MVC patterns, and while the tech market was getting forced to respond faster and faster to demand and to fast-shifting market dynamics, I found myself thinking, there should be a position at the cross-roads of Product, Business, Development and End-User.

A discipline to keep an eye on the whole picture, all pieces and assure that the outcome would stand. That’s when I realized Quality Assurance would and should be that discipline.

Soon after, Agile Development Methodologies emerged and I found myself more and more passionate about QA as a calling.

In a 2017 report, tricentis.com found that in 2017, software failures cost the US economy, $1.7 trillion in financial losses. (Up from US$1.1 trillion in 2016.) Software failures at 314 companies affected 3.6 billion people and caused more than 268 years in downtime. IN ONE YEAR.

The day I read about the Challenger Incident, I also ‘grokked’ this: ‘When a system is in an unpredicted state, it becomes unpredictable.’

QA is important and QA is cool, you just don’t know it yet! (In other words: The unbearable burden, we the groovy must bear!)

I became a ‘QA Guy’ and never looked back. To be fair, my shift of career did not prevent me from the gratifications of writing code and instantly seeing the results of creating something, either. I was writing code to test code as often as writing a proposal on how to fix a defect that I uncovered or evangelizing why QA should get involved from the-get-go to prevent defects in the first place.

I have been seasoned up and down on my career ladder multiple times, but I still get the same rush and try to never miss an opportunity to write test scripts, to develop frameworks. (Probably why I am quite comfortable with going down as well as up on that ladder; as long as I am hands-on and working under the ever lasting pressure with the team in the trenches.)

I wrote everything above to lend more credibility to everything below.

Nobody is perfect and rock stars are hard to come by. The rest of us can always strive to be better and enable and encourage our team members to be on the path to rocking and stardom.

Over the last 15 years, I’ve come to believe that an ideal QA team member in today’s SDLC, must have the following 5 qualities. These are the Qualities I try to convey and seek in my QA team members.

One can have these qualities at varying degrees and can always improve upon but the total absence of any of these, is detrimental to assuring quality.

1. Diverse and real technical knowledge. You must be a generalist to identify and prevent problems (and technical debt) and must have enough knowledge of software development life cycle to first, understand what (and how) you are testing and second, gain the respect AND TRUST of other team members. (Trust is a must for ultimately assuring quality) You must keep your knowledge up-to-date. (Most projects are client-server applications with multiple services, dependencies, integration points etc. So never be content with black-box testing.)
   Learn the ‘stack’ don’t get stuck (at a layer).
2. A dogged determination and passion for figuring things out: Having a mind set and habitual inquiry for what makes software work, what would/could make it break, what is getting done, what is done and what NEEDS to be done. (A software QA engineer asks ‘what if’ more than ‘if this then that’ and you must already have ‘the how’. -See #1-)
3. Understanding and internalizing that QA is not getting a task done. It can not be doing what’s asked of you but understanding what’s needed to assure quality and evaluating what’s at hand with that framework. (You must have a holistic view of the project. Don’t forget about the car, drivers, passengers, road conditions, the load, the destinations it’s expected to hit etc, while testing the carburetor. It might ‘work as designed’ or ‘works at developer’s computer’ but does it work as intended or for what it will be ultimately used?)
4. Methodical approach, careful examination with attention to details, and patience. Never be content with assumptions but always check and validate. The passing of tests doesn’t mean the software works as needed / intended. The software should work in spite of our assertions on what would or could cause it to fail. (Read “Scientific Method” or the principles of “Test Driven Development”)
5. It’s a ‘balancing act’: Managing expectations, managing communication and managing time. Most of the time, QA activities involve a balancing act. Patiently, carefully and methodically analyzing AND prioritization of the work while not losing the sight of the fact that there is more to do and time is limited. This approach start from the get-go; i.e. when acceptance criteria is being defined. (For example: Pro-actively partnering with project manager / scrum master and the development leadership, saves everybody from falling into Rabbit Holes. Documenting findings will be the bedrock of regression. Did I mention that every step of the work should have ‘traceability’, accountability and agreement across the board?)

There is much more and I am just getting started.