Again, I want to share my experience with you on an interesting topic in software testing. It is a hot topic in any organization if it is a Tester or QA then you can guess it – nothing else is – Testers with Developers.
Testers? Troublemakers
It’s funny that somehow some devs always consider testers to be troublesome =))
In fact, it is not their fault, no one wants to hear that they find their fault in their own product. But that’s what we (tester) are doing, of course, the intention is just to bring the best product quality to our customers. On a regular basis, there is hatred that happens to people in these two roles (dev vs tester).
Why is that?
As the number of bugs increases or bugs are serious and it makes it difficult for devs to solve them, it makes them feel frustrated no matter how good they are. There are many times when a bug reports a dev, half jokingly, it is not a bug.
So, how to create a good relationship and understand each other between the Tester and Developer here?
My experience is that teamwork and friendship are the best solutions.
If you can become a good friend of a dev then you can challenge him (Dev) and make sure that person will take it positively and make it better. It will be the responsibility of both to ensure that the output is the best. Meanwhile, developers should ensure that no bugs will be born from what they have created.
Just kidding, if there’s any software that is not buggy, Dev will make a bug-free product, Tester will worry too =))
Testers should also make sure that if there are bugs then these bugs should be identified, handled at the right time and scope. When you are a QA and are working with a team for a long time, the relationship between you and the dev will become closer.
As a team, you can work together to find defects first, which is always appreciated. Not only that, sitting together to discuss designs and solutions can make developers aware of different issues and areas to improve product quality. thus taking the quality mindset a step further.
As a tester, you can find flaws but it would be nice if you share with the dev some tactics to test the application. Perhaps this will help developers test better before delivering products. But this only works if everyone has enough cooperation to have an overview of the final goal, such as delivering quality products.
Let’s share your thoughts
What do you think is the best way to make the relationship of dev and QA smooth?
Here are some of my thoughts on this:
# 1) Share your strategy with the dev. Don’t keep thoughts in mind and think that you mark it as an issue at a later stage.
Like you might find it problematic, but don’t share it with the dev, but then go away later to log the bug. Often in the case of an unclear or suspicious issue I often ask the dev to confirm whether it’s a spec or not and then log the bug later. If not, then avoid the log to avoid spam list bug.
# 2) Try to build a close relationship with devs so they can share anything with you freely.
# 3) Report issues positively, don’t hurt the feelings of others.
This is obvious, the same is a bug but the way to say so that the dev does not feel hurt, it is probably much easier to receive and fix it =))
6 ways QA can work with Dev better
1. Focus on quality rather than testing
Testing is just a means to an end. Often, QAs run the tests as if they were expected to fill up some quotas to complete the tests. We must remember that the actual goal is to improve the quality of the product.
Make sure you understand what is important to the customer and test it out. Don’t just look at user needs definitions. Try to think like a user and make sure the app makes sense from their perspective.
Always think about your users and don’t test just to say that you performed the test. Users don’t care how many times you test your app – what they care about is product quality and whether it meets their needs or not.
2. Sharing responsibilities
Very simple: Everyone should be responsible for the quality of the product. In an Agile group, there will be no “we” and “them” anymore. Devs are responsible for their code and make sure they write the relevant unit tests. QA should check the whole system.
Yes, QA are gatekeepers, but when everyone belongs to the same Agile group, everyone should be equally responsible for the quality of the product.
3. Choose your battles
As a gatekeeper, you can’t fight every single flaw. You have to understand what battle is worth fighting and where you can let go. Otherwise, it will take a long time for people to fix things that aren’t important.
Here’s a tip: Define your own “Red line” of things that you simply won’t compromise on and just focus on.
Many teams set up a “defect committee”, pre-defining bugs before each sprint or version is released. This helps focus everyone’s efforts.
4. Constructive for defects
The truth is: no matter how much you test, there’s no guarantee that the software will be flawed. Some are always lacking even when using rigorous testing procedures and then they are often detected by external users.
=> This is for sure the occasional bug that the Customer returns but the heart beats and doesn’t ask thousands of questions about why it might be lacking.
The key here is to keep calm, learn a lot from those shortcomings and improve the quality in the next releases.
Dev likes to ask QA questions like, “How did this get past you?” Haven’t you tested that? ”The fact is that the software becomes complex and you can’t always test every single script and configuration. We conduct risk-based testing and test the user flows that we find to be most important and popular based on the time we have.
In some cases we should consult with the PM manager (product manager), the parties involved in the trade (sales, pre-sales, etc.) or even the customer itself. If something goes through our site, we do an interview to find out what happened and why we missed it, and, we create an automated checklist. for the lack of that error.
5. Create visibility into your activities
Vision enhances cooperation and reliability in any team, and Agile teams are no exception. You should not assume that developers or any other stakeholders know what you are doing, how to test it or what your standards are. Let’s dev review what you intend to test offline.
When you share your work with devs, they may start to pay attention to what’s important. There are days of bug hunting, along with additional stakeholders from PM to support teams and architects, which not only broadens the scope of effective testing, but also has more eyes to review the product carefully. Taking out important lessons learned from customers, it will be more beneficial for you as a representative for the end users.
6. Don’t accuse devs or users
I often hear QA threaten that they won’t accept a feature because it’s low quality. In my opinion, this is really the worst thing you can do as a Tester. Think of the result here: With your disapproval of a feature, you alienate the dev and, worse, your users won’t get a chance to use it either.
There are many things you can do in the case of low quality: There is a group selected to improve quality; only release the first part of a feature (the part where the quality is good enough); and make a list to keep going. A common tactic is to highlight a feature like “alpha”, “beta”, or “early access” to set expectations.
This means that users will be able to start using the new feature, knowing that this is probably a half baked pies. I think this is a win-win situation: Users get new features, then we get feedback from them, and our so-called “quality conscience” remains. intact.
In short, even if there is a partial release, it still ensures a good quality rather than releasing the entire product, but the error is not much to do anything ^ _ ^
Conclude
Originally, the relationship between Dev and QA has always been difficult to reconcile. But think about the ultimate goal of the entire team is product quality . Therefore, do not let the whole emotions affect the progress and quality of the product.
The article was translated from the link:
https://www.softwaretestinghelp.com/how-to-make-developer-and-qa-relationship-healthy/
https://techbeacon.com/app-dev-testing/6-ways-qa-can-work-better-developers