best practise when creating scripts."expected results field"
I work for a company that has a product (OnDemand Personal Navigator) which is used to produce training content against any app.(both documentation and simulations) in a single process.One of the many cool features is the ability to produce manual test scripts that are compatible with Mercury QC.This is from the one single process.
Anyway,this feature is relatively new and I don’t have extensive background in the testing sector so hope to gain some knowledge for your guys (the experts ;-) ).
Can anyone provide me with examples of a typical “test script” that you would produce for a Bussiness process? We create QC scripts that have 3 columns, ”Step Name”, “Description” and “Expected Result”. We populate the first 2 columns from our application and leave the third “Expected Results” blank. Testers can populate the “expected results” field either before or after importing into Mercury.
Just for my own curiosity, I would like to see the type of text in the “expected result” column. Is it brief single statements, example “Opens new windows” or would you typically elaborate more in a “Expected result” field
Re: best practise when creating scripts."expected results field"
Several years ago it was expected that testers could walk in off the street and start testing with virtually no experience in testing or the Application under test. This was exploited as a reason to write test cases down to the finest detail with all possible solutions included. Today, for the most part, the theory is not adhered to as much as it used to be. Testers are more skilled in both testing strategies and the applications they are testing. Therefore, without knowing your specific situation it is difficult to answer the question accurately. That being said, I personally opt for the least description of expected results to get the job done. I make them short and to the point, much the same as your suggestion "Opens new windows", or application closes, or xxx value appears in the answer field. Any more might possibly serve as a point of confusion to the tester.