10x your collaboration on writing tests

Collaboration is the process of two or more people or organisations working together to complete a task or achieve a goal.

There is an African proverb:

“If you want to go fast, go alone. If you want to go far, go together.”

Have you ever noticed any silos in your teams? Have you ever come across an “them vs us” situation when it comes to your tests. Do you find automation is sidelined from the software development process, and treated as an afterthought?

What you need is a little collaboration!

I am Qambar Raza, the Senior Software Engineer in Test for iPlayer and Sounds.

And

I am Sheila Bhati, I’m a Senior Tester in iPlayer mobile.

We decided to collaborate on this blog post, about our experiences of how we’ve helped improve collaboration within our teams.

Change understood by everyone

Scenario 1: Change understood by only one person

Have you come across a project which heavily relies on a certain member of the team knowing everything about it ? During stand-ups you will see that person talking about what’s right and what is not and the whole team would nod in agreement.

Scenario 2: Change is partially understood by everyone

What about releases? Have you ever been scared to release something to production because you don’t know what else is included in the release apart from your own change? This becomes more complicated with time when the change starts bundling up to a point where you are releasing 50 commits in one release. How confident would you be with that?

How did we solve it?

For scenario 1, we propose XP practices which means constant pairing on writing code and cycling the pairs for tickets to spread the knowledge across the team.

For scenario 2, everyone in the team should have the ability to understand the change that is being made in the system clearly. This is only possible if the size of change is kept small. In an ideal world that would be one atomic commit that gets released to production after it goes through all the phases of Software Development Lifecycle.

If change is small, then it will be easy to understand and communicate, not only within the team but also outside the team to stakeholders. Everyone in the software delivery chain would be aware of what and why the change was made and would be able to support their customers better.

We understand that sometimes it is not possible to do atomic commits and the change could include multiple commits. Although we highly discourage this practice we have a temporary solution. Within a department where multiple teams are involved in the change you can use the method of “huddle” when the change is being released to production. It helps you share knowledge between teams about the changes committed by members of each team and ask questions about risks.

The problem with doing a bundled release is the rollback or revert process. For example you release five changes together to live and, out of the five, one of the features is completely broken. How would you deal with that? Would you just do a full rollback? Or do you prefer a roll forward approach or patch based approach? The roll forward approach takes longer as you would be putting a “proper” fix in the release and for that you will need developer effort. The patch approach since its a quick fix there are chances of side effects. Rollback would mean that all the features that you just demonstrated to your customers are taken away from them. This will damage your trust with the customers and could have a big impact on your organisations reputation.

A better approach is to keeping things simple, releasing everything you have from commit to production has several benefits:

• Team members are happy and onboard as they understand the change
• Customer happy as less disruption and confusion in the product
• Stakeholders will be happy because they can understand what is live and what did not
• The Test Team would not have to create complex test scenarios in order to approve the change which means testing would be faster
• Your overall pipeline process would be smoother and faster

In order to understand the impact of a change as a team, we need to create a shared understanding of the change. So how can teams go about building that shared understanding?

Help create a shared understanding between developers and testers by encouraging developer and tester pairing

When work in a team isn’t aligned and automation is put in place retrospectively rather than at the time of development, it can increase the burden on manual exploratory testing and ultimately increase risk of bug leakage. Which potentially requires rework on issues found late on in the development cycle. Collaboration between Dev and Test teams helps to ensure test automation is part of the definition of done. By not having to develop automation retrospectively you can maintain focus on the current task, smooth the process of delivery, and the team will have more confidence to deliver features faster.

In our experience by introducing pairing practices, dev and test can agree which tests are required and where to include them at UI level, integration or unit test level. This helps in a number of ways:

• Creating a shared understanding of test coverage
• Reducing duplication of tests and the effort to maintain them
• Exploratory testing focuses more ways to improve a product, rather than being a bug safety net.

Overall it contributes to a reduction of risk and can help teams go faster.

This is just one blog post out of the series that we are planning to write to share our experience with you. Please feel free to comment and share how you collaborate within your teams.