“Together Everyone Achieves More”

• It is very difficult to test a complex RIA thoroughly. It is even more difficult if it is yours. Sending the system to the users, and asking them to focus on specific areas is an excellent way to find problems you missed. Remaining focused on delivering quality software and doing a good job makes it easier to acknowledge oversights, errors, bugs, and mistakes - and fix them.
• Don’t send harsh comments or accusations. If something is wrong, check very carefully to see what is happening. Report only the facts, for example: ‘this is in the log’, ‘this sequence of steps causes an error’. Read carefully. Take your time.
• Don’t underestimate the value of the data in the system. Take great care to protect it at all times from corruption. Test the system on a different server or using a different database prior to launch.
• Respect the value of other people’s time. Don’t ask them to test anything that you aren’t very confident in. Request their help with several, specific issues, to reduce communication overhead. Offer to meet them in person if it is difficult to resolve through email.
• Use version control. Be sure that if you changed the file last, you didn’t overwrite anyone else’s changes.
• Thank those that test the code and take the time to respond, even if they find problems.
• Even if there isn’t a problem, or it is a simple piece of code, it is good to allow others to review it and suggest changes. Whenever possible, make the changes.
• Avoid scope creep by adhering to written and recorded content. email and verbal changes that have been agreed upon should be entered into a defect management system. This ensures the details aren’t forgotten and also serves to limit the scope of changes when the work is done. Use the ids from the defect system to be sure everyone knows which issue is being addressed.
• Use neutral colors and be courteous in email replies. Many people perceive red text and UPPERCASE as harsh, even if the content isn’t. Blue, green, purple are better choices.
• Remember that it isn’t ‘your’ code, it belongs the the company or the client, whoever is paying your salary. The objective of the project isn’t to produce software, it is to provide a solution to a need or requirement. Strive to find the best solution.
• Give credit for good ideas from others.
• Test plans are excellent resources. They don’t need a specific template. Any way that you can comfortably explain what to do, and what should happen is find.