About a year ago, I wrote a post suggesting that we could think about automation in terms of a test wheel, where each section of the wheel represented a different type of automation. A reader who works at Abstracta told me that my wheel reminded her of the wheel they use to think about all of the different facets of quality. I thought their wheel was so great that I knew I would eventually want to write a post about it.
I’ve been thinking about the different types of quality mentioned in Abstracta’s Software Testing Wheel, and wondering what I would do if I was brought on to a project that had never had any testing and I needed to start from scratch. Where would I begin my testing? I thought about what the most important needs are for quality, and I was reminded of Maslow’s Hierarchy of Needs.
For those who are unfamiliar with this psychological concept, this is a theory that all human beings need to have certain basic needs met before they can grow as people. The needs are as follows:
1. Physiological needs- food, water, shelter
2. Safety needs- security, property, employment
3. Love and belonging- friendship, family
4. Esteem- respect, self-esteem
5. Self-actualization- becoming the best person one can be
Looking at this list, it’s clear that physiological needs are the most important. After all, it doesn’t matter if you have high self-esteem if you have no water to drink. Each successive need builds on the more important one before it.
With this in mind, I realized that there is a Hierarchy of Quality- certain conditions of quality that need to be met before a team can move on to the next area of quality. Here is my perception of where the different areas of the Abstracta test wheel fall in the hierarchy:
1. Functionality and Reliability
These two areas share the most important spot. Functionality means that the software does what it’s supposed to do. This is critical, because without this, the application might as well not exist. Imagine a clock app that didn’t tell time, or a calculator that didn’t add numbers.
Reliability means the software is available when it’s needed. It doesn’t really matter if the app works if a user can’t get to it when they need it.
Once these quality needs have been met, we can move on to the next level:
2. Security and Performance
Security is important because users need to feel that their data is being protected. Even applications that don’t have login information or don’t save sensitive data still need to be protected from things like cross-site scripting, which might allow a malicious user to gain control of someone else’s device.
Performance is also important, because no one wants to wait for sixty seconds for a web page to load. If an application isn’t responsive enough, the users will go elsewhere.
Now that the application is secure and performant, we can go to the third level:
3. Usability and Compatibility
This is the level where we make sure that as many users as possible have a good experience with the application. Usability means that the workflows of an application are intuitive so users don’t get confused. It also means that the application is internationalized, so users all around the world can use it, and that it is accessible, so users with visual, auditory, or physical differences can use it as well.
Compatibility means that users with different operating systems, browsers, or devices can use the application. Have you ever filled out a form in a browser and had it not save correctly when you clicked the button? This has happened to me more than once, and I’ve needed to fill out the form again in a different browser to have it save correctly. It’s important that our users have a positive experience no matter where they are using the software.
Now that we’ve made our application accessible to as many users as possible, it’s time to go on to the next level:
4. Portability
Portability covers how easy it is to move an application from one place to another. One example of portability would be the way I can access my Google Drive files on my laptop, my tablet, and my phone. Portability also refers to how easy an application can be installed or updated. Also, we want our application to keep working when a device has an operating system upgrade.
Finally, we have thought about all of our users’ needs. Now it’s time for one more level:
5. Maintainability
This is a level of quality that benefits the software team. Maintainability refers to how easily an application can be updated. Is it possible to add new APIs or update existing ones? How easy is it to test the system? Is it easy to deploy new code? Is it easy for other teams to use the code? Is the code clear and easy to understand?
When software is accessible and easy to use for all end users, AND is easy to work with and maintain for the development team, then truly high quality has been achieved.
I hope that this Hierarchy of Quality will help you make decisions about what areas of an application should be focused on first when there are a number of different quality areas competing for your team’s attention.
What do you think of this order? Do you agree or disagree with where I placed items in the hierarchy? Are there any missing quality areas? Let me know in the comments below!
I'm a big fan of models as thinking tools and conversation starters. I like this type of model to help prioritize testing activities. I think each team probably needs to figure out their own hierarchy. For example, in some domains, performance or security or accessibility could matter more than functionality.
I totally agree, Lisa! The needs of a gaming app would be quite different from a banking app. With the banking app, security might be more important than uptime, for example.
I feel like you could make #1 be functionality/security and #2 reliability/performance. It is tough for me to argue that functionality should come before security in most cases. If you fix up a broken application to be functional first and release it before tackling security then it could open the door for vulnerabilities that weren't there before due to the broken state it was in.
That's a good point, Austin! But, if the user can't make it to the application at all (i.e. gets a blank page), then the app is completely useless. Which one is more important probably depends on the kind of app. With a banking app, I'd definitely prefer getting a blank page over having my security compromised, in which case #1 as functionality/security makes sense. 🙂
great