R&D Rules

[Kycb-Kycb]

QA rules:
1. When opening an incident use very simple language. “Nothing works” usually gives a developer enough information to figure out what’s wrong.
2. When a problem appears, restart everything and then call a developer. (Note. You can call a developer first, but then you might not have enough time to restart everything before someone comes down)
3. If something goes wrong, don’t check the configuration. Call a developer he will check it for you.
4. Never turn logging on. This will make it too easy for developer to investigate a problem. Developers like challenges.
5. In case you accidentally left logging on, make sure you don’t attach any logs to an incident. A developer can get all the necessary logs without your help.
6. Always open multiple incidents if possible. (Explanation. If an application doesn’t start you can open at least 3 incidents: App doesn’t start on Win98, App doesn’t start on Win2k, App doesn’t start on WinXP)
7. Every day move one of your incidents back to Development with “not fixed” comment. Don’t put any additional information.
8. Incidents can have only two priorities –High or Urgent. On the second thought… Just Urgent. All incidents are important, right?
9. Screen captures of the error box with OK and Cancel buttons are very helpful for a developer. Developers can debug application from the Paint.
10. Developers should actually do all testing.

Developer rules:
1. It's not reproducible.
2. Do not test your code before checking it in. Trying to compile is optional.
3. When an incident is fixed just change a status to QA. QA will have no problems figuring out what is fixed, in which build and how to test it.
4. When called by QA to investigate problem, agree to come to QA lab right away and then forget about this for a couple of hours.
5. Adding 10 pages of code, logs or e-mail exchange to an incident usually helps QA to test your fix.
6. If you don’t understand a problem description just move the incident to QA. They will hate it if you will try to call and ask for details.
7. Every day move one of your incidents to QA with “please reproduce” comment.
8. If problem is only reproducible on one machine try to reformat it when nobody is watching.
9. When marking incidents as a duplicate try to mark an incident as a duplicate of another duplicate incident. Try to create longer chains. This will make QA life a little bit more entertaining.
10. QA should actually do all testing. And yes, that includes a unit testing.