Six Developer Phrases That QA Engineers Love to Hate
We have to verify that our code works, that's just a fact of life. Having spent my entire life on the developer side of the room I must say (if I'm going to be honest) that I have committed each and every one of these sins.
Join the DZone community and get the full member experience.
Join For FreeTalented developers write code, and create beautiful features and robust infrastructure. But issues can still arise due to an inability to see the full scope of the product, lack of attention, or just natural human mistakes... which we all make.
That is where we come in—as QA engineers, we test features before they are released to keep the product up to the highest standards.
This basically means it is our job to ruin what you created. Just kidding—we just want to make sure the product is of the best quality. Yes, we know that developers don’t like their code being tested. But trust us—we all have the same goal. When we raise issues, it is because they need to be fixed.
In the spirit of working together, here are six sentences developers say to QA engineers, which I’m sure will sound familiar:
1. “But it works on my machine.”
Some of the bugs we find as QA engineers are invisible to developers. This can happen when the issue is not reproduced on their environment, but does reproduce on the production environment—maybe due to scale or different configurations. This is a frustrating one because everyone is pulling their weight but things still aren’t working.
The solution? It’s not you, it’s the environment. :-) Come and investigate the problem on production. That’s what the client uses, so that’s what matters.
2. “I checked the fix and it is fine now. We can release now.”
After fixing the bug that we passed on to them, sometimes developers think the change or code can immediately be released to production. But, each and every fix needs to go through QA. Yes, even after you fixed them. Yes, even if you’re 100% sure it’s fine now. Yes, even hotfixes.
Why? Because changes might affect other parts of the software developers can’t see, but QA engineers definitely can.
Really, we’re not trying to drive you crazy. We just want to make sure the system is up and running 110%. We will release as soon as we can, freeing you for your next project.
3. “Are you sure you are using it right?”
Developers, I enjoy working with you, but this is an annoying one. Yes, I’m sure I’m using it right. Sometimes it’s hard to believe a new feature isn’t working as expected. But that does happen, and it’s not because QA engineers aren’t using it properly. Let’s work together to make sure the customer gets the best product.
4. “It’s not a bug/That wasn’t part of the product specs.”
Hurray! A new feature is done. Developers are super enthusiastic, but QA makes them halt in their heels—something is wrong. A bug.
‘No, wait,’ the developers say. ‘It’s not a bug - this is how the feature should act,’ or ‘this wasn’t part of the product specs.’
The thing is, that as QA engineers we see the whole system, including all of its sides and features. Something that might seem fine from the developer’s side, but might not seem fine at all from the user’s side.
This is a tough one that needs an outsider to resolve. Good thing we have a product manager who decides what to do (and sometimes acts as our babysitter). Let the PM figure it out—in the meantime, we can get a coffee together.
5. “Why did you wait so long to find this issue?”
I completely understand how frustrating it is when you have to work in the evenings or over the weekends to fix a bug we found, before a tight deadline. But, we’re not doing it on purpose. Our work as QA engineers is conducted according to a systematic logic. We definitely try to do our best not to pile up work for you on your free time. But it might happen sometimes… (and believe me, it makes me feel bad).
6. “Are you sure you are testing the newest code/right version?”
Similar to questioning if we used the new feature correctly, we often get asked if we used the newest code or the right version to test the work. Before we start testing a fix or a feature, we make sure that the commit is in the current version we are about to test. Unfortunately, sometimes things just don’t work as expected.
* * *
Developers, admit it—deep down inside you know we are right. But it doesn't matter I still love you guys. Are you still here?! Go fix my bugs! And don't forget to update me when you finish!
Want to learn more about Load Testing Like a Pro? Check out our free Webinar.
Published at DZone with permission of Michal Borenstein, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments