How To Train Your Dev (from a QA perspective)

Boryana Yaneva
Apr 11, 2018 · 4 min read
Elkling taming the Dev Dragon, Dapfne

If you ask a random project manager about their team, they will tell you that Quality Assurance and Developers work together in a symbiosis to achieve the best possible result. We put our differences aside in the name of the greater good, which is a bug-free, beautiful, sparkling clean product. However If you ask QAs they will tell you that Devs are snotty machines that are so far gone in the Matrix that they have reached rationality on a level that should not be reached. Programmers are the eternal evil who roam in the night and close our bugs as ‘Cannot Reproduce’ even though we have just shown them how to trace them back step by step!

On the other side, if you ask the Devs they will mumble out that QAs are doofuses whose sole purpose in life is to destroy their precious, pretty code. Programmers always whine that we are taking extreme measures just to crap all over their hard work. They will claim that we are imagining impossible scenarios to mess with their logic and are experiencing almost orgasmic pleasure when we discover a crash (which when I think about it might have happened once or twice).

With so much rivalry between these two work forces, how do you achieve balance and harmony and more importantly how the heck do you train your Dev to be nice and cuddly and reduce to minimum the fire spitting in your direction? I will tell you how, just keep reading. During my not-so-long 5 year career as a QA I have experienced all types of programmers and I bravely tamed most of them.

Check out my 5 rules of how to tame your dragon Dev!

  1. Remember to start taming them young. As a rule, developers have the mind set that they know everything and they are the top of the development food-chain. I had cases of senior developers throwing a device at me and arrogantly telling me “Good luck finding anything”. Resist the urge to throw the device back to their smug face but instead…see rule number 2.
  2. Test as there is a piece of delicious cheesecake for every major bug you find. Be curious, be stubborn and be very, very persistent. Every feature has bugs! It is up to you to find them and show that passive aggressive douche-nugget that he needs you. Showing the Devs that they and their code have flaws and you are very aware of them will give you the upper hand and reduce the arrogance!
  3. Do not get insanely focused on minor issues! If all you contribute to the project is spill-outs, overlaps, missing pixels and tiny UI improvements, then perhaps switch profession to being an editor or something. As much as I like going to a Dev and giggling about his spelling mistakes, I also really want to destroy their stuff completely. I want to show them that I am not only a Shepard of missing commas and a Chaser of misalignment. I am also the Hulk who smashes and CRASHes (in a friendly manner) their puny code. If you bother them with minors all the time, they will just get frustrated with you and feel like you’re wasting their potential. Challenge them by finding complicated and cool bugs. Show them that you have thought of a scenario which they have missed. Prove yourself valuable and they will trust you with their precious Git commits.
  4. Establish authority over young Devs. As I said earlier, young Devs are lovely to work with. They are inexperienced and a bit uncertain about their skills. I have often had situations when I send them bugs and then they ask ME how I want the issues fixed? I was a bit stressed at first, because I thought that this is the job for a solutions architect or a project manager but then I started making decisions. Trust yourself and go with your gut. By now you have seen a lot of software and even if you don’t realize it, you will be very good with explaining what the Expected Behaviour should be like.. After all you have the renderings, the acceptance criteria, you have written the test cases, therefore you are perfectly prepared to tell them how you want the things to look like. Of course you should also know when the questions are above your knowledge and consult with other people if you are in doubt.
  5. Make yourself needed and trustworthy! The biggest compliment for me is when a developer refuses to release a feature without me checking it first. You should establish a trust that you have their backs. Yes, maybe you do make a happy savage howl when you find a crash but at the same time, you are their safety net in case they have made a mistake or forgot about a user scenario. You achieve this by being extremely curious, very inventive and creative with your testing. I have found out that programmers are usually very logical creatures and they follow strict rules. You should be their alogical alter — ego. Think in a way that they would not think and be able to come up with good negative scenarios.

Hope all of this was useful and you achieve mutual respect and understanding. Once you tame and make Devs trust you, they can be lovely and loyal friends and colleagues that are willing to help you with anything! And a little bonus tip, if all of my advices fail, take them out for beer and some pizza. If you can’t beat them, befriend them!

Norigin Media Tech Blog

The wonderful blog of NoriginMedia Engineers

Boryana Yaneva

Written by

QA by day; Comic Artist, Journalist and Draenei Hunter by night.

Norigin Media Tech Blog

The wonderful blog of NoriginMedia Engineers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade