If you’re like me, it’s likely you’ve made some mistakes that you wish you could correct with the benefit of hindsight. In the world of professional software development, these mistakes can be, at the least, minor irritations, or at their most severe, major disasters for your customer and for you. Anywhere on that spectrum, all mistakes waste time and money, leading to the derailment of projects, which translates to increased costs and frustration for all involved.
Wouldn’t be it great to implement some tools or processes that helped you reduce mistakes, making your customers happier?
That’s Quality Assurance.
Really though, doing quality work is a frame of mind, an attitude. Just like the arts of playing piano or sitting in meditation, quality is something you practice.
In order to get better at what you do, you need to first measure how you’re doing today. A simple way to start is to learn to recognize a mistake, or defect, when it occurs. Defects can be technical (a code bug) or process-based (like a misunderstanding). Usually, there are more of the latter type, and these can be harder to spot, but process defects that affect your relationship with the customer are just as important as technical defects.
To practice seeing defects, try recording them for a month. Just note and count each defect, then make a goal of how much you want to reduce them: try for a 50% reduction over the next 6 months.
While you’re at it, also note things that went excellently and you pulled off defect-free! Deployed a new feature that worked exactly as the customer expected? Great! Log it.
In my experience, most major project defects can be directly attributed to a lack of the appropriate depth of planning. So how can we do better planning? I have a couple tools I rely on consistently to help me:
Oh no, I can hear you thinking: the dreaded ‘D’ word! But it doesn’t have to be painful, and in fact, when used well, writing great documentation won’t be a burden for you, it will benefit you. It will add value to the project, your process, and make your customer happy.
Good, clear and concise documentation shows your customers you’ve heard them. Written well, it also lets them participate, giving them a collaborative role in a process which more often than not is foreign and possibly intimidating to them. Effective documentation also will save you time coding, and allow you to test easier.
A veteran Quality Engineer once recited this mantra to me:
Document what you’re going to do.
Do (only) what you documented.
Document what you did.
Try this! I promise: your work will improve, your defects will plummet, and your customers will love the results.
So how should I document what I’m going to do? We’ll cover that in Part 2.