Product Quality
October 27th, 2009 by Jeff Jaffe
By far, the major obsession of Novell’s engineering team is to deliver products with the enterprise level quality that customers demand and deserve for mission-critical usage.
It is useful to review our comprehensive approach to quality. Quality is not a single process. It is baked into everything we do: before and during development; after products are shipped in the field; with maintenance provided to customers well after products have been shipped. Due to this breadth I will “fishbone” our activities and address this topic over several postings.
In this posting we define quality, provide key tenets, and outline future posts.
Quality Defined
There are numerous definitions of quality—the most general being “the degree to which the product meets customer expectations”. This can be interpreted as—choosing the right features to meet market needs—and in the past I have described our Integrated Product Development (IPD) process that has that goal. By the way, we are broadening IPD to include a new Requirements Management System which allows customers and partners to directly input their needs to Novell’s product management. But, that is a story for a different day.
Colloquially, when people talk about product quality however, they refer to product defects or bugs. We address bugs throughout the lifecycle of a product by preventing defects in the first place, testing and debugging to remove them, and patching and fixing problems in customer installations. This definition is akin to a classical Six Sigma focus on defects and this is the aspect of product quality that I will discuss.
Philosophy
Herein are basic tenets or beliefs about product quality. Many of these are common in the industry; some are unique to Novell.
- We are in business to provide mission critical software. Accordingly, we hold ourselves to high standards for initial product quality and strive to correct defects found by our customers.
- Quality must be built in prior to customer shipment. The cost for Novell and our customers alike grows exponentially the later in the deployment process one finds a bug.
- The practice of software development has not been perfected. There is no such thing as bug free software. We strive for excellence, but recognize that defects will occur.
- The response to these defects is modulated by severity. Critical defects found in a customer’s production environment get the most immediate attention.
- We make mistakes. And we fix them. If a defect occurs, we patch it. If a product has too many bugs, we redouble our efforts to restore quality to that product as soon as possible.
- Consequence of 5—we try really hard not to make the same mistake twice!
- Our employees respond to management’s attention. Hence we carefully measure our quality, review it on a regular basis, and won’t ship products that do not hit quality criteria. This ensures that we will build quality in.
- There are different methodologies for developing software including agile, waterfall, and open source (community). Our customers expect and deserve equal quality regardless of the methodology.
- Consequence of 8—although there might be different methods to develop software; the software quality metrics and release criteria must be the same.
- Quality is a continuous learning process. Time is set aside for our engineers to continue to grow and learn to improve their skills.
The Fishbone
This is a broad topic and it is already running a bit long. Let me summarize my intentions by listing the key aspects that I will discuss in future blog entries:
- Building in quality from the ground up: In the development of a product, how do we build with as few defects as possible. For agile, waterfall, and open source.
- Metrics: What are the common metrics we track to ensure that we release with quality.
- Testing tools: Methodologies, laboratories, cross-product testing, defect management process.
- Product introduction: How do we manage that very challenging time when a new product is first introduced into the field. Readiness criteria.
- Continuous improvement: Engineering Excellence Steering Committee. Learning Initiative.
- Cadence between product development and Novell services: How we work together and hold each other accountable within Novell to take care of our customers.