Aim For Better - Quality Assurance Activities In Development Teams

Updated Oct 10, 2024 • 15 min read

If you are worried about the quality of the product you are developing, you may need to introduce some activities that could spark discussions around quality among your teammates.

Quality is perceived differently depending on the person, so a common understanding between product representatives, end users, and the development team should also be reached.

Software development projects require a lot of collaboration and knowledge exchange to make things happen. After all, we need to know what needs to be built and how. Experienced developers are aware of standards and common practices. Discussing them among less experienced peers may lead to solving technical challenges more efficiently.

It is quite similar when it comes to discussing quality. Skipping quality assurance topics brings many risks, so consider following the guidelines presented below.

The good news is that you may already have plenty of opportunities to include quality assurance, even without additional meetings or processes. For example, many scrum ceremonies may support brainstorming and knowledge exchanges, even in the areas of quality. Sometimes the only thing that is missing is the right perspective, mindset, and your expectations.

What are quality assurance activities in software processes?

Before proposing specific actions, some definition of quality assurance itself should be proposed.

Quality assurance is an ongoing process of collecting information, performing tests, and improving products based on test findings. Gathering information is the first step, as there needs to be a common vision as to what provides value for product users or its owners.

Understanding this can be used to define the needs and criteria that should be met. Then, you can move on to think of when and how to test your idea or ready solution against the criteria of success. Discussing the test findings may lead to further improvement of product, its maintenance, and flawless end-user experience.

All activities built upon that introduce elements of quality assurance into the work of the whole team. What are those?

What activities in software processes can include quality?

Across the development pipeline, there are multiple steps that a feature needs to take before finding itself in a product. One of the most popular working methods, Scrum, structures the flow of work. It will be used as a reference, but most of the recommendations can be applied in any other approach.

Refining the scope of work for the next increment of work is a practice that brings many benefits to the development process. Having an opportunity to ask questions regarding future tasks gives the product owners time to search for answers.

It also includes a separation of perspectives because during refinement the team can focus on collecting questions, searching for risks, and can consider quality. With refinement in place, planning can then be more closely focused on lower-level technicalities, estimations, and discussing priorities.

Since refinement is at the start of the development process, this is a point in time when there are most unknowns and risks. It makes it perfect for triggering topics around various quality requirements:

How does this feature contribute to the quality? Can it make the product worse? If so, how to make sure that doesn’t happen through testing?
When can we consider the solution is of high quality standards? What can be sacrificed without damaging the quality of the final product? Is there a shared understanding of product quality among teammates and stakeholders?
Can we fully apply our software testing strategy? Is there enough information for developers and QAs to plan the software testing process or automation activities?
Can we think of edge cases? If the feature is too abstract, perhaps more clarifications are needed before we are ready to estimate the work required.
What about quality metrics? How do we review quality metrics to know the solution will satisfy all stakeholders?

Anyone can ask the above questions. Asking early helps minimize risks and inefficient work, as fixing or changing the solution at a later phase will be more costly.

Planning

When the team is ready to plan work for a sprint, you should already have an idea of which features you want to create. If all questions during refinement were answered, is there a need to consider quality during planning itself? Of course. After all, we are changing the perspective slightly so we can focus on the software development process itself in more detail.

How is the work divided for the next sprint? Think carefully about when development will be done, and make sure you don’t complete all items at the end. After all, all features should be tested, and it is wise to leave some time for possible bug fixes.
What about deployments? Will there be a single deployment or multiple ones? Knowing the scope of changes, how long will regression testing take?
Do we need to prepare a quality assurance plan for testing a specific feature? Perhaps it could help devs avoid some missed edge cases if we present at least some rough schedule of testing.
Perhaps developers should support the software testing process in order to release in time? If so, make sure not to pick too much development work.

Other than focusing on the questions above, check whether the answers from refinement were provided. Any delays may help uncover areas that have a high risk. Make sure to discover the difficult topics and make sure to introduce risk management to them.

Development

As a developer, do not forget quality. You should have some ideas already from a QA as to what could go wrong. If you lack some information or you uncover something from the code that may be worrying you, do not be afraid of reaching out.

QAs may help you dig up more edge cases or suggest some solutions. When you are close to finishing your work, take a look at the test plan one last time and see whether you missed anything.

Code review

Having your code reviewed is already one of the most important quality assurance activities. Make sure every code change is being reviewed by a fellow developer. In a pull request, provide some details to help the reviewer understand the context of a change.

Code review is a dialogue, ask questions about the code and don’t be afraid to question a remark if you don’t agree with it. Be respectful and remember that you are reviewing code, never the author. Some important quality-related areas to consider include:

Are unit tests present? Are they written in a way that is easy to understand?
Is the API documented?
Is there a link between the pull request and the requirements? If you are using a work management tool, make sure to provide a link to a specific task.

After you are satisfied with your code after review, merge it and test it at least shortly on an integration environment. Your development setup is different from an actual setup and some issues may be missed without considering how the application behaves on your shared server.

Waiting for testing results for hours/days and then finding out that due to a minor configuration issue, the change was not even present on the shared infrastructure is quite frustrating.

Testing

Software testing is an activity that provides probably the biggest impact on the quality assurance process. Even if your team doesn’t have a dedicated QA, consider adding this phase to your workflow.

Testing itself is a broad topic that cannot be fully described in this article. If you are not sure how to start, check our articles on testing. Here are some tips that can help you build a better testing culture:

