Measure Twice, Cut Once
The Role of the QA in Making Software Development Predictable
A Guest Post for the Getting Predictable Blog
Measure Twice, Cut Once is about having a plan, being prepared, and having a systematic approach before taking action. Whether it’s installing new cabinets in your kitchen or writing a new software application for a client, no matter what type of project you’re working on, you can minimize your chance of making costly mistakes by double checking your measurements/requirements before cutting materials or writing code.
I learned this very valuable piece of information growing up with a mother who loves to sew. As a kid I would always ask my mom if I could help. Since sewing requires measurements to be as accurate as possible, a standard practice was enforced when working with my mother to double check my measurements before I cut anything! I always thought the reason she made me double check everything was because I was a kid, until one day I noticed my mom double checking her measurement as well. So I asked her, “Why do you measure the fabric twice before cutting it?” My mother replied (as she continued measure every part of the fabric), “Because this fabric costs too much and my time is too valuable to be wasted.”
She continued to say, ”Let’s say I cut too much fabric. I have now wasted fabric because I have to cut off the extra fabric which takes time. Or, let’s say I cut the fabric too short. Now all that fabric is wasted and I must cut a new fabric layout which also takes time…”
“This dress should take me one day to make but if I’m constantly re-cutting fabric due to measurements being off, then it can take me twice as long. My original estimate of how many outfits I could get out of it will also be off. Plus, I will have to go back to the store to get more fabric. But if I just double check my measurements I save myself time, money and a headache.”
QA. (not to be confused with Tester)
This is true for IT projects as well. If the requirements (which are the measurements for a software project) are being doubled checked, the project will have a minimal chance of wasting resources, time and money.
One approach to ensure that this double check is being done is to get the QA involved at the requirements stage. While having a tester involved at this stage is not the most efficient use of resources, having a Quality Assurance Analyst (QA) definitely is.
Many IT professionals are not aware that there is a difference between a QA and a Tester. A QA is an IT professional who makes the blueprints for processes and procedures. These blueprints will ensure quality is maintained throughout the lifecycle of the project. A QA also understands how to design test cases in a way that they are competent, effective and easy to execute. A tester is someone who executes test cases that, in some cases, have been written by a QA. If a QA is involved with the requirements stage, the requirements will be unambiguous and succinct.
The QA will also check the requirements to ensure that the following has been covered:
- Look and Feel: – How does the interface make the user feel and behave?
- How and why the system works: What will happen when this button is clicked and why?
- Contradictions among scenarios: Does one scenario say the opposite of another scenario?
- Root causes for gaps in the system/process: Are scenarios defined well enough? Is the workflow depicting a different picture than the information given?
The more robust the requirements, the better the final product.
During the requirements phase, the foundation that the entire project depends on will be formed. Given that over 50% of project defects are introduced during the requirements gathering phase, it makes sense to have a QA involved to double check that gray area requirements do not get overlooked and to help define error messages and usability issues. Just like a sewing project, fundamental issues left unchecked will surface later in the project.
“Measure Twice, Cut Once” is a reminder that careful project planning will result in more predictable results.
Category: For Practitioners, Requirements Definition
I completely agree with double counting techniques and methods to improve knowledge on what is being estimated. However doing the same thing twice won’t assure much gain where all requirements are best guesses. Maybe a more efficient way to tackle the issue “Given that over 50% of project defects are introduced during the requirements gathering phase” isn’t to estimate twice, but to understand the problem of detail planning up front doesn’t work well in dynamic environments.