How to Make the QA and the Developers Work Happily Ever After

However, usually they simply come from lack of knowledge.

And I think it is our responsibility to draw the world close to the glorious role of the Quality Assurance Specialist and some aspects of our work. Let’s allow people to get to know us better. The best starting point is presenting our everyday job: working alongside the software developers.

At this moment, there is probably a silent voice in the back of you head saying: “Wait a second… A QA is going to talk about the QA life. Of course it will be glorified, perfect, and the QAs will be heroes in all the projects.” Well... I agree – it is not going to be objective. However, in order to guard the quality of this article (see what I did here? :) ), I also asked some Netguru developers and some other QAs about their opinion to show you that in this subjectivity you can find a lot of the reality.

Know thy project better than a back of your hand

Many QAs (I would even risk stating that all of us) have one great superpower: we know our projects best. I would say it is not surprising; after all, we click through the application several times a day. We have tried some features in various combinations so many times that we could recite the flow in our sleep. And let’s be honest: we are not at all shy about having this superpower so the whole team knows about it. The developers are not afraid of using it for the advantage of the project. I am not able to count how many times for the last several months I have heard such questions as “How do I use this feature exactly?”, “Does this feature is used anywhere else in the app?”, “How should I do it so it would be consistent with the rest of the app?” The bigger the app is, the most valuable our superpower becomes. Imagine a huge monolith app with three or four developers. The developers are not able to know all the features developed by other programers, they are not able to comprehend all the minute connections between some part of the app for the very simple reason: it is not their job! However, they realize that and in such moments they use our knowledge and expertise and they actually expect us to have it.

Guardians of the quality

To resolve the doubts: yes,. I am a Marvel fan and I think that the QAs may have some things in common with the Earth’s Mightiest Heroes. We are an additional barricade protecting the production environment from dangerous adversaries. Here, I need to emphasize one thing: the developers also care about quality! And we expect them to do so. For that reason they write unit tests, they do code reviews (which is an inseparable part of the development flow here in Netguru), they consult the features with us while working on them. However, mistakes happen or the developer do not think about all edge-cases, unhappy paths, and consistency issues. Here we come, the QAs who actually think about all these things. Yes, we expect them to follow the aforementioned ways of maintaining quality but at the same time, they can sleep well knowing we are there to double check everything.

Indeed, sometimes we do not agree on everything. We don’t have to. However (and maybe this is the biggest mystery which is going to be revealed today), we need to remember that…

A developer and a QA are (best) friends!

If you have ever heard that the QA’s sworn duty is to make the developer’s life more difficult, you have heard wrong! I think it may be one of the biggest misconception of the IT industry. The quotations above can give some hints that the QAs really like to work with developers and that we want to build the positive relationship. And what it looks like from the developers’ perspective?

As it has been already mentioned, the developers often perceive the QA as a silent partner in coding. They seek our knowledge about the project and they are pretty much sure that they are going to get that help when needed. On that account, the QA’s expertise is sometimes indispensable for the developers to continue they work in an efficient manner. They somehow expect from us to respond swiftly and directly. Of course, sometimes it is not possible to respond immediately but it’s good to give the developer at least a hint and the approximate time when we will be able to answer fully.

As you could see in Maciej’s opinion in the previous section, we are expected to be sometimes relentless when it comes to quality. The QA does not reject tickets for the sake of rejecting tickets and, most of the time, we have good reasons for pointing out some flaws and we are not afraid of sharing it. Here in Netguru, our developers know that simple yet powerful truth and they trust us when it comes to quality. Of course, we can be wrong and sometimes we need to be ready to admit to making a mistake. As in every friendship, the basis for this healthy relationship is communication. Even if we disagree with each other, or even if we reject the ticket – we do it in a polite and respectful way. We do not reject the developer(!), we just point out to some defects in their code.

QA, the liaison

There is another area in which some developers really appreciate our help. Sometimes, especially in long-lasting monolith projects, there are some unknowns and challenges when it comes to the final shape of the feature and we are the first line of contact for the programers. However, it happens quite often that even we are not sure or we do not have the final decision power, and we need to contact the client. Yeah, the developer could contact them by themselves but often we join those calls and conversations to support them and two good things come from that. The first one is simple: the developers know that their QA has their backs! We can explain something less technically and more user-friendly, we can present all the edge-cases and unforeseen consequences which allow the developer to focus on thinking about the code behind that. The second good thing is beneficial for us, the QAs: the client can see the value of our work. After all, the developer delivers the ticket and sometimes the client does not realize how much the QA has helped with that. When we present our own ideas and propositions, the client can see our engagement and value we bring to the project. Had it not been for that, the client could have missed our contribution to the project (but then they could just read this blogpost :) )

