As developers, you are probably familiar with this scenario: you went over a code review with another developer (which you do, right?), pushed the latest fixes, ran a couple of tests by yourself, and with a big smile upon your face, you sent a message to the QA guy, Joe (a generic name for a person from the QA department): “You can start testing.”
Then, you get off the cozy chair and make yourself an excellent coffee (or tea). As you sipped your coffee, Joe slacked you: “I found a couple of bugs, here’s the list.” The most fantastic coffee turns bitter, and the sense of a flawless victory quickly fades away.
Thus begins the never-ending ping pong between you and Joe. The session can be long, but it crushes your happiness with endless thoughts such as “I’ve tested it. How the hell didn’t find this edge case.”
I can say, until my previous position, this was my relationship with Joe. But in that organization, something changed, and suddenly I was not afraid of Joe. I’ll show you what helped to remove the fear of Joe’s feedback, and you might be able to apply it to your organization.
First, what was that company?
Before Testim, I worked in a med-tech company that developed an algorithm for managing insulin treatment plans for people with diabetes. In the med-teach field, you must test any piece of code (or else, sorry for my French, the shit can hit the fan). Unlike other companies that prioritized which feature needs heavy testing or just a simple unit test, you cannot skip it in the med-teach field.
It comes from the simple reason that people’s lives are at stake, and if we deployed a piece of software that did not perform properly, all hell breaks loose.
Step 0 – We are all part of the process
Our story began when the VP of R&D decided not to have a classic QA team write the tests and execute them before a release. Instead, the developer responsible for the feature will write the software test plan (STP) with Joe. This change in the paradigm was helpful for two reasons:
- Just as we review code, we also review how the logic interacts with other software parts. As developers, we often look from a very narrow point of view on our features. Joe, which is a certified QA, knows how to test better and what could go wrong.
- When starting to test the edge cases we need to talk with the other stakeholders of the feature. The product team can help us understand better how the feature should act when we find edge cases that weren’t specified in the software design document (SDD).
Step 1 – What’s QA’s big idea?
In the past, I thought that Joe’s job was to take the feature and try to break it. But Joe explained it to me from a different perspective: the QA job is to see how the change in the code matches the SDD.
When I understood that approach, I started to look at testing in another light. No more shallow testing but rather in-depth testing and understanding that more test cases (TCs) are a good thing.
Step 2 – Don’t rely on 3rd party vendors
Sure, today we have a lot ready to use packages like Express, Django, Laravel, or even a CMS like WordPress to get the work done but we must understand that we need to test them as well.
Let’s say we have a news site that has a section for registered users. As a developer, you’d know that using the permission layer of WordPress (or Django middleware) would solve it – it’s in the documentation and you’ve done it to the previous client.
You cannot take it for granted and you must add a test for it – perhaps a developer changed the code? Maybe a bug was introduced in the new version? As I mentioned earlier, over-testing, in a good manner, is not harmful.
Step 3 – Platform infrastructure is crucial
After we wrote our huge STP we needed to implement it. If we had to do this manually, many of us would rather jump into a hot tub with a plugged-in toaster. Fortunately, this is 2021 and for every language/framework that respects itself, there’s a test execution tool.
Sure, we would need to start writing the functions that would come in handy – login to the site (in a REST world we would create a token), send requests as that user, create users with various roles, etc. When we have a toolbox with a wide variety of utility functions to execute anything we need, we would not be afraid to expand our STP and cover a broader set of edge cases.
But don’t think you’re invincible – automation is not a magic pill. Sure, we can cover a lot with our amazing infrastructure but we would still need to test the site manually – play around with a couple of buttons. Trust me, you can catch more edge case bugs than you can imagine.
Step 4 – Consider it a code review
In the beginning, it was hard. I needed to remove my developer hat, put on my QA hat and assume a new state of mind. But just like we’re learning from a code review and understanding what should get more attention you’ll get feedback from an STP review that will help you improve your code.
Conclusion
Usually, when we look at the developers and QA teams we think of them as separate entities, like a bird and a crocodile. But the Nile crocodile and Egyptian plover have learned to help each other—providing a snack for the bird and healthy teeth for the crocodile.
This post showed how two separate entities in an organization, who sometimes annoy each other, can work together to accomplish a lot more: writing better tests, earlier.
