So, What Is Quality?
I have been testing software for a lot of years: first as a power user of software that my company purchased, then as part of my job implementing a highly customizable enterprise resource planning (ERP) platform. For the past ten years or so, I have been building and managing software quality teams. Part of the work of building teams has involved training folks who are brand new to QA and testing.
One of the topics that is important to discuss with people new to the field is the definition of quality. I think we all agree that we know what “quality work” is when we see it, but we don’t always think about the definition of the word. The definition of “quality” as an adjective at Dictionary.com lands as more than a bit flat for me: “of or having superior quality; producing or providing products or services of high quality or merit.” Thanks. Define the word with the word. My third-grade teacher wouldn’t have been impressed if I tried that. I realized that I would need to do my own research to find a definition that works well for me and for those whom I teach.
Many of my readers may not know that Quality Assurance / Quality Control originated in the standards established by craft guilds in the Middle Ages. It became a management discipline in the 1920s as manufacturers needed to ensure consistency and interchangeability in the products that they produced. Two of the great minds who helped to shape quality management were Joseph M. Juran and W. Edwards Deming.
Juran was a Romanian immigrant who developed much of his quality control philosophy at Western Electric and Bell Labs. In his Quality Control Handbook, first published in 1951, Juran defines “quality” as “fitness for use.” As I read his definition and further discussion, it resonated so much with my own thoughts of what quality is that I continue to quote it, and it forms the basis of my own “Quality 101” presentation. While it’s a great definition, it also deserves some further thought and explanation.
For Juran and others, “fitness” means that the product (including software, apps, websites, etc.) meets the specified requirements. That is, the customer/user or their advocates in product/project management and design specify what they need the product to do and how to do it. In software development, we have our acceptance criteria and UI/UX designs as our specifications. We QA folks and our software engineer counterparts can write all sorts of tests (unit tests, functional tests, integration tests, etc.) to determine if the app or site is doing what it’s designed to do.
When we add the “for use” phrase to “fitness,” then we shift the focus from requirements to the actual end user. Not only should the software work as designed, it should also work in such a way that an end user will actually want to use it. This means that we (QA, product, design, etc.) need to take into account broader, general expectations and paradigms to ensure that the solution isn’t too complicated or unpleasant to interact with.
I have a great example of a “general expectation:” Think about almost any website where you login and logout. If you’re on your computer and you need to logout, where will you look first? Your mind and eye (and probably your cursor) will go to the top right corner of the page, looking for a profile/account icon or logout button. I happen to have a Macy’s credit card, and the site for managing my account has the “sign out” function in the top left. There is no rule or law that says that Macy’s is wrong, but I’m so accustomed to sign out/logout being at the top right that I still (several years into having the card) frequently forget where to find the “sign out” on that site!
For QA folks, I always stress the importance of setting aside our tests that are written like cookbooks (click here, enter this type of data there, click that button, and expect this thing to happen) and sitting down in front of our apps/sites to interact with them like a user. What does the user see? How do they move through and interact with everything on the screen? What things happen on the screen, and how do they compare with what a user expects to happen? (This type of testing is known as “Exploratory Testing,” and I’ll sing its praises in a subsequent blog post.)
If you think about it, Juran made a great point: quality (in products or software) is fitness for use. The product does what it’s supposed to do in a way that fulfills the needs of the end user.
Contact Us
contact@hunterstrategy.net
