24 of 25 people found the following review helpful:
5.0 out of 5 stars
SQA Engineers must read this book., June 29, 2001
This review is from: Customer Oriented Software Quality Assurance (Paperback)
I have been in the SQA business for 10+ years. I wanted to test my field knowledge by taking a certification. To my surprise, I did not pass the "Brainbench SQA Certification" (from brainbench.com) the first time I took it. Therefore, I wanted to find out what information I was missing. The test site recommended several books from Amazon.com. I choose this book because it seem to the information that I was looking for at a low cost. After reading this book, I was able to retest and pass the Brainbench SQA Certification.
What I like about this book is the basic industry information that an SQA Engineer should know. It is full of information in metrics. As a tester, I know that metrics were important but I did not know where to apply it effectively. It is also provided me some basic information in ISO 9000 and SEI CMM appraisals in customer-focused quality assurance.
I know there are many software organizations out there that have have not read this book. I highly recommend this book or similar basic book for those organizations that want to develop a quality product based on customer orientation.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
22 of 23 people found the following review helpful:
5.0 out of 5 stars
Too basic for the SQA practitioner, but ..., January 26, 2001
This review is from: Customer Oriented Software Quality Assurance (Paperback)
I agree with the previous reviewer that this book is a basic primer on software quality assurance. From the perspective of a software quality assurance practitioner I would have rated this book at 3 stars and moved on.
However, this book has much to offer to four domains outside of SQA:
(1) Developers - most developers are woefully unaware of the basics of SQA. They have no idea of the much larger picture and how they fit into the scheme of things in a process that is designed to deliver a quality software product. In fairness to developers they have a daunting task just keeping up with the techniques and technologies that characterize their domain. What this book will do for a developer, particularly one who is working within the context of Extreme Programming (XP), is to provide a foundation for software quality. It also provides an awareness of SEI's capability maturity model (CMM), about which most developers outside of defense-related software organizations probably don't know much. It also gives a good overview of ISO 9000-3 (also known as TickIT).
(2) Testers - software testing and SQA are two vastly different functions. Testing is done to verify and validate software or to break it. In the verification and validation stage testers find the answer to: Did we build the right thing? Did we build it right? This is done in the user acceptance/product test environment. Testers try to break software in the staging/pre-production environment. In this respect testers are the natural enemy of developers. Contrast this with SQA - this function is a process and oversight function that is usually performed at the program management office (PMO) or software engineering process group level. In an ideal world SQA concerns themselves with developing and implementing processes that minimize defects and rework. They work with trends, statistics and other quantitative methods and attempt to answer questions such as: Where in the development life cycle did the defect get introduced? What can we do to the process to prevent it from happening again? This book exposes testers to a brave new world called SQA and shows how they fit into the much larger picture of delivering quality.
(3) Production Services (a.k.a, production support, application support, and a plethora of other names) - this group is on the front line and is comprised of a number of functions, all of which would benefit from this book. The help desk staff will have a clear idea of quality indicators to measure that mean something to both the business and the applications delivery team. For example, while defect density metrics may mean something to the SQA group, it is of less concern to the help desk. On the other hand, the help desk (and tier 2 application support) would find metrics such as defect removal efficiency to me a useful measure. This metric is the ratio of defects found in testing and defects discovered production. This does three things: shows how effective the testing function is, provides a baseline for developer resources needed to fix the problems, and provides an indication of the resources necessary to support an application.
(4) Project manager - here is a succinct resource that shows you where you need to focus your quality efforts during the development life cycle.
I liked the fact that the author resisted the temptation to write a ten pound tome on a subject that could have consumed thousands of pages. At 208 pages it is an easy read, provides a clear picture of SQA for the non-practitioner, and is well suited for the audience that I cited above. Because of my view of the potential audience for this book I felt that it deserved a solid five stars.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
2 of 2 people found the following review helpful:
2.0 out of 5 stars
Too Little and Too Basic for QA Engineers, August 26, 2004
This review is from: Customer Oriented Software Quality Assurance (Paperback)
Although this book provides you some basic insights about customer-oriented quality assurance concepts, it offers too little and too primitive basics for someone who want to learn solid software QA basics, processes, methods, and metrics, and standards, and quality systems. It does not provide fundamental
basics for you to learn how to work and perform as a SQA engineer.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No