Are you a developer struggling to get User Stories through QA? Or a quality professional being disregarded by developers? This article will help you to build a better relationship with your team, and make for a seamless transition from ‘QA’ to ‘Done’.
One of the most difficult relationships in a software development team is the relationship between developers and the QA team.
Speaking from a developers perspective, there may be an unfortunate perception that quality professionals are paid to find problems with software developers’ work, because they review our work once it’s done and flag problems or issues with it.
This can be difficult to swallow for some developers, myself included. We spend hours writing code, unit tests, and reviewing PRs, only to have someone throw our work back, telling us it’s not good enough!
Sometimes I feel for the Balrog
I hope through reading this article you’ll see the benefit in collaborating closely with the quality professionals on your team, and have a good idea of how you can start doing so today.
What’s the problem?
The idea that quality professionals are only present to find problems with developers’ work, and that they provide less value than developers, is simply not true.
Think about what QA stands for for a sec: “Quality Assurance”.
The definition of “assure” is:
Make [something] certain to happen.
So Quality Assurance means, “Make quality certain to happen”. A quality professional’s job is to make it certain that the team delivers a high-quality product.
If the QA team was called the Developer-Utilisation Assurance team, then we’d be having a different conversation.
Having said this, quality is not purely the responsibility of quality professionals, it’s the whole team’s responsibility.
Everyone on the project is responsible, in one way or another, for delivering a high-quality product.
If you want to build a productive working relationship with quality professionals on your team, you can’t go into a project thinking that they provide less value than you do.
Both of you provide great value to the project and, as we’ll see, neither can be removed without consequences.
Why do we even need quality professionals? Can’t I just test my own work?
User’s know very little, if anything, about how a particular feature was built or how it was designed to work. So they rely on their experience from other products, and their intuition to tell them how to use your product.
This might not always match up with your intentions for the feature, and this can lead to a poor user-experience.
Your product might not be as intuitive as you think
Your product might not be as intuitive as you think
As the person building the feature, you tend to have the “happy path” baked into your head: you built the feature a certain way, so you test it the way you intended it to be used.
One of Rangle’s Technical Directors, Evan Schultz, shared his insight:
“A good QA brings another perspective and set of eyes, and can find things that you might miss. I’ve found that the QA’s I’ve clicked the most with — I start to anticipate the edge cases they are going to test for, and try to account for them. Likewise, they tend to know the gaps I might have, and they test for those.”
It can be very helpful to have someone with a completely different perspective, and a less-detailed understanding of the inner-workings of the feature, to come along and try to use it.
If you think you can do that as a developer, don’t kid yourself. It’s very hard to break out of the developer’s mindset and test your feature as a user.
It’s likely that you’ve spent a long time thinking about how to build the feature, so you know every aspect of it inside-out. All of that knowledge hinders your ability to play the role of a user.
So, yes, we need quality professionals to help reduce the number of bugs, poor UX, and typos that make it into the final product, by testing it from a user’s perspective.
At Rangle, we look at quality holistically because we believe that quality needs more than just testing.
A tale of two teams
I recently had a fantastic experience with a client and their team. It’s an excellent example of how good the relationship between developers and quality professionals can be.
Side note — normally I’d use individuals’ real names, but, for client confidentiality reasons, I’m going to refer to the QA team as “quality professionals”.
At the beginning of the project, I think everyone was still a little uncomfortable working together.
So the client’s quality professionals added some comments to our User Stories, and put them back to ‘To Do’.
This was fine at the start, so we continued working like this.
A week or so later, I started to get some messages on Slack from the QA team, “Is ticket 98 in QA?”, “The calendar dropdown isn’t displayed, is that expected?”
I was getting quite a lot of questions, which is frustrating as a developer when you’re in the middle of a focused coding session.
I found that my Stories were being automatically transitioned to ‘QA’ status, without the features being present in the QA build.
Automated systems ain’t that clever
Automated systems ain’t that clever
I’m sure this must’ve caused frustration and confusion for the QA team too. If I was in their shoes, I’d expect the Story to be in the QA build too.
I could’ve let the matter drop. It’s not my problem, the QA team can figure it out! But I don’t believe that’s the right way to build a relationship with my co-workers.
So I brought it up at stand up, and we all agreed that the auto-transition was a problem. Stories should only be in ‘QA’ if the features are in the QA build.
Talking openly about the issue, and taking input from all stakeholders helped us to move forward and improve our process.
Soon after we removed the auto-transition, the quality professionals started coming to my desk to discuss specific issues.
This really helped speed up the development cycle. They didn’t have to struggle to describe issues via Slack, they could just come to my desk, show me the problem on their laptop, and discuss the problem with no delay.
After this, it felt like we were all on the same team. The “us and them” feeling disappeared. We were all working towards the same goal of delivering a high-quality product.
Now I felt confident enough to go over to their desks to discuss issues. It would’ve been easier to sit on my butt and write them a message on Slack, but not as productive.
The final hurdle
During the final 2 weeks of the project, we started to come up against a new issue, bugs being created for features not listed in some User Stories acceptance criteria (AC).
This is frustrating for developers for a couple of reasons:
- It looks like we’re delivering poor-quality code because there are a number of bugs in the backlog
- It adds on to the work that we’re responsible for, making the backlog longer — It feels like a kind of scope creep
Generally, if a feature isn’t listed as an AC, it isn’t going to get built.
Of course we apply common-sense here, if we think there’s something missing from a Story, we’ll discuss this with the team and the Product Owner will decide if it’s worth spending time on. Otherwise we build the feature described by the User Story.
There’s a fine line between a new feature and a bug. Sometimes small details are missed from a Story, some people think a certain detail is implicit, but the people building the feature might not be aware of the implicit detail.
Sometimes it comes down to personal preference, and people’s preferences vary wildly.
That’s why we have multiple eyes on a feature, to ensure the feature is being built as the team and PO would like it.
Back to the story.
We discussed the “extra ACs” with the whole team, and agreed that if a piece of work doesn’t deliver the minimum requirements of a Story (as defined by the ACs) then either a bug can be created or the ticket put back to ‘To-Do’.
This simple change, turned what was a challenge into an opportunity for open discussion and collaboration. The QAs and developers were enabled to agree to this on a case-by-case basis.
We also agreed that additional requirements (i.e. those not part of the original Story) must be discussed with our PO, and a new Story would be created and prioritised if a change is required.
Again, open communication and collaboration with the team helped us to resolve an issue.
By the end of the project, our clients were able to release their new product to their customers.
This wouldn’t have been possible without great effort from both the development and quality professionals, and all other team members for that matter.
Cool story, Bro. What’s your point?
We encountered a few issues on the project:
- Inefficient communication — It’s difficult to explain bugs via Slack
- Out-of-sync Kanban board
- Bugs created for “missing” features that weren’t ACs — Probably partially caused by us not discussing a “definition of done”
Some of you reading this might be thinking this project was a walk in the park. Don’t get me wrong, it was a GREAT project, with very few issues. I’m just highlighting the issues that we encountered when working with our client’s quality professionals, and how we overcame them before they were out of control.
Any one of these issues could’ve become major if we hadn’t done anything about them.
Now that I’m writing this down, I’m realising that we solved all of these issues via open, transparent communication and collaboration with the whole project team.
Wow, what a revelation…
You probably knew this already, but knowing and practicing are two very different things. So here’s proof that this actually works.
Yes, talking to people about a problem can actually be beneficial, even if it’s a hard thing to do, even if you don’t want to come across as a complainer complaining about some seemingly small problem.
Small problems become big problems when they’re not addressed.
When it comes to crunch time, things get compounded, and blow up, so deal with them when they’re small and manageable. Preferably not the day before a big release.
A quality professional's perspective
Photo by Paul Skorupskas on Unsplash
So far, we’ve only discussed this from the developer’s point-of-view, but what about the quality professionals? How do they see our relationship? And what do they think we could do to improve it?
I spoke to one of the quality professionals on my current team, Mitch, and his point-of-view is that some developers don’t realise that quality is the whole team’s responsibility. A developer’s work isn’t done until the story has been tested and accepted.
“I think that the only real issue I’ve had with devs in the past is when they don’t realise that quality is a whole team responsibility, and that they aren’t really done their work until it’s tested and accepted”
Mitch shares my view that we have to realise we’re all on the same team. We’re all working towards the same goal: to deliver a quality product.
He feels that some developers still work with a “throw it over the wall” mindset, as if once the story is in QA the developer’s work is done. And I’ve totally seen this type of delivery happen.
Mitch also touched upon a key area of contention. What happens when quality professionals find a bug that’s not part of the acceptance criteria of a story?
We’ve all been there.
Personally, I find this difficult to deal with. If my story is in QA, I’ve probably moved on to another piece of work, and now someone’s telling me I need to go back and fix something with my last Story.
I’m generalising here, as every situation is different, but usually my team is under pressure to deliver some number of Stories in the current sprint, so I need to know that the bug found by the QA team is worth spending time on.
This is something Mitch has found frustrating in the past:
“I’ve felt like I’ve had to build up a case and make sure that I’ve done enough digging and investigation to make sure I can deflect the initial rounds of defensive questions like, “Well did you try this?” Or, “Did you check with this team first?” Rather than having an open discussion about what the expected output should be, and working together to figure out the best decision for the situation.”
Again, Mitch suggests that the best way to resolve these kinds of dispute is through open, transparent discussion.
Don’t come into the conversation with the mindset of strictly adhering to the ACs. You’re not a robot, you’re human, and so are the quality professionals you work with.
We’re all on the same team after all, so why can’t we have an honest conversation?
Something else that Mitch said sparked my interest:
“I think QA and Dev don’t talk and/or try to share knowledge enough. Both to propagate the ‘quality is a team responsibility’ mindset (ex. pair testing earlier in the development process), but also just to learn from one another, pick up new tools and techniques, and to better understand the overall process/system they’re working in.”
We don’t have to work in silos. There’s a lot to learn by sharing your experience, including all the tips and tricks you’ve picked up over the years.
Be open to suggestions and you never know what you might find out.
How much can you learn by having a more open conversation with your QA team?
The key to it all
If you remember only one thing from this article, let it be this:
Open, transparent communication about your issues will strengthen your relationship with quality professionals.
That’s my number one takeaway from this project. And I only realised it by writing this article.
The biggest challenges you’ll come up against when working with quality professionals will be inter-personal. Technical challenges pale in comparison to these, they can be fixed with a few keystrokes.
Inter-personal issues take more effort to fix: misaligned expectations, poor communication, and plain, old personality mismatches.
“Even if a QA is non-technical, there’s still benefit to talking through a little bit about how something is built — Devs will likely get different questions/comments from someone who thinks about testing the overall system much more regularly.” — Mitch, Business Quality Analyst @ Rangle
I promise you that improving communication can solve the large majority of problems you have with quality professionals.
And if you’re a quality professionals, the converse also applies! We’re not just code monkeys 🐵.
So next time you have a problem with a quality professional, talk to them, bring the issue up in stand-up, and discuss it openly. I’m sure you’ll come to a positive outcome.