Give me your helping hand, my friend

Some could ask what we, the QAs, have from this relationship. Quite a lot, actually! The QAs are technical members of the team but it does not change the fact we may never fully understand all the intricacies of the code behind the app we know so well. Of course, we do know the basic terms, it happens that the QA has some wide knowledge about programming, but the developers are the people who know the code the best! It happens quite often that we consult the programers about some logic in the app and they patiently explain us how something should work according to the code and how it is written so we could confront the code’s logic with our expectations and vision of the feature. Another situation is when we have some bugs, errors, Rollbars and we are not entirely sure what is causing them, the programers are always very eager to look into the code or into the logs and explain us what may cause it so we could investigate further (and write a nice ticket, but we will come to that topic later). Moreover, when you are a bit less experienced QA, they may give you some tips how to test some backend issues. I remember my first testing in the Rails console; I was given a specific commend I should run (`WonderfulDeveloper::HelpfulQA.count`) and some tips what should be the result. If I had had to come up with that myself, I would have to spend much more time for compiling that commend. However, somebody could ask “Wait, they gave you a method and expected results, and you call using them testing?”. Believe me, my friends, a simple method like that in hands of the inquisitive QA can be a powerful bug detector when we combine it with our knowledge of the app. And in time, we learn how to modify those methods, how to write them but every time we have doubts or do not know something, our wonderful programming friends are always willing to help us.

In the beginning was the ticket

I believe this is one of the most crucial parts of our cooperation. No matter how many people I asked about QA/developer cooperations, the issue of the tickets were there. It works both ways: the QAs expect that developers will deliver comprehensive tickets with all the necessary details, and the developers count on us that would not have to guess why the ticket was rejected or why the bug appeared in their “To do” column.

Let’s start with the beginning so the ticket creation. Depending on the project, it may look differently, but usually the tickets are created by a Product Owner. Then it goes to the developer. And they perform wonders and miracles converting words from the ticket’s description into the code which then changes into the beautiful app we test. It is a complicated process: sometimes some things not mentioned in the ticket are added, sometimes (after consultation with the PO) are removed, sometimes the QA advises implementing a change or an improvement. When it finally comes to the QA column, we expect that all these changes and adjustment will be well documented in the ticket (even if the QAs themselves proposed the fixes as we are not able to remember everything, especially with huge features). If they aren’t noted down, we can reject the ticket (which could seem unreasonable for the developer since everything was done as should) or we could contact the developer, discuss the discrepancies and explain some issues. No, we don’t mind talking to the developers but it consumes our time and force us to switch context which is not could for the overall focus. The better the description of the ticket, the less we need to interrupt each other in our work. The second important things are Tips for QA. Remember my first console testing? Yeah, the developer’s tips were described in the ticket. Sometimes the ticket is obvious for us, but very often we need some commentary from the developer. Where should we look for the implemented solution in the application? If the feature is not finished (very rarely a whole feature is implemented within one ticket), then what we should expect to see in the application? What has been implemented and what waits for some decisions or next tickets? Is this feature already accessible from the frontend or should I test the backend? How this API endpoint works or how has it been modified? The more the developer include in the tickets, the less questions we would need to ask them, the less energy and focus we take from them, and the more independent we are as the testers.

However, sometimes there comes the moment. A drama. A tragedy. A catastrophe… I am joking of course, sometimes we just need to reject the ticket. Or report a bug. That’s life and normal part of the development process. There is one “but” – we should never reject the ticket without explaining a reason. And I am not talking about a subjective opinion “I don’t like it”, but about an intricate explanations with snapshots or short clips, pointing out to what does not work and how it should behave, and, most of all, how to reproduce the issue. It is of vital importance that we provide developers with all the details necessary to reproduce and fix the issue. Without that it’s the same as with incomplete tickets delivered to testing – the developer need to interrupt our work and break our focus to understand the issue. This could be completely avoidable if we described the prob… the challenge in the appropriate way. We could prevent the programer from being frustrated and make them happier in general. They would start fixing it right away instead of wasting their time and energy for attempts to understand the cause of the problem.

In the end, we go out

The feature is done, the client is satisfied and it took a lot of effort from both the QA and the developer to achieve this successful end. We can give each other high fives and go out for a cold beer. Or to play some volleyball. Or the board games. Or go shoot each other with laser tags (do you have the same picture in the mind of the developer with a gun, advancing on their QA, and screaming “Freedom for bugs!”?). We can chill out before we jump into this fruitful collaboration on the next morning.

Photo by Chris Liverani on Unsplash