There are many different ways to determine how “good” a piece of software is. A developer might feel efficient code that’s maintainable and extensible is the most important thing. A product manager might be looking for a rich feature set that delivers more than the competition. A tester might be aiming for a bug-free release. Problem is, all of them may be wrong: you can still end up with a product that is too complex, too hard to use and too hard to learn.

If you really want to know how good your software is, you should be asking your end users. The real measure of quality is revealed in your usage statistics. What are your adoption rates and how often are people using your product? If people use it a lot, they like it. If they don’t…well, there’s a reason for that too.

The 3 drivers of software success
You need a solid foundation built on three drivers in order to deliver good software, and each one must be measured and judged from an end-user perspective.

  • 1. Usefulness: Does it have the features and functionality people really want? It must do what the end user expects it to do. It’s not about having more features than the competition; it’s about having the features your end users want and delivering them to a high standard.
  • 2. Usability: How easy is it to use? It must be fast and efficient, easy to learn and understand, and capable of recovering graciously from any problem. The learning curve should never be too steep, and there’s no patience for long complex user guides.
  • 3. Appeal: What reason does the end user have to install your software and load it up again and again? The best software is something that people will immediately see the value in, and after using it they’ll want to use it again every day, not once or twice a year. Would the user tell their friends and colleagues to try it out?

Understand the end user
For any software tester, the first thought should be to understand the end user. You can focus on the first two pillars and always ask how useful and usable the software is. You’ll obviously explore the reliability, the flexibility and the extensibility of the software using the full range of tools at your disposal, but try to do this with the same mindset as your intended audience.

Practically speaking, this means learning the end user’s context. Don’t just rely on documentation; you need to immerse yourself in their domain and gain an insight into the specifications they require and the desires they have.

The simplest route to this data is to talk directly to them. Modern projects frequently involve a lot of discussion with the end user and agile development dictates that a feedback loop should be established early and feedback should be collected often.

When the product manager organizes feedback groups and meetings to discuss the expectations and job requirements, make yourself a part of that conversation. The earlier everyone gets involved, the better informed they will be, and the better the job they will do. If you don’t get involved until later, make a point of being proactive in catching up. Identify representative end users and interview them.

Going beyond bugs
The old metrics are outdated. Reports on defect counts and defect density simply don’t provide a clear picture of software goodness. Just because a piece of software is completely bug-free, that doesn’t mean it’s good. Testers need to look past defects and consider things like how steep the learning curve is and how well it gets the job done.

For end users, defects are obviously a problem. But you can’t eradicate every defect before release, especially when you’re rolling out new features frequently into a live product. If we accept this, then we can take a different view. What’s more important is how the software handles a problem. Can it recover? Can it provide clear instructions for the user? Is it obvious to them what happened and what they should do next? The help and support should be built-in.

Make the end user central
It’s time to change the way we evaluate software goodness. Instead of collecting a disparate group of metrics and snapshots that deliver insights on specific elements of the development, we should make the end user central and narrow our focus. Even an efficient, feature-rich, defect-free product can be hard to use.

Any startup or seasoned software team would be wise to consider the three pillars that will drive usage, before any requirements are drawn up or a line of code is written. Then they must continue in that vein for the full life cycle of the product.

Let the end user lead the way. Take the time to understand what they want in a product so you can make it useful. Observe how they interact with the software so you can make it usable. Never take your eye off the adoption and usage statistics, because they are the only measure of the product’s appeal that really matters.