Early Feedback Is Critical

One of the things that I appreciate the most in the team I’m working with is the fact that we’re constantly discussing new ways of improving our work, new ideas of making our processes better and better and in most of the cases we come up with very cool and helpful ideas.

In one of those brainstorming meetings, we reached to a less known model for us since then, the Atlassian model, introducing the concept of quality assistance. The article focuses on describing the transition from quality assurance to quality assistance.

Having this topic in mind, we thought “how this new thingy, quality assistance, can help us and if and how can it be integrated in our process?”. Well, as the song says, we did it our way.

I need to mention a very important mindset change that we have made. We, as software engineers (I try to include here all the folks involved in software product development), usually think of the quality assurance team as to the team which assures the quality of the product. We started to split the responsibility for product’s quality between developers and testers — the developers are the ones driving the development process and assuring the quality of the code they’re writing and the testers role is to flag any “deviation” from the requirements or the intended behaviour and raise risks about the quality of the product.

But what does “our way” mean?

When working using agile methodology and having fixed development cycles(i.e. sprints), it happens very often that the code gets to be tested on the last hundred meters of the development cycle or the code freeze deadlines are not met. We tried to adapt to this and we started to use a separate branch (other than master or any other feature branch you’re using to merge the code) where the intermediary code is merged and testers and product team (including business analyst and product owner) have access to it. This approach’s main purpose is to serve as an “early warning system” for identifying divergent work in shared code.

Main advantages:

• Early feedback in development process.
• Mismatches between requirements and what was implemented can be spotted earlier and saves a lot of time.
• Testers can find defects sooner instead of waiting the whole functionality to be ready. Defects that are found are not tracked in any bug tracking tool, but are directly addressed to the developers working in that specific functionality. This encourages a continuous communication between developers and testers.
• Product Owner can give an early feedback on what is going to be implemented and can make change requests if needed.

An important aspect that needs to be mentioned is that this new branch used for intermediary work is never used for cutting test releases. Its purpose is to help testers, business analysts and product owner to work closely to developers and assist them with early feedback with regards to the work they’re doing.

How do you manage to offer early feedback and assistance to your team?

Photo by Conner Baker on Unsplash.