The Challenges of Quality Assurance

This article was last updated in December 2021.

Quality Assurance has always been an evolving challenge in software development. Are we doing enough? Are we asking the right questions? Are we catching the right bugs? These are all concerns that cross our minds during the process. Each of us has a different way of dealing with these questions on an individual level. But how can we ensure as a team that we are addressing these questions and more? A project team these days may include multiple developers, project managers, designers, solutions architects, supervisors and clients. Such a group can present challenges not only for the sheer number of individuals on the team, but also the diversity of that team in terms of skill set and role in the project. In this blog post we highlight two of these challenges, namely communication and verification, and how we can deal with them.

Speak the same language

The first challenge on our list is communication. As mentioned above, a project can include many individuals with diverse roles and skillsets. The challenge of effective communication is that more often than not they don’t speak the same language, and we don’t mean like English or Mandarin. However the differences between for example: designer lingo and developer lingo can cause confusion, unnecessary errors and delays.  

There are a few things we can do to make this experience as smooth as possible. We use a team collaboration tool called JIRA to help us track tasks and communicate more effectively, because it allows us to share comments on a specific task and have them readily available to the entire team. But having an effective tool is only part of it, the key is how you use it. The first step is provide context so that everyone has a chance to change gears and be on the same page as you. So what do I mean by context? I think of context not only as a frame of reference, but also as a guided path which starts from that frame of reference. For example: When reporting a bug to a developer. First of all it is important to realize that the developer fixing the bug is most likely not the same one who initially created that functionality. They will need to know which project it is for, which feature(s) have been affected, and quite possibly what the feature is supposed to do. They will need to know this information before you tell them what needs to be fixed.  

The second part of effective communication is telling them about the issue. It is important to not be blunt or abrasive when pointing out an issue that needs attention. Being sensitive to the fact that developers are usually under a lot of pressure to deliver will always help get you on their good graces. Sharing with them your mindset that they are actually helping to improve a product and take it to the next level will receive a much more positive response, then giving them the feeling that you are pointing out mistakes. Give the developer confidence that they can achieve the task at hand and that you will support them if they need help. This will not only help build rapport, but will also help them see that the task at hand is not as daunting as it seems, and can be solved with a little effort from both of you.

Verify the resolution

The second quality assurance challenge on our list is verification. Despite our best intentions sometimes things just slip through the cracks and issues that were thought to be resolved actually weren’t. You have put in time and effort finding those pesky bugs in the system, and the developer has spent time and effort on fixing it and the issue seems resolved, but was it actually resolved? Verifying that issues have been resolved can give the entire team great value. Usually it’s just one more small step between the issue and resolution, and a run through (or two) of the resolved bugs list can help coax out those pesky, unresolved bugs. The challenge arises in proving that the issue remains unresolved even if the team thinks it differently. As with effective communication it helps to be as descriptive as possible.

• Provide the team with the steps you went through that resulted in showing that the issue still exists.
• Supplement your descriptions with screenshots of the issue whenever possible.
• Be open to challenge from the team, they may not be able to recreate your results, you need to be open to questions and help them see it from your point of view.  
• Remain open minded you could very well be the one who is wrong, you may think the issue persists but the test server you are working on may not have been updated with the fix, this is why the constructive dialogue is important.
• Never become confrontational, even if members on the team don’t see it your way despite your best efforts, but don’t give up on the issue either if you believe the issue persists keep up your effort to try and convince them.  

The value for the effort comes not only in having remaining issues resolved, but also you are getting a review done at the same time as an added bonus. This review can give the entire team including the client confirmation that they have done a good job, and confidence in the fact that their solutions are solid.

By communicating effectively, and verifying the work that has been done while at the same time remaining non-confrontational, constructive and open minded, QA challenges can turn into a positive exercise for the entire team. The exercise can build cohesion between team members, inspire confidence and at the same time take your deliverables to the next level.