What quality assurance techniques work? Most probably, you use some standard practices developed in your organization. The industry you work in may dictate the practices. But, are they efficient? Can you improve them? How?
The key question is different.
What techniques provide 80% of quality? Do you apply them to your project?
Working on numerous software development projects, I tried many fancy techniques. Still, there was always a limited set of quality assurance practices. They provided the most significant benefits.
In this article, I will talk about the 20% of techniques that provide 80% of quality on your project. You need to assure you implemented these practices to the full extent. Only then, try something else.
1. Requirements Definition
In the previous post, we talked about the definitions of quality. One way or another, all of them are related to the requirements.
Profound requirements definition is the key to a quality product.
Serious Projects Need Serious Teams
Your team must have enough expertise to collect and write down high-quality requirements.
Nothing can change that.
There are no magic tricks here. You will not be able to collect requirements and build a top-level product or result with newbies.
I agree that ten students with basic programming skills can create an application for iPhone. Still, they will not be efficient. There will be trials and errors. And there will be reworks. And I’m quite sure they will not be able to win the market with their product in the end.
So, you need to ensure that you have the required resources and expertise in the team. It may include roles of Business Analytics, Product Manager, UI/UX experts, and other subject matter experts relevant to the industry.
I mean, you need to have experts available to assist your project team. Experts that have experience in similar projects, not only the required skill set.
What can you do if your budget is limited and you cannot acquire anything like that? It is a risk within several domains (technical, legal, business, etc.). So, you need to treat it like that. You need to communicate the risk to the stakeholders and plan accordingly.
Build Bridges Between Business and Expertise
It is not enough to learn what business needs and transform it into requirements. You need to get input from the experts on the limits of the technologies or approaches that you have at hand.
I do believe that we can do almost anything given enough time, resources, and failure tolerance.
However, that is not our goal.
Project management is all about the efficient use of time and effort. So, you need to find a balance between what business wants and what your project team is capable of. There should not be extremes in budgets or timelines.
Design First
If applicable, always try to visualize the final result or product. Create designs, wireframes, prototypes, mockups, sketches, whatever. Just give your customers and the team something to play with before starting the work.
The benefit is that you will get more of possible use cases. It will reveal extra questions and clarifications. You will be able to simulate the end user’s behavior.
Getting to this level of detail will save you lots of time in the future. Especially if you build in the ability to extend, scale, and adapt your project to the new requirements right from the start.
But stick to common sense.
Sometimes it is more efficient to create a hardwired product or result. Even if it means redoing it from scratch later. So, consider your high-level requirements, constraints, and project context.
What do Engineers Need?
Last but not least. If you have engineers or any other kind of experts, you need to get their input on what should go into the requirements.
It might be some extra information or a specific format of the requirements. For example, designs can be created in an interactive form. There, engineers can see all the required measurements and metrics rather than counting pixels on an image.
I mean, you need to streamline the workflow from the beginning.
Requirements come from clients from the business. Nevertheless, your project team will use them in the first place. Language, terms, or formats should not impede their work.
So, care to find out the team’s preferences in advance.
That is not all…
“Quality is never an accident. It is always the result of intelligent effort.”
– John Ruskin
2. Work Towards Deliverables
Work Breakdown Structure has a great impact on quality as well.
Why?
You always work to create a tangible and complete piece of a project. It complies with both quality management and the requirements.
Here are two components that will help you create a quality product with a WBS.
A. Decompose Project Scope for Better Quality
For example, a project that is 100% finished is worth $1,000,000
What is the value of a project 95% done?
The correct answer is $0.
On the other hand, let’s assume your project has 10 components.
You have 10 components done but with severe defects in each one. Can you release such a product to the market?
In most cases – no.
What if you have 8 components fully ready, tested, and polished?
In many cases – it is a viable product ready for market.
It is always better to decompose the project into tangible parts.
But there is a catch!
B. Deliverables Should Comply with the Definition of Done
It is not enough to just break down the project scope into pieces and pass the tasks to responsible team members.
Every team member should produce deliverables of the same state of readiness and quality.
You achieve this by compiling a list of typical activities everyone should perform to hand off his or her work.
It may include:
- Performing actual work.
- Performing testing and sampling.
- Reviewing the results with Quality Assurance team and Business Analyst.
- Creating of related documentation.
- Demoing the delivery.
- Actual hand-off and sign-off by responsible managers.
The list depends on the nature of your project.
And here is the primary goal:
Prevent integration of unfinished or poor-quality parts of a project into the whole product or result.
The idea is simple.
You create a quality product from quality pieces.
3. Make External Quality Audits a Habit
For sure, you think through the quality management plan for your project. You keep track of the quality processes. The team performs quality assurance.
However, there is still a way to improve.
The best way it is to ask someone to have a critical look at what you are doing. They will have uncomfortable “why” questions.
Can you answer them all confidently? Without saying, “It was always that way”, “It just works well this way”, or “We don’t have time/money/desire to do it in another way”.
Here are some aspects to think about.
A. Developing with Quality in Mind
What can you improve to make a quality product at once? How can you integrate quality into all the processes?
Here is just a short list of possible activities that you may find beneficial:
- Review requirements before starting any work.
- Work in pairs.
- Review intermediate results by another expert.
- Perform intermediate quality control checks.
- Let the responsible team member demo the results for the rest.
- Perform Retrospective meetings.
- Build ownership feelings in the team.
- Improve motivation in the team.
It doesn’t stop here.
You need to review and analyze quality assurance processes continuously. Look for an opportunity to improve it.
B. Reduce A Defect Feedback Loop
There are cases when you cannot prevent defects efficiently for objective reasons. Then, look for a way to reduce the time it takes to fix the flaw and provide a corrected deliverable faster.
The best way is to start looking for defects before the work is hand-off as a complete deliverable. In other words, look for a way to integrate quality control activities (e.g., testing) into the workflow.
C. Automated Testing
If you are following me, then you do decompose your project scope into pieces. You work towards delivering high-quality and tested pieces. So, new defects should not popup just like that in a completed piece of work.
A defect may appear during the integration of separate parts.
Do your decomposed pieces change a lot in the process? If not, it is not efficient to retest them after each integration.
Then, you need to consider automating the testing of the pieces and integrating the whole.
From my practice, it works more effectively if you develop your project with automation in mind. Introducing automation mid-project is usually too costly.
Takeaway
As you can see, nothing I mention here isn’t really industry or project specific. Requirements, scope, continuous improvement. These are the three pillars of quality you need to establish first. Then, start looking for any other fancy approaches.