Re: Advice on software testing?

["Dana Worley (MVP/JB)" <dana -at- campbellsci -dot- com>]

To add what has been said:

When you get a new build with bug fixes or changes, sit down and talk 
with the developer on the areas of risk (what changed? where in the 
code? what other areas in the software could be potentially affected by 
this change). This will help you focus your testing.

When documenting bugs, make sure to provide complete steps on how to 
reproduce the problem. Saying, "It's broke" is not helpful :) Detail the 
behavior, write down or get screen shots of complete error messages. If 
its a bug that is related to usability, provide information on what you 
expected to happen, and how the software's operation differed from your 
expectations.

Working from test cases is great -- in a perfect world. However, if you 
are being asked to step in and do testing, it may be that there ARE no 
formal test cases or a QA department to turn to. "Demanding" that you 
have test cases before you start may be unrealistic. FWIW, I have been 
with the same company for 14 years, working as part tech writer, part 
tester, part customer support... It has only been since I began managing 
the group that we set up more formal test procedures.

If you have the opportunity, get training. I found training from SQA 
quite valuable (we actually brought it in-house for my group and our s/w 
developers).

Defend your position on a bug, but also know when to back off 
(especially when you get near release). Don't be offended if your bugs 
are "next versioned". Think about risk -- how likely is a customer to 
run into this issue? What are the ramifications? Is there a work around? 
Is it catastrophic? At some point, the software needs to be locked down 
(or it will never ship) and all bugs except those that are absolutely 
show stoppers will need to be moved to a future release. Understand this 
and don't take it personally.

Dana W.

On 12:59 PM, Cardimon, Craig wrote: