How to think of QA

Supppose you had a Friend.

You know, pretend you are back in school taking some really hard courses with difficult assessments. Now suppose all your friend did was check your homework before you turned it in.

How would you feel about that? How would it change things?

It is odd that all Software Developers do not feel this way about QA. But you can tell the Software Developers who have reached maturity because they understand QA is their best friend. And over time they have figured out the homework check dynamic and it changes the way the operate.

Clearly it is next to worthless getting your homework checked right before the bell rings. If your friend finds anything you will only have time to change the most simple stuff, spelling, plus or minus sign, grammer, elimination of extraneous solutions. If you have something fundamental wrong you may need to change everything.

The first step towards QA acceptance is when Software Developers start proactively getting their code to QA early. Some even start to pester QA to test their stuff first. QA loves this. Just like your friend who checked you Algebra homework in highschool, everyone likes to be needed.

The next phase follows naturally, Software Developers start getting their work to QA often. As Software Developers mature from a Feature focus to a Bug focus on their work they realize, it is easier to get Feature implemented Bug free in isolation. As such they want each individual Feature tested as soon as it is available. They also soon encounter Daisy Chain Bugs and Regression Bugs.

Daisy Chain Bugs, Regression Bugs, Requirement Bugs and more exotic Bugs takes us into the realm of Software Development Management. Software Development Managers that have reached maturity understand how critical good QA is to sustained success in software development. The key their is the sustained. It is possible to get lucky and implement a bugless feature. The difficulty arises when you want to add another and add another. The final maturity revelation that is reached is that:

Good QA can save you from bad programming, but no amount of good programming will save you without QA.