Those of us who have been involved in testing for a long time are familiar with the adage, "Quality cannot be tested in; it must be built in." This adage is true because testing merely finds problems. And although the defects that are found are usually fixed, the quality impact of testing is marginal. When a high-quality product goes into test, a high-quality product comes out. When a poor-quality product goes into test, a poor-quality product comes out (and the testing takes longer as well!).
There are a few software organizations that rightly refer to testing as "QC". They recognize that testing is an important mechanism to determine if quality targets have been met, and to prevent the deployment of a clearly defective product. Testing limits your exposure to the impacts of poor quality, but it does nothing to get the organization to where you want to be: producers of high-quality products.
If it is difficult for you to imagine what QA activities might be, you are not alone. Most software organizations have never engaged in QA activities, and so these activities are foreign to them. There are a few cases where QA activities are being done, but they are not called "QA". But those are the happy few. More often, these are activities that we know would be good to do, but we never seem to find the time to do them.
Let's look at some examples of QA activities:
When a team of individuals must work together, there is no substitute for agreement about how to do the job. Each of us knows what to expect from the others, and we can all rest assured that our performance as a team will excel. But even if you are a team of one, the consistency of processes and standards will help you to be your best.
Any shop that takes the time to agree on the best ways to approach the activities they undertake, and the content and format of the documents and code they produce will realize real quality benefits.
The best way to assure quality on the next project we undertake is to spend a little time learning from the one we just finished. What went particularly well? And how can we change that superior performance into our norm? What went wrong? And how can we prevent that problem from recurring in the future? What opportunities slipped through our hands? And how can we be sure to capitalize on them on future projects?
Project Retrospectives give us the opportunity to learn from our own experiences.
Once you have identified a type of defect that you would really benefit from fixing, start brainstorming: Can we adjust our processes to eliminate that defect? Or can we make it less likely to occur? Is there an opportunity to detect and remove that type of defect earlier in the project when it would be less expensive?
Each defect in your database has already cost you plenty! Why not see how they may be able to pay you back by helping to assure quality on a future project?
The best learning organizations include specific activities in their projects to ensure that they can improve based on what they have learned. Not only do they routinely do activities like those discussed above, but they carefully catalog what they learn (e.g., in a Lessons Learned database). And it doesn't end there, because their project initiation and planning processes include searching that database for pertinent information that can be applied to each new project.