Actually the actual result is not match with Expected then we have to lock it as a BUG. Before that it is best to do

--> Consult the Developer and pls tell about it and Clarify it as a bug or not

--> Decide what type of bug it is

--> Decide the Severity Priority etc

If the actual result doesn't match with expected result at this situation the test case must be verified first whether it is a right expected value becoz there are some times where there is a mismatch between the SRS & Test case becoz of unrealistic change after preparation of SRS (Changes made at the time of Developing)

As the above condition is positive we assign the priority & Severity with an track of bug to concern authority.

Sanjeev

As a first step we should clarify whether the result is a bug or Change requested by customer b z some times changes may not be communicated to QA in time. If that is not a change request then try to reproduce the same result then lock it as Defect with appropriate priority and severity.

1)Try to reproduce the same with valid testdata.

talk to the devoloper.

LOG it as per the severity.

Rest is to the QM/CCB of the site.

They will analyze the bug and keep you for assessment.

again step1

write your comments

Retest NOT OK

in the sub-sequent build the devoloper will fix this.

Retest again

make sure that environment is prepared as per the testcase/testplan.

cool man..

If the expected result is not matching with actual result then it is Defect. Before raising a defect ensure that you have used valid test data to test the script if possible cross check in the FS or the requirement doc. (it is not necessary to cross check in requirement doc or FS as the script/test case is derived from these docs).

Raise the defect with appropriate priority/severity.

Rohan

not match we can raise a bug and give to seviarity as well as priarity and put defect tracking .

Thanks

Srinivasulu.chittoor.

Hello everyone..

I am a new visitor to this site.. And I am sure there would be plenty of new visitors to this forum. Just a few suggestions to some of the posters. Everybody's responses and thoughts are very much appreciated.

1) It would be more helpful for QA rookies and other visitors if proper spelling and grammar are applied to your responses.

2) As much as everyone takes pride in what they do as most of you are experts and senior professionals documentation is a key aspect in the IT business. I hope grammatical application and spellings similar to your reponses are not enforced in the actual technical docs that you prepare..

3) At least grammar goofs can be read (pronounced as RED) between the lines but spellings are unforgivable. Some of you may want to do a spell check in word or consult a dictionary before actually using the word.

Some of the words used don't even have a latin-greek root..

Just my ten cents.

V

Hi

If your actual behaviour of the application is something which is different from what is expected follow the below steps.

1) Verify if your testcases are as per the requirement.

2) Verify if valid testdata is being used.

3) Try to replicate it with n number of possible combinations of testdata.

4) Take snapshots of the screens where you found the deviation.

5) Communicate to Developer about the Deviation found and finalize whether it is a defect.

6) If you are sure it is a defect at a first go log in the defect tracking tool with proper severity and priority details. Also steps to reproduce should be very much precise so that a lay man should also be able to reproduce that defect by following the steps.

7) Attach the snapshots for reference purpose for Development team.

Please write to me @ sukanya.kambhampati@gmail.com incase you need any additional information.

Regards

Sukanya