Have developers provide tips for QAs in a ticket after completing their work. Providing links to documentation, tips on creating test data, etc. can significantly speed up the testing process.
Consider adding desk checks – short calls meant for presenting a solution to a QA just before testing. It allows for a quick feedback loop and may also increase collaboration between the devs and QAs.
If there are some bugs, consider whether they should affect the completion of a feature. Perhaps some minor fixes could be done at a later time if the deadline is a factor to be considered. Just make sure to document all issues in a work management system.

Deployment

When you are satisfied with your solution and its performance, it is time to publish your changes to the end users.

This may be a stressful activity if you lack confidence. Automation and production observability increase the feeling of safety. First, they help with quick regression, making sure that core features are working as they are supposed to. Second, they allow for a quick feedback loop as we can observe whether any errors are appearing or whether some business results are dropping.

How confident are you with the deployment process? Are you prepared for things to go wrong?
Do you have a rollback procedure? Is there a backup/recovery procedure? When was the last time you performed it?
How long does it take to go from merged code to production? Consider improving your process to speed up deployment times and regression testing duration.
How long can the business continue to operate if a critical issue prevents the app from working? Can you disable the failing features, at least allowing for some functions to work?

Questions asked above usually cannot be addressed during the deployment phase. At the same time, keep your eyes open for those and note down any possible improvement ideas.

Demonstration or sprint review

Stakeholders of the application you are building may be interested in seeing the changes. Preparing a demo for this group may help with gathering feedback. Besides presenting the solution, you may also ask questions and test some of your theories.

Observe which of the areas gather the most interest, and which areas are criticized the most. Whilst it is too late to change things, you may adjust your approach in the future. On the other hand, stakeholders may be very satisfied and can work on promoting the application and its upgrades.

Retrospective

Upon completing the work increment, you may be urged to start working on the next items. On the other hand, It may be more valuable for the team to stop and reflect for a while.

Retrospective meetings give an opportunity to raise issues, come up with improvements and brainstorm for solutions. Think of the quality of the past increment, and feel free to challenge the team to keep improving.

Ask the team how satisfied they are with the quality of the project. Perhaps technical debt is rising.
What was the biggest issue that happened?
Has the test strategy helped the team? Should we adjust the process to detect some issues earlier? Are there any areas that couldn’t be confirmed due to limited testing scope?
Have any of the risks materialized? Perhaps the other way around, the probability of a risk should be decreased and testing efforts limited for such areas.

Keep tracking the team’s approach towards quality during each retrospective. Keep in mind that all decisions affect stakeholders (especially application owners and end users). Try to connect your actions with observations and feedback from those groups.

Bonus quality assurance activities – build a quality mindset

The previous section focused mostly on development processes that you may already be performing, providing some tips on how to bring the topic of quality to them.

Introducing the mentioned changes will certainly impact quality, however, it may not be enough to build enough ownership and involvement for each team member. If you want to build a shared community and provide some exclusively quality-focused meetings, try some options presented below.

Bug bash

A Bug bash is a time-boxed session during which participants are trying to find issues in the product. You can invite the whole development team or even people outside of that team to participate. Try to limit the scope to be checked – perhaps to an area that you were working on recently.

Prepare a short introduction, a way for participants to report all issues, and consider giving a separate challenge to each participant. Allow asking questions during the meeting as some people may not be as fluent in using the application. Make sure there is enough test data to perform all needed actions.

Bug bash significantly boosts the feeling of shared responsibility. It becomes a competition of who will find the most issues, the most interesting one, or provides some user experience improvement idea.

Some developers don’t play with the application on a daily basis, allowing them to see it working may also impact the feeling of appreciation for one’s work. Of course, you also gain a whole list of bugs to be addressed.

Quality assistance

Introducing a dedicated tester into a project team may not be an approach you prefer. You may be interested in an approach where developers gain the skills and experience in testing their code.

Removing a dedicated person experienced in testing itself has its cons, but it can still be enough for some projects if you support the devs with their growth. Quality assistance is an approach where an experienced QA engineer teaches the team how to elevate the quality to a higher level. Such a QA limits the amount of testing personally in order to focus on giving guidance to others.

Quality assistance is an investment that takes some time in order to fully reap the benefits. To maximize the chance of success, make sure your development team is open to such a growth opportunity, as there may be some resistance.

Additionally, make sure that the person performing quality assistance is supported by the team. After all, without as much time to familiarize themselves with the application, a QA may not be able to predict all possible quality issues. QA may help design the best process for quality, but the decision to follow the process lies on the developers in such a setup.

QA Audit

If an area of quality was neglected for a long time and you didn’t have a QA in your team, you may want to start with a quality audit in order to understand the situation that the project is in.

QA performing an audit will check and possibly improve the QA flow of the project. Potential future issues could be found, good QA practices shared with the team. Some guidance on growth can be provided to less experienced teammates. Audits end with a detailed report, outlining the good and bad, with specific tips on how to improve the quality.

Audits should be performed by an experienced QA. Netguru has senior QAs that can perform a complete QA audit on your project. You should provide enough time and support for sufficient observations to be made.

High-quality audits include interviews with team members and gathering their pain points to make sure they are available. Upon hearing results, remember that the audit is aimed to help the project improve, so don’t take the results personally.

Quality assurance is a team effort

Quality is an attribute of our product. Special attention and time should be invested in making sure that we are satisfied with the outcome. Quality can always change for the better (or worse), so taking it into account should be done on a regular basis.

This article showed that all phases of a project may benefit from discussions about quality assurance. Having a dedicated QA will help make sure all of the mentioned areas will keep improving, but hopefully, you can start on your own with the activities proposed in this article.