I’ve had the benefit of both doing Quality Assurance and Software Development for many years (usually not at the same time.) Interestingly enough, doing QA has made me a better developer and being a developer has made me better at writing comprehensive testplans. What astounds me about these two roles that work together on a nearly daily basis is they have a communication level that is lower than the US and Russia in the mid 80s.
I find it hard to believe but nobody really talks about how QA should work with developers and how developers should work with QA. I’ve worked on great teams where communication has been great and “the talk” really isn’t needed and I’ve worked on great teams where “the talk” needs to happen and QA/dev are ready to have a shoot out at high noon (Note: The talk is not the differentiator of a good or bad team)
The QA Dev relationship is just that, a relationship, a marriage, the good, the bad, the ugly. It will have its ups and downs but the one thing that remains key to any type of good relationship is having a good basic understanding of your role in the relationship and communication. If you picked up on the fact that I said it would be one thing but listed two then you are probably on the QA side of the relationship.
The following rules are not tied to any specific methodology and I don’t get technical for things like coverage etc. This post is bring to light the interaction (or lack of) between the two parties.
Basic Rules You Should Follow to Make Life Suck Less (BRYSFMLS)
Your basic job:
- QA: It is your job to break what the developer has created so the customer doesn’t have to do that. Do not trust developers. Your job is not to trust, it is to evaluate documentation, run tests that either pass or fail and properly report your findings.
- Dev: It is your job to turn over code that is as error free as possible (that means you actually testing the code before you hand it over). Your job is not to convince the tester that your way is the right way it is to evaluate the documentation and write code that satisfies the documentation/requirements in an efficient manner (both of your time and CPU/memory/database/etc).
Before you hand over your work:
- QA: It is your job to come up with a test plan/test cases that adequately cover the codebase. If you have questions, ask them early in the project.
- Dev: It is your job to make sure the docs are up to date (either you do it or have somebody else do it) before the tester gets it. QA cannot go off of what you tell them and they rarely have the understanding that you have of the project at that point. It is also your job to review test plan that QA creates, there will be hidden gotchas that QAs will never pick up from the docs.
When testing:
- QA: You should come up with test cases that are more than a literal translation of your documentation. Learn to read between the lines, find the realistic test cases that will happen in the wild but aren’t the exact requirement. Example: Calculate the age of a user using whole years. Your test cases should probably try someone who is born on a leap year and then calculate their birthday on their exact birthday of a non-leap year.
- Dev: Before you hand over your code make sure your code works properly and that it follows what is outlined in your technical documentation. If there is something that you think may cause issues for QA or that QA might miss, test it yourself (and also let QA know about it and why you think it might be an issue.)
When you find a problem:
- QA: It is your job to fully explain the problem as well as the steps you took to create it. If calculation is involved, show your work. By the time the sprint/project/whatever has ended up in your lap the developer has moved on to other sprints/projects/teams. Pretend the developer who will work on your ticket knows nothing about the program and might have been hired that morning from a third grade class.
- Dev: If a QA sends you an incorrect ticket, don’t just reply with “you’re wrong” or “DUH”. Educate your tester of why it is wrong (using facts, do not try to sway them). If you are unsure of which party is right, do not assume you are right because you are awesome. Raise the question to the lead/manager/client and get a real decision.
When working with tickets:
- QA: A developer can never have too much information. Include a writeup of the issue, what you were expecting, why you were expecting it (cite your sources) and if you can, images and videos help the developer too.
- Dev: Never reply with “fixed” or “wrong” or other useless one word phrases. A tester can never have too much information in the reply. Include a writeup of why the tester was right/wrong (cite your sources), what has changed and what you think could be affected by your changes. If what you are seeing doesn’t match up with the tester feel free to take screenshots and/or videos to help convey what you are experiencing.
When to automate testing:
- QA: If you can automate/record your testing for re-running later, do it. Make this available for the developers to re-run when they are developing.
- Dev: If you can automate/record your testing for re-running later, do it. Make this available for QA to re-run when they are testing.
When to be embarrassed:
- QA: When you fail to execute the test plan properly (it should be following steps by that point) or you let the developer convince you that a requirement is incorrect and you don’t verify it with a third party.
- Dev: When you turn over code that is completely broken. Your pre-QA testing should have caught these things. You are wasting QAs time. Also, when you convince QA that your code is correct and the docs are wrong without 1) going to a third party 2) updating the documentation (your job is to code, not to be God of All Logic in the World).
When not to be embarrassed:
- QA: When a bug is found after you have tested the code. QA is a third party that tests the software to catch bugs that developers might have missed. QA is not a fail proof method to remove all bugs from software.
- Dev: When QA finds a bug in your software. That is their job, don’t get huffy, evaluate the bug, fix it and properly document the changes.
When to talk to your significant other:
- Both: When you keep passing back and forth tickets but nothing is getting done.
When to get pissed off/annoyed/angry:
- Both: Never, see the rules above to identify which rule(s) you are not following. Remember, you both have the same goal, put out a good product within a timely manor.