Review By: Cathy Bell
08/15/2002In the preface to this book, the author writes “Data processing, once held in awe by most people, has now become the scapegoat for many organizational problems.” And most would agree that quality assurance could quickly become the scapegoat for a myriad of IT problems. If a project runs late, QA took too much time testing, and if a bug is found after a product is shipped, QA did not do a good enough job of testing. This book is designed to arm Quality Assurance with the practices to develop an effective process that will “steer project development in the right direction”(21).

This book was written in 1991, but the practices discussed are relevant today. There are a few references to out-of-date technology, such as how to handle 5 1/4-inch diskettes, which may give the reader a chuckle. These references should also make us realize that the basic practices associated with quality assurance as outlined in this book have stood the test of time. If you are looking for some templates to get your QA practices documentation on the right track, there are many practical checklists, worksheets, report outlines, and a sample quality assurance manual.

The book begins by giving us an overview of the basics of quality assurance: What is quality, what is quality assurance, why is a quality assurance group needed, and the “critical” difference between quality assurance and quality control. “Quality assurance works with the processes while quality control works with the products”(19). There is a very important point made in this chapter, which is stressed throughout the material: “Does the system achieve the objectives of both the user and the total organization? The goals of the organization come first, and the goals or the requirements of the user second. Should the requirements of the user conflict with the goals of the organization, it is important for QA to point out this conflict.”

Chapter 2 discusses the role of quality assurance as we support our organizations’ MIS departments, and chapter 3 outlines how we go about setting up the QA group. There is a chart that outlines the many challenges faced by MIS and how QA can help meet these challenges. These tasks are broken down and a checksheet is provided for rating the importance of these tasks. There is an appendix at the end of this chapter, “Quality Assurance Work Plan,” which outlines the scope of the QA department’s functions. If you have not already begun a QA charter for your department, this document would be a good first step.

Chapter 4 covers the important aspect of allocating QA time from a very practical viewpoint. It outlines what to consider when deciding which projects or systems to review, risk factors to consider, and how to score the risk. Then chapter 5 discusses what QA should do when reviewing an application—including goals, methods, and performance—always pointing out that this is a review of adherence or conformance to the policies and procedures of the organization. How and when to review is the substance of chapter 6, while chapter 7 walks us through a review.

Application controls are covered in chapter 8 by dividing applications into several categories and looking at both environmental and application controls for each category. Don’t pass up the charts in this chapter as tools to assess the adequacy of your application controls. Chapter 9 gives us guidance in the many techniques we have at our disposal to accomplish the review process.

We now have mounds of data, so what do we do with it all? Chapter 10 covers reporting our findings, including how to report the data and who should receive the reports.

What are QA responsibilities and methods? Chapter 11 discusses verification, validation, and testing, while chapter 12 covers improving software maintenance. By applying QA principles past the release date to the maintenance phase we can improve this process, and help reduce any negative impact on our projects.

Software reuse is an often-debated topic, but how often do we consider reuse of our QA resources? Are we developing test plan after test plan when we should be considering what parts we can use across projects? Do we discard test data after it is used once, or do we realize the importance of our in-house “testware”? Chapter 13 covers the practicality of both software and testware reuse.

Have you ever been asked to take on a “special assignment” and then wrestled with the impact the assignment would have or your current project? Chapter 14 discusses how the QA group can accept and reject special assignments, giving us practical advice on which assignments will most likely further our quality assurance efforts and which are not really worth the time they will require.

Chapter 15 explores the impact of the personal computer on quality assurance. It discusses many points on security and protection of the data that are still relevant. Many of the references are outdated, but it is still worth skimming this material.

Chapters 16–19 are devoted to measurements and metrics.

I recommend this book because even though some of the data is out of date, most of the material is as useful today as it was when the book was published. Even if you do not want to “formalize” all aspects of your QA functions, this book has enough charts, checksheets, and thought-provoking questionnaires to make it worth having in your library.

I do feel strongly that the publishers and authors of this book (and many of the quality assurance books currently on the shelves) would do us a great service by making the charts and graphs available on an accompanying CD. I am a big fan of eliminating duplicated work—this book has many good guides for our use, but alas, we have to reproduce them. Otherwise, this is an excellent book.