About QA and workplans – it always takes more than you have

by daniel on February 6, 2009

After development cycle comes QA, this is common in commercial software development. The QA cycle has specific goals: check the result according to specifications, check for abnormal behavior and try to “abuse” the system in ways the end user might do for stability assurance. My colleague Shai has a blog explaining the different goals of QA. This is the theory, but as we all know, theory in practice is somewhat different.

In practice QA is a mix of conflicting tasks:

  • Recreate the requirements
  • Create the end user abuse
  • Understand the actual development
  • Integration of the development
  • Generate simulated and real data to test upon

On top on these, there should be also prioritization of the tasks and communication of the findings. Mix it all together and the QA becomes a bottle neck, delaying the release of the software even more.

The management perspective on QA, due to the reasons above, is that QA hinders the development and is a nuisance more than a benefit, in turn causing the management to decrease the investment in QA and thus increasing the numbers of problems found by the customer, creating a negative feedback loop.

How do you get out of this loop? How do you create a QA that is effective, streamlined and can actually provide a benefit to the company?

There are no easy answers, but there are general guidelines:

  • Have a process: for the requirements, for the development documentation and for the QA.
  • Allow for enough time for thing to settle: there is a minimal amount of time to coordinate the software components before they play well together – i.e. integration time.
  • Spend time educating the QA management on the process and the priorities while carefully pruning misguided tasks.

Since we are talking of software systems, remember that there are some common misconceptions and pitfalls; programmers are optimistic and the timeframes will be longer than expected, same for QA planning and execution.

The QA group can be a real asset, built and maintained correctly as described by Joel on software. Even more important, it can help the company reach the proclaimed goals by helping the company define the goals and communicating them at various levels.

Comments on this entry are closed.

Previous post:

Next post: