In today’s post, we’ll raise your awareness of how good quality can be defined and achieved. This material will be useful to project managers and company owners who are running software projects either regularly or on a one-time basis.
Every project manager knows that when planning a project, it’s essential not to leave any issues up to chance. And it’s not about the software only. When planning a trip, house repair works, or a wedding, it’s vital to take all but tiny issues into account.
When speaking about IT projects, it’s highly important to plan for the scope of work, for the budget and timeline, select the right tech stack and skills that every team member will bring to the table.
However, there is one thing that is often taken for granted. Quality. Believe us on the say-so: high quality is not a matter of course. Quality is as important as budget, deadlines, and toolset. And if you don’t plan it, you still leave it up to chance.
Quality plan: what to include?
For every project, there is a project plan. The point is that for every project, there should also be a quality plan. Unfortunately, very few of us know what it looks like. Right?
A quality plan is not the same as a test plan. A test plan outlines a testing strategy, while a quality plan helps to assure that you will deliver the flawless system.
To excel, make sure you have the comprehensive step-by-step quality plan in place. Mainly, planning to produce a decent software product of high quality is a three-step process, and we’ll list all the steps.
So what are the steps your team should take to deliver a high-quality product, free of flaws and vulnerabilities, and satisfying both the stakeholders and your users?
1. Agreeing on “good” quality
For those who have no or little experience in setting quality goals, this step may be rather daunting. But once you set your first goals, it will be less challenging for you next time.
The simplest way, to begin with, is to analyze what has made us or our clients, or management judge the system to be of unacceptably poor quality before. What made the client go crazy or why the users left bad reviews you’d prefer to delete from the store? Was the software too buggy to be used successfully? Was it slow? Was it insecure?
Try to make a list of all quality dimensions that turned out to be critical in the past.
2. Setting measurable quality goals
Sounds quizzical? Indeed, the budget is set in terms of money, deadline – in terms of calendar dates. How can one measure quality?
Once you’ve completed the list mentioned above (with various quality dimensions that matter), think how you can measure each of those dimensions.
- If you care about the number of defects, then apply the “defect density” notion. (Defect density = total number of defects detected in software for a certain period of time/product size, where size is measured in some concrete way, i.e., lines of code).
- If the final performance parameters are important, then you can speak about the time of response (measured in seconds), throughput (bytes per second), or load (simultaneous users).
Once you’ve identified the key quality attributes, it’s high time to figure out what your reasonable quality goals are.
Previous software development and testing projects will be much of help. However, very often, the quality on the prior projects fell short of expectations. If this is the case, still measure the goals achieved and set new ones with improvements.
3. Planning quality-related works
Defining measurable quality goals is not the end. In order to achieve them, you or your team must do something.
There are three main types of quality-related activities you should plan: detection, correction, and prevention. Let’s specify each of them.
Defect detection activities are designed to isolate defects. “But we have a QA engineer who’s responsible for reporting bugs to the developers”, you might say. You’re right, but are you sure that testing doesn’t happen too late on the project? To answer this, reckon up the costs of the bug fixing activities. How much effort does it take?
You can improve quality by doing more detection activities earlier on the project. The results will astonish you.
To do this, try the following:
- Introduce code review in the early stages of the project.
- Consider implementing a test-driven development approach. Writing the tests first requires a software engineer to consider what he wants from the code.
Defect correction activities are focused on verifying that the bugs that have been detected and fixed haven’t introduced any more flaws or vulnerabilities to the system.
The last (but not the least) kind of activity is defect prevention. If conducted properly, it will provide you with the biggest payoff. Remember a wise saying assigned to Benjamin Franklin? “An ounce of prevention is worth a pound of cure.” The essence of the defect prevention is to consider the problems you faced before, and try to enhance tools, methods, or approaches to keep them from happening again.
Of course, some experience is required to perform defects prevention. Otherwise, it is likely to take too long to search for all possible bottlenecks. We would advise addressing specially trained staff, be it business analysts or QA consultants, to do this work and avoid high rework costs.
In today’s post, we’ve focused on planning for quality. Now you know that alongside the project plan, there should also be a quality plan in place. Have we convinced you?
We’ve also specified how to choose quality parameters and measure them. The three activities you must plan if you don’t want to leave your quality goals up to chance have also been mentioned.
Now you know the route to successful project delivery.
Any questions? To get a free quote, drop us a few lines.