By Craig Dill

How many times have you heard or seen a slogan like the title of this article? Catchy slogans like Ford's, Quality is Job One have that same ring. They want you, the potential buyer, to believe that they make a quality product. But what's behind the slogans?

The American Heritage Dictionary states that "quality is a degree of excellence." That's wonderful, but it doesn't say what "degree of excellence" means. Another definition of quality is meeting the customer's expectations. Now to define quality are we stuck including the customer's expectations too? Yes, and to make things more complicated, expectations of software quality are constantly changing.

We have to separate quality into functionality - how the product works - and reliability - whether it functions consistently. The goal of excellence gets applied then to functionality and reliability. A great example of quality of functionality is field lookup. In the 1980's, this feature helped sell your software. Today, field lookups are simply expected. Pinning down reliability we'll touch on later.

My quality values? I believe that the twin goals of meeting customer expectations and achieving excellence would revolutionize Quality Assurance departments. This view of customer expectations and excellence has caused me to believe that quality isn't something you have or don't have. It's a way of life. Your software has better features and is more reliable than your competition's when you organize the whole project around quality.

Quality is a Process, not a Destination

How does any company keep up with changing quality expectations? The company must remember that quality is a continuous process or lifestyle, not a destination. If you think of the destination of quality being absolutely no defects, you and your employees will find out that this unrealistic goal is unattainable and eventually they will give up. If you consider quality a constantly decreasing number of defects, the process becomes a lifelong journey toward excellence. You may never quite get there, but it's worth trying.

BASIS Starts a Quality Assurance Process

This past year BASIS became very serious about quality. The Spring 1996 Advantage Newsletter announced that BASIS' Quality Assurance (QA) Department had been born. It has not been a simple birth. When we started in January 1996 there was a very large backlog of products to test, and many more tests to write and develop. None of us in the QA Department had ever started or developed a QA Department from scratch. We treaded softly and quietly on this newly laid ground by reading J. M. Juran's book Juran On Quality By Design. BASIS acquired some experienced people from other QA Departments and learned all about quality assurance. In the past year, we've implemented many processes, including processes for handling QA Memos, writing new tests, and performing these same tests. An additional member was quickly added to the QA team. This member is Brad Walston, whose Certified NetWare Engineer (CNE) training has been a great benefit for BASIS. BASIS has also implemented distribution of our updates through the World Wide Web. This was no small task from QA's viewpoint. But the most important development in my mind was that BASIS began creating detailed specifications so we could test against our customers' expectations.

The Most Important Part of the Process

As a customer of BASIS you are most likely a programmer. What I am about to say, you may already know. If you don't have a specification, you can't please the customer. Some of you will dispute this by pointing out that there is no need for a specification when you are just making a simple program change for a customer. You may argue that you only need specifications when you are doing a large project.

Let's stop for a moment and consider, what is a specification? My trusty dictionary says that a specification is "a detailed and exact statement of particulars." In my previous job as an Add+On Software dealer, I discussed directly with clients what specific modifications and changes they wanted to accomplish in the software. These discussions all seem like specifications to me. Now, let us suppose that I was going to give that specification to a programmer that worked for me. If I give these specifications only verbally, I could risk leaving something out of the specification or miscommunicating what the customer wanted to my programmer. However, if I take the extra time to write down what the customer wanted, not only would I remember all the details, but I could give a copy to my customer and have them approve my plans. Then when it came time for me to test my changes before delivery to my customer, I could review my specification and make sure I had met their needs. Finally, if the customer and I ever had to review the project, we could both use the specification to check and verify the work.

Now consider the situation that BASIS faces every day for each specification. Two product managers work with the lead software engineers to put together product requirements and specifications. Fourteen engineers turn these specifications into an upgrade of a previous product, or a completely new product. Software under development is continuously being reviewed by four members in Quality Assurance, while two technical writers develop the documentation. These specifications also help eight Sales representatives to sell you our products, five Customer Service people to deliver the product to you, and six Technical Support people to answer your tough questions.

The Work Bears Fruit

At BASIS, the fruit of all that specification effort will appear in our Kilauea product. BASIS will be able to release some of our highest quality products. 1997 holds even more surprises for our customers. Our Volcano product releases call for an exciting product revolution, like the revolution that started BASIS International. This quality revolution will vault our customers' expectations beyond anywhere they have ever been before. An important part of this revolution is putting quality in the products before the fingers ever touch the keyboard.