How are we Assuring Quality in our team?

When we think of Quality Assurance, it’s easy for us to think tests, tests, and more tests. As much as this is a very vital part of delivering a quality product, it’s not the only requirement or basis for Quality.

Oxford Languages defines Quality Assurance as “the maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production”. This means that Quality Assurance goes beyond testing a functionality or a feature when development is done. It cuts across the entire development process and ensures that our output at every stage of this process is of optimum quality.

Here are some things we do as a team that I believe contributes to our overall product quality:

Pair Programming

It is quite common to work in groups of two or more in our team. This happens often because we believe in swarming on important tasks and completing them before starting another. While that is helpful, what I believe to be the bigger value in this way of work is that you have a second pair of eyes and brains to walk through problems and spots that could go unnoticed by a single developer. It also means that as a less experienced team member working with a more senior colleague, you are privy to certain hacks and ways of thinking that they have gathered from their wealth of experience, which helps you be better at problem solving.

Code review

As a team, we adhere to a certain level of code quality and this is something that every member of the team contributes to. We keep each other accountable and code reviews are not just another obligatory step in our development process. Typical code reviews get a lot of comments and nitpicks from team members. Not only can the team question why a feature was implemented the way it was, but they also give suggestions on ways to improve the readability and efficiency of the solution.

Writing tests

Our team is heavy on automation and tests are an important part of our coding practice. We don’t believe in deploying and writing tests later. Tests are just as important as a feature implementation. We don’t strive to reach 100% test coverage, instead we try to cover the most fragile and vulnerable features and functionalities to ensure trust in our system. As a data platform engineering team in Revel Systems, we implement the following test types: Unit, Integration, API, Snapshot, Schema, Smoke, Regression, Manual etc. But, every team should consider which test types are actually useful for their product and not just follow test trends.

Continuous delivery(CD)

Because we deploy to production frequently, we work with the mindset that our master branch should always be production ready. This means that our tests (including manual) are ideally done on the feature branch and approved before merging to master. This continuous delivery mindset also means that we are intentional about testing our work and only merging code we are confident in. This level of confidence is why anyone can deploy at any point in time. Another benefit of CD is that we are forced to release in small/medium batches or deliverables that are easy to track if something goes wrong.

Quality mindset

This is probably the most important point. Every team member thinks about quality in general: The Managers, Product Owners, Developers and QA all strive for quality in their work processes which leads to overall quality of our Product.

In conclusion, it’s important to know that even when there is a designated QA in a team, quality remains everyone’s responsibility. Also, when you think about improving the quality of your Product, don’t just think about increasing test coverage (although that is important), but also consider other ways to improve your team processes and practices.

Would be great to hear what other practices you have adopted in your team that you believe greatly improved the quality of your output.