Developers and Testing – Part 2: The Importance of Quality
In this four-part series, ArcherPoint’s Matt Traxinger discusses the relationship between development and testing, how to improve your testing skills, and an alternative approach to testing. If you’re just joining us, be sure to read Part 1: Developers Don’t Make Good Testers.
Quality is important. I think everyone agrees on that point. Or at least everyone pretends to agree. If it is really that important, then why do we put such little emphasis on it? I think we have to start by deciding what quality actually means. Usable? Reliable? Accurate? Maintainable? Those are characteristics of quality, but not really a definition. Does it mean that the solution conforms to requirements? What if the requirements aren’t accurate? It means different things to different people.
My definition of quality is that the system is fit for use by the people who will actually use it. I should point out that I take a broad view of the term “user” as well. A user is not just someone at the company to which I am delivering the software. Users include the other developers who have to look at my code and modify it in the future, the consultants who have to train on it, and the support desk that has to understand it. Everyone who touches the software is using it in one way or another.
Now that we have a definition of quality, we need to understand what affects it. I often ask a question when I interview potential developers: “Among time, cost, and features, which one would you sacrifice if you had to?” The answer I always get is time (which in a services organization typically means cost as well) because you should never sacrifice quality. This is the traditional approach to software development: a fixed set of features with variable time and cost. What most people don’t realize is that this has a direct effect on the quality of the solution. Whether it is pressure from the CEO about keeping to an implementation schedule or reminders from the CFO about budgets, quality will diminish in order to reduce the variance. It’s not that any of us do this on purpose, but we’re fooling ourselves if we think quality takes priority over other things.
Let’s flip this around and act as if quality was the most important thing. If quality is fixed, that means something has to be variable. Typically, we want to keep time and cost under control, so that only leaves one thing: features. Now, don’t get me wrong; you should not sacrifice the things that you need to have. It can, however, be difficult to say no to those things that are not in scope but would make life easier. If you can’t say no to scope creep and can’t say yes to time extensions and cost increases, then diminished quality is an absolute certainty.
In my next post, we’ll explore different ways to improve our testing skills. Understanding this can help us get to and maintain high quality more efficiently. While that doesn’t completely change the above model, it does mean that we can deliver solutions faster and cheaper, and as a result deliver more features.
If you are interested in NAV development, check out our collection of NAV Development Blogs.
For step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV, see our collection of How-To blogs.