Today, quality related processes within software development projects are shifting towards a more strategic and continuous role (i.e., Continuous Integration and Delivery or Site Reliability Engineering). The better you understand and apply core software quality aspects to your projects, the more certain you can be of their success.
Software quality is not a destination
In many ways, software quality is more of a path than a mere objective, however the Quality Assurance (QA) discipline is often mistakenly referred to as a function, process, or task within software development. This perspective obscures the value added from a solid quality approach and may even lead teams to view quality processes as a bottleneck.
Software systems are embedded in our everyday lives, for them to be successful they must be ideated and designed for the user and be as defect-free as possible. This is why this series aims to help the readers find new purpose in the seemingly abstract and tedious software quality jargon we hear all the time. Stick around for the monthly insights that will make Chasing Quality a regular and more actionable part of your projects.
Here are the topics we will be discussing throughout this series:
- Technical debt might not be what you think it is
Our first stop is to revisit a familiar face and a particularly important topic for software development: technical debt. We will cover the formal definition of technical debt, provide examples of what it is, and clear up confusion about what it is not. We will also cover the importance of keeping a ledger on technical debt, giving you a grounded yet uncomplicated way to track it. - Estimating your project’s technical debt might be easier with a change in perspective
Next, I will transport you to what some may see as an alternate dimension by introducing you to “quality debt.” This is a twist on how to think about technical debt and a concept that was developed to give down-to-earth ways to identify, measure, and account for it. In this topic, I will briefly mention defect related artifacts, which are essential to this mindset shift, but they will be covered in greater detail in the last post of the series. - Consider alternative ways to reduce quality debt
Now with the tools to expand your horizons from tech debt to quality debt, this third post will cover ways to plan for its reduction (or at least keep it from growing) by more deeply involving and developing your team and making better use of the tools already at your disposal. - It is not a picnic without bugs
Try as you might, one cannot escape bugs, and when you get bit it’s always safer to get help from an entomologist (the professionals who study insects). For our final post, let’s talk bugs (better known in the tech world as defects). While the “traditional” or “academic” definition of a defect implies a reactive approach, I will suggest a classification (or taxonomy) for a more proactive defect management process—so you don’t get bit by the same bug. I will also cover how to effectively read the “glyphs” (or graphs) of some common defect metrics, as they are an intrinsic part of any defect management approach. At the end of this post, you and your team should be able to switch from engineers to software entomologists when needed. - The aim is for you to chase quality yourself
The series will close by rounding up how artifacts (sometimes understood as standalone items) can work together to help you enhance your release cycles, spot trends for better predictability, and increase the certainty of your software deployments.
Through this series, you will gain monthly insight into some basic but powerful concepts of software quality assurance. Discover how to apply them to your projects and learn a trick or two to start your efforts (or better yet, get back on track) towards better software. You may start doing it for your business, but you will keep going for your team, and at the end of the day your users will appreciate it the most.
Stay tunned!
