At Klima, we’re all working together to achieve a common goal: to create an engaging way of removing CO2e from the atmosphere. Climate- and company-wise, we are all in the same boat, so even though our daily activities may seem like individual work, our contribution is measured within the context of the whole team. That's why we know that sitting together in the same boat just isn’t enough. Ideally we’re not only rowing in the same direction but handling the oars effortlessly.
In that notion, our developers have always worked very closely with the QA team. As our processes continue to evolve, we want to share some of our findings on how developers can try, with small mindset changes, to not only work more efficiently with QA, but leave enough legroom on the boat for each team member to feel comfortable, appreciated, and effective — basically replacing those annoying paddles with a proper jet boat engine.
TL;DR:
- Mind the self-assembling bias. Your code could be great, but it's easy to lose objectivity when you are evaluating your own work. When coding and testing, be doubtful and vigilant, not optimistic.
- Every bug is a learning opportunity. Maybe you’ve missed something, requirements were unclear or changed, edge cases weren’t covered — each bug is a reminder on how to prepare for the future.
- Every bug is a win. Appreciate when bugs are caught before they reach your users, and don’t take them as a source of frustration.
- Information flow is crucial for keeping the quality high. QA team often works with a black box. Share additional, relevant information with them about implementation or possible regressions to make that box a little less obscure.
- Consider pairing with QA engineers. Fellow QA team members can shed some light on a suggested solution, help ensure all edge cases are covered, and bring business knowledge and end user perspective to the mix.
- Be a dev first and a QA second. Be proactive: test what you build and report or fix any issues you find along the way, even if they’re not necessarily part of your code, so they’re fixed before they become a problem down the line.
📼 Try to break your Kassett
The IKEA effect is a cognitive bias in which we attach disproportionately high value to items that we assemble ourselves. One study showed that we are willing to pay significantly more for a standard IKEA Kassett storage box if we made it ourselves.
While programming is definitely different from assembling Swedish furniture, the bias stays the same. We value the code that was written by us (sometimes) disproportionately highly. It’s easy to be emotionally attached to solutions that we’ve ideated and executed, so we tend to be optimistic. But software development is not a place for optimism, it’s a place for doubt.
As a developer, you know all the details of implementation, so before you say that you’re done, consider if any changes introduced might cause some random regression, and investigate that. Ask yourself how well you’re prepared for integration, since the bug in your code could be triggered by the code of other teams, and investigate that as well.
Test your own code and think of ways to break your Kassett before you push the code out, and a realistically high value is going to be attached to it, not only by the QA but by end-users. In the process, you will learn how to look at your code more objectively — in the above-mentioned study, when participants destroyed their Kassetts, the bias had suddenly dissipated.
🐞 Learn from your bugs
You’ve investigated additional cases, pressured your code to break, and everything looks okay. Yet the ticket, after a short stop in the QA department, has come back at you like an agile boomerang. But while it could mess up your workflow, it’s a perfect learning opportunity and a way to enhance your skill set.
Besides searching for (and fixing) the root of the issue, try to understand why the bug was there in the first place. Was this a test case you forgot to cover? Here's the motivation you needed to cover them all next time. Can you cover it with a unit test? If not, can you cover it with a UI test? Is it related to legacy code? Take note, so you have more arguments when prioritizing working on tech debt with product! Tickets will still come back again, but use each occasion as a learning opportunity to reduce the chances of running into more bugs.
Bear in mind that the problem may lay in your code, but also on poor requirements or miscommunication. If the code is the issue, you will be better prepared to tackle this case next time. If it’s a requirement or miscommunication, be the spark to trigger a conversation about the issue. QA will back you up in no time, since high quality must be a trait of every phase of the development process — from feature ideation, to creating specifications, to post-launch analysis.
🏅 Turning bugs into wins
Bug reports can easily be a source of frustration, but you can also think of a bug report as a win: an issue was spotted by your team instead of your users. The unknown risk was identified, making planning more efficient and the release process safer. That’s a win. You’ve encountered a great learning opportunity, a way to prepare your code for another case, and enforce your code with additional tests. It’s. A. Win. Any person who finds a bug should be rewarded, and yet, quite often, the “author” of the bug is unhappy about it.
Frustration is not productive. It blurs your focus. When receiving a piece of feedback, consider how you respond emotionally versus how you react pragmatically. Paraphrasing Marcus Aurelius, choose not to be harmed, and you won't feel harmed. Choose to focus on growing with each bug and on working with the QA team (and not against them).
💬 The information must flow
While your fellow developers, simply by peer-review, possess knowledge about the changes you are trying to commit, fellow QA engineers are rarely part of the code review process. They receive a black box to analyze, and sometimes that box is weirdly big for the change or feature that was requested.
Perhaps the “black box” is bigger than expected because a bug investigation or a debugging session revealed that a small change will require minor refactoring in seven different places. Some of those places can be related to a critical flow or are prone to break for different reasons. QA team members can decide to spend time investigating and understanding the code changes themselves, but as long as they're not a full-time dev, they will never have as much context as whoever is pushing the changes, and diving into the code by themselves will rarely be the most productive approach. As a developer, you can easily mitigate the growing risk of potential regression by leaving the black box open so that any stakeholder can peek inside and understand the scope.
Leave notes about other systems that were changed with your commit. Leave a list of other user paths or features that might be affected — even with test cases you’ve already covered — to be sure that you are pushing code as fine as wine from captain Jean-Luc Picard’s winery. QA peeps will be thrilled to see those notes, not only because they mean you care about the quality of the product, but also because they can utilize those in their processes. They can decide to focus on those related, affected systems, do some quick exploratory sessions there, and catch regressions way faster than when living in the dark.
Your QA team wants to know what’s in the box, and you hold the key.
🦆 Extreme rubber ducking
QA engineers within your organization must know the product. They should utilize their end user perspective and business logic knowledge to make the development process as smooth as possible. You are part of that process, handling complex and difficult tasks, hoping to cover all loose ends, often under time pressure. When you have a hard time sorting out those loose ends, a QA engineer could be the helping hand you need.
Invite them for a pairing session, a QA-debugging call. Walk them through your code and explain how the code logic covers the business logic. Even without coding experience, their questions can open your eyes to different things you could have missed, cases that were not yet covered, behaviour that was implemented differently because of specs misalignment. It’s a rubber duck session on steroids and a win-win situation — you will get rapid feedback on your code, and QA will get a glimpse of the underlying backbone of the application.
✨ Truly Full Stack devs
Some developers like to be a “mobile dev” first, and a “backend dev” second. Some are Full Stack developers, keeping the web pretty and stable with sheer willpower and focused commits. But we think the best developers are a dev first and QA second, especially when it comes to the mindset.
While we are all responsible for the quality of the final product, on a personal level, we need to try our best and stay vigilant. When you see some shady behaviour while you are developing your change, it’s very easy to ignore it and assume that it’s not a big deal or an edge case. The sands of the ostrich algorithm are sweet, but often quick.
If you want to take pride in your work, you need to be proactive. If you see weird behaviour, fix it, or at least be vocal that something is off. Proactively test your code, try to find issues before they become problems later in the process. If you're building your features without putting significant effort into quality and testing, there's probably room for improvement. Infuse your dev process with some QA magic, and the whole team (and the end user!) will be grateful.
If this sounds interesting, and you want to learn more about our project (or how to help the planet!), head over to klima.com.
Written by Fred Porciúncula and Jedrzej Kaminski.