sachin

• Mar 19th, 2005

 

you can derive your expected results after detailed analysis of the urs and the srs documents.

Brian Parry

• Mar 26th, 2005

 

Expected results is another way of asking "How do you know if a bug is a bug?". There are several ways to determine this depending upon what info is available.  
 
1: You can check the spec or requirements. 
2: You can check against the previous version of the product. 
3: You can check against competing products. 
4: You can talk to the programmer to see how he/she got the idea something should work a certain way. 
5: Common sense. 
6: Ease of usage. 

Dyeana

• Apr 18th, 2005

 

Your answer is correct, very correct practically. However in the interview if we answer all 6 reasons, the interviewers dont get satisfied. They want to hear "only from requirements."

Ravi

• Jun 1st, 2005

 

It?s the responsibility of the Tester, who is involved in the testing the application. When we go through the requirements documents and write test cases for the functionality of the application one should be clear about what are the expected results once the test case is run successfully. The tester should prepare different test cases both positive and negative inputs and based on the requirements documents, he will come to the conclusion, what should be the result for specific inputs. If you have any doubt about the expected result, make sure to clarify in the status meetings or in the walkthroughs.  
 

choudary

• Jul 8th, 2005

 

we get expected results from the SRS and Functional Design Documents. 
 
if there is no clear documentation we prepared expected results from the  
1. Previous similar products. 
2. by communicating with the developers 
3. by common sense.

jigna

• Dec 22nd, 2012

 

From requirement document