Four Practical Steps to Execute a Software Quality Strategy
Four Practical Steps to Execute a Software Quality Strategy
In this article, a DZone MVB explores what Agile development teams to ensure they deliver quality products, made using quality code.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Software quality has become a lot more important than it was a few years back. This is mainly because of increasing business competition to win customers' trust and retain them for a longer period of time. The organizations that failed to focus on software quality struggle during their development and after deployment phase. It is proven that cost of quality is exponentially high if caught later in the game, what it means that if the issue got caught during unit testing it costs a lot less to fix compared to the same issue caught by the users in the production environment. Here cost is not just cost related to money but cost is related to the brand's image. The organizations can lose their customers if they fail to meet quality expectations.
What Does Software Quality Mean?
In my opinion, software quality means that your code is meeting the bare minimum business expectations and do not have serious usability issues. We should also recognize that it is next to impossible to implement software without any defects. However, we should keep in mind that having defects in the system does not mean it is poor quality software. If the software is meeting business expectations at the end without compromising the user’s ability to perform their tasks, the quality of the software is acceptable. Every organization has their own quality standards and expectations and it is important to understand your organization's definition of quality.
Who Owns Software Quality?
Software quality should always be at the center and not at the side of the software development process and it should be owned by a team, and not just one person’s responsibility. It is very common that the responsibility for quality goes directly to testers and only they are accountable for any issues. Indeed, testers play a pivotal role in identifying issues before they reach the customer, but they are not the only group accountable for overall quality. However, everyone is accountable for the quality of the end product and it should be treated as a joint responsibility.
When to Define a Quality Strategy
Software quality should be treated as a priority by the IT and the Business teams. During the initial phase of planning, a quality strategy should be clearly defined. This is the foundational step towards quality-centric product design and development and the more we delay, the more we are going to get into trouble.
The lack of a quality strategy is the root evil of all quality issues and if they are handled well then it becomes a smooth ride for everyone. Everyone can always agree on what quality should be but if there are a lack of actions to realize this in the end product, it becomes a challenge.
If quality is your key differentiating factor, then it should always be central to your product development.
The quality strategy is key and having this strategy written down will give good clarity to everyone, in fact, once the strategy is defined, it should be clearly communicated to everyone, so they can internalize it.
Let’s discuss what should be defined in the strategy and who should do that.
The quality strategy should be owned and defined by the Project Manager along with Architects, the Testing Lead, and the key team members. Ideally, it should cover the below quality-related objectives.
How to identify personas.
How to write and store test cases.
Unit testing plan.
Regression testing plan.
Performance testing plan.
Code Quality Review.
How to measure quality.
The above-bulleted points are just for your reference but it could have many more objectives based on the project's needs. Once all objectives are understood, define expectations for each objective, who should own the objective, and how to achieve it.
For example, unit testing - set an expectation with the development team about what is expected out of unit testing. Do you expect them to write automated unit tests or do you want them to do manual tests? There could be multiple ways of doing unit tests and you will be the best judge as to what will be the right strategy for you. My favorite is to have automated unit test cases written during development so that developers can get automated feedback about their development and potential code issues.
Let’s talk about code quality review. Nowadays, various automated static code analysis tools are available which can be used doing development. It is just about deciding which tool will fit the purpose. Having solid code quality will have a long-lasting impact on the software product quality and manual mistakes can be avoided by using the right tool. While these tools can save a lot of time, they cannot 100% replace human code review.
The point I want to make is that it is all about how effectively your quality strategy has been defined. If the plan is solid and expectations have been properly set, then quality will be automatically driven by the team. Having a solid plan will guide the team to march in the right direction and will avoid confusion and the blame game.
Now, let’s talk about how to execute quality strategy in four simple, but practical steps.
Step 1: Communication
Once the strategy has been defined, it has value if it is well understood by the team members. Schedule a meeting and communicate what is expected out of each objective and who is accountable for each action. Explain each action item and help the team to understand why it was chosen. Not explaining the reason behind action item can lead to confusion and you will not get creative suggestions out of the team. For example, if 90% automated unit test code coverage is needed, then this should be communicated well in advance so developers can consider this while giving estimates during development. Also, the team will be able to suggest how to track code issues effectively.
Step 2: Training
Once you define your quality strategy, there is a high chance that you will encounter a skills gap. That is the correct time to identify any technology gaps and fill theme by either training existing team members or hiring additional devs with the right skills.
Remember, as you are trying new things and setting your bar high for the team members, it is good to provide training/educational sessions to team members for emerging technologies and utilize their skills for the betterment of the product.
Step 3: Infrastructure
It is important to utilize the greatest and latest infrastructures for quality strategy. It could be a dedicated staging environment or a continuous integration tool where automated integration feedback can be provided. Software projects are a lot more complex than they were before, so it makes sense to have the right infrastructure in place to provide better software delivery. If we have a continuous integration server in place, it can save a lot of integration time and provide early feedback to the development team about integration challenges and it has a direct link with the delivery speed and potential integration defects in the system.
Step 4: Continuous Improvement
The team regularly reviews what is, and what is not, working well. In Agile, there is a ceremony called a Retrospective, and it could be just a weekly team meeting in other methodologies to discuss pain points in the project. The point I want to make is that it is extremely important to review how your quality strategy is working and if any changes are required then you should brainstorm with the team and make suitable changes.
It is important to review strategy periodically and refine that for the betterment of the team and the product.
Opinions expressed by DZone contributors are their own.