These days we equate good QA with automated tests. But quality is fundamentally about excellent process. Here’s a common-sense, reality-friendly route to better quality, and better automation as well.

Quality is hard; quality is process

Development can fixate on completing individual tasks, and still be relatively successful. Quality, however needs an overarching process with good organization and vision.

Consider this $100 boutique fingerprint padlock, defeated by a magnet. Or, a military airstrike which destroys its specified target, only to discover later they hit a school or hospital. “We successfully destroyed the target requested.”

Specification and task success, catastrophic process failure.

Keep a list of your critical test cases, and keep it up to date

Stupid simple. So why don’t we actually follow through and do it ?

  • There should be a list of all your critical + major test cases
  • Someone needs to be in charge of maintaining the list
  • For a given release, know what from the list has already been tested, and what still remains

I personally love TestRail from Gurock software.

Spend the extra time to track your test execution

There’s a saying in auto racing, also in military Special Forces: “Slow is smooth, smooth is fast.” Be deliberate and the speed will come.

You’ll lose say 5-10% of raw execution speed. However you’ll gain it back in three key ways:

  • As documentation becomes a habit, you’re developing an expectation of thoroughness. This thoroughness has to be one of the most important professional qualities in the QA discipline.

  • Holding individual testers accountable, means that you’ll hold your test environments accountable as well. You’ll gain plenty of time back with better test rigs.

  • Better QA means means less bugs in production. How would you rather spend your time ? And when the inevitable bugs do get through, a) they should be less severe and b) you should have much more context and data for a faster fix.

Use TestRail, configure it well, maybe give your testers a tablet dedicated to just recording results. You’ll be surprised at how little time overhead you’ve actually added.

Slow is smooth, smooth is fast !

Developers should keep running notes for the QA team

As devs write code and implement features and new frameworks, lots of technical details will bounce about in heads or meetings of heads. Get developers in the habit of keeping a running notepad of implications for testing.

  • Rough notes are fine
  • QA adds new tests directly from devs’ notes
  • These notes can help QA break out of their current mental frame and think of additional secondary + tertiary test cases
  • More cooperation between devs and QA means better teamwork, a sense of inclusion and personal investment through better friendships + comeraderie

Which leads to another point about cooperation…

Actively foster spirit in the QA team

QA can be painstaking sometimes, especially if your automation hasn’t caught up with mundane tasks.

Counteract this by spending extra resources to develop a unique energy within the QA team. Whereas software development tends to be individually task-obsessed, QA is an opportunity to do engineering with a wider, more collaborative feel.

Rather than isolating an analyst in one area, rotate the testing around ! It will keep people fresh, and also reinforce point #1 of good documentation. Pair people up ! Let them enjoy some time working a mundane task with a partner in crime.

Work hard as a team and celebrate your accomplishments. Make the development group jealous that the QA team is having so much fun !

Invest the necessary time in a well-configured, fast ticket tracker

Writing up tickets is a core QA operation – don’t disincentivize a core task with a cumbersome ticket creation process. Your tracker should be quick, intuitive, easy to use. Keep tweaking until you’ve got the right balance of workflow versus ease of use.

Make your tools work for you, not the other way ‘round.

Speaking of which …

Automation: Set up for success

Writing automated test scripts is fundamentally a development undertaking, not QA. Your automation scripts and architecture will be buggy, your harness will be too complicated, your test developers will come and go and leave crappy code behind. You’ll need to test your tests.

Doing automation well is a whole series of articles, and your author has rather strong opinions on the subject. But for now let’s consider a few points:

  • QA testers often do not have a deep background or education in clean code principles.
  • Junior-level developers tend to be enamored with complex solutions.
  • Complexity is the enemy of any software endeavor – bugs cascading upon bugs.
  • Good QA process requires a wider vision to anticipate problems.
  • Developing tests tends to foster a narrow vision of grinding through individual technical problems until the script accomplishes its single specified task. In this scenario, when will you have headspace to think outside the box and anticipate edge cases ?

Be honest about whether your automation is working well for you. If it isn’t, change it up ! Keep researching, keep adapting, learn from others who are doing it better than you !

Which leads to another suggestion:

Leverage your development team to improve your automation efforts

Maybe your QA analysts aren’t professional coders, but your developers are ! So solicit their advice !

Better yet, why not invite an interested dev or two help your testers write code ? Maybe some pair programming ? Not only will your automation improve by leaps and bounds, but stronger individual collaboration between dev and QA means better vision, more testing ideas, and more bugs caught earlier in the process.

Review your quality process regularly and be willing to change

Agile retrospectives can be a good place to do this. Or maybe your QA group needs to do a regular offsite lunch, or rent out a ping pong hall. But be honest about your process – what’s working ? What’s a pain point ?

Assign people tasks to resolve pain points and follow through. And for management, be flexible and willing to change what needs to be changed !

Conclusion: Working culture

So much of a business’s success derives from its working culture. Changing a working culture is extremely difficult. Let’s consider a few points then in conclusion.

First of all, as is said in recovery programs, “The only way out is through.” You can obfuscate code, but you can’t obfuscate critical bugs that escape to production.

Also, changing habits is difficult, but it gets easier as the positive effects result in positive experiences. When your team sees better releases with less stress, they will develop pride of accomplishment and sense of identity. These feelings easily pay for the effort of the discipline.

Leadership is about helping a group accomplish what’s difficult. If it was easy, everyone would be doing it.

The only way out is through !