From my experience working as both a developer and a tester, I’ve noticed that there tends to be a sense of friction between the two teams. This seems only natural considering a tester’s primary role is to point out what’s not working in a developer’s code. My current company has found a way to avoid this tension, however, by setting up collaboration hacks from the beginning of every project to guarantee we win every time. Here’s how we do this.
When I was a developer, I would often get frustrated when I had invested days’ worth of concentrated effort in a project, only to have someone point out that I’d overlooked something hours before deployment. Now, as a tester, I’ve felt that frustration from the developers on my new team when I had to be the person to tell them that there was a bug in the code just before something launched.
While this friction can be viewed as a natural human interaction – no one wants to have their mistakes pointed out, and, on the flipside, no one wants to be the bad guy who’s constantly nit-picking – it really affected team dynamics, which in turn affected how we delivered on the work we were tasked with.
The company I’m currently working at, however, has found a way to establish a collaborative relationship between the two teams from the beginning of a project.
This means both the developers and testers feel like equal contributors and know who, when and how to communicate with each other for the most effective results.
Here are the steps we take to do this:
- We plan thoroughly
- We clearly define responsibilities
- We maintain strict visibility
I’ll discuss these in more detail to give you a sense of how we do this, so that you can implement this approach too.
Planning thoroughly
When I worked on a team that didn’t factor planning into a project’s roadmap, I found that we ended up winging it and hoping to have an awesome product at the end of it all. This inevitably didn’t go to plan and got very messy because when things went wrong, there wasn’t a reference point and a lot of blame went around between the teams involved.
The company where I’m now working as a tester understands how important this initial phase is. We have built proper systems that we make sure to follow every time we start something new. These look something like this:
We establish who will be working together
At the beginning of the sprint planning, we make sure we’re clear on who the developer, product owner and tester are for each task. Doing this means there are known check-in points for anyone who has questions when we kick the project off. In Agile, this approach is known as, or rather, affectionately referred to as ‘The Three Amigos’.
We define the project’s acceptance criteria as a unit
Once the team has been defined, we work hand-in-hand to define the project’s acceptance criteria. We use the Gherkin Syntax to define acceptance criteria, which, much like Behaviour Driven Development (BDD), documents how the software is intended to function. This helps us think about the outcome of a specific feature or user story before development even begins, so that there is an agreed upon goal that we can all work towards.
We set up regular check-in sessions as a micro team
I’ve found that spending this extra time on planning has helped us understand that the quality of the final product is everyone’s responsibility, no matter where you’re involved in the development cycle. Checking in with the dev and product owner I’m working with on a task regularly helps to see where everyone’s at, and reinforces accountability. It also helps cement the idea that we’re all really working towards a common goal from the beginning, which encourages more camaraderie.
Assigning responsibilities
As much as we are all a team working towards the same goal, it’s also important to remember that all team members have a unique role they need to play in order for the project to be successful.
By establishing this at the beginning of a project, I’ve found that it helps everyone on the team understand what their teammates are responsible for so that we can better set expectations.
We do this by using Microsoft Azure DevOps, where we have a scrum board with colour-coded tickets that are assigned to either the developers or the testers depending on the task at hand. With these tickets, the project manager can easily gauge the progress of a user story or feature, and its readiness for deployment. Each team member is responsible for ensuring that their respective ticket clearly reflects their progress.
Having this system in place has proved to be very effective when it comes to team dynamics, and, through having a stronger relationship with each other, we’re able to do the following things:
Complete work faster because we’re more focused
During our daily stand-ups where we work with the scrum board, we can all see who is working on what, and exactly how far they are with that task. This is also a great platform for team members to talk about impediments, so we can stay on track with our goals as a team.
Establish well-oiled communication channels, which help resolve queries quickly and more positively
For instance, when a ticket is moved to ‘ready for testing’ on our board, I know that I can immediately start testing the feature. On the same ticket, I can see who the developer is that worked on the ticket and know who to assign any bugs arising from said feature. This way, the bug is immediately picked up and resolved, meaning I can start retesting straightaway and have the fix deployed. Work is constantly flowing and team members are constantly collaborating! Win!
Strict visibility
As with anything, I’ve really found that the key to relationships succeeding is clear communication.
We’ve learned that being visible about what we do and when, as well as any difficulties we encounter goes a long way in helping us avoid friction and work effectively as a team.
In order to make it as easy as possible for each of us to check in with each other, we do the following things:
We define what our capacity looks like
As a software tester, I’ve learned that one of the seven principles of testing is ‘exhaustive testing is impossible’, which basically means that you can never test a piece of software or functionality ‘completely’. There are bound to be bugs that fall between the cracks. That said, my team and I still give 110% to ensure that the software we ship to production is of the highest quality attainable, but we make these limitations clear to the rest of our team to avoid setting the wrong expectations.
We build systems into our process that make visibility something easy, not something we constantly have to worry about
Using Azure DevOps for our testing allows us to generate a report to show testing progress, which gives all stakeholders a view of what test cases were run, which passed, which failed and many other factors they might be interested in.
The importance of having these metrics helps to not only keep everyone on the same page about the state of the project, but also acts as a reference point should questions like ‘Are you sure this was tested?’ or ‘Why was this not picked up in testing?’ arise.
We keep track of our individual team processes in an easily accessible place where anyone from other teams can access
Although we make a big effort to collaborate on projects, there are obviously ways of working and niche skills that the testing and development teams have that the other maybe doesn’t know much about.
To help answer any questions that come up about how we do things when we’re testing software, for example, we have a document repository where testing processes are explained simply, yet descriptively. The aim of this is to help everyone get on the same page about what we do as testers, as well as create a sense of involvement for everyone in the company who might be interested in learning more about testing.
To conclude, my company seems to have struck a sweet balance between our testing and development teams by setting us up well to collaborate throughout a project’s lifespan. I’ve found that this has not only helped improve my day-to-day experience at work, but it’s also resulted in higher quality deliverables that I’m proud to have been part of.
Khanya Mbini is a dev turned software tester who works for NML in Observatory, Cape Town. She’s a bootcamp graduate and this has made her very passionate about getting more unemployed youth into the tech space. When Khanya is not reading blogs on software quality and inclusivity in the workplace, she is spending time with her little human beings.
