You have to register it as a bug . and you have to decide the prority, severity and register it in bug tracking tool so your testlead,developer and project manager get noticed that.
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.
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.
Prasad Meduri
Feb 13th, 2006
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.
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
satish.c
Mar 9th, 2006
if the actual doesnt match with the expected then we shall report tht as a bug, then we will assign its seviority & priority by looking at the bug cause.
not match , we can raise a bug and give to seviarity as well as priarity and put defect tracking .
Thanks
Srinivasulu.chittoor.
Venu Narayanan
May 1st, 2006
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..
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.
If the actual result doesn't match to expected result , then the testcase is failed. Re execute the same test case for reproduciability. If the same occurs it is a bug. then log the bug in the BTS.
Hi , The combination of Mr. sanjiv and sukanya answer is best suitable for this question.
Normally Any developer not accept his mistakes. so first we have to clarify our self . how much perfect we are mean check two or more times actual results with expected results and read carefully SRS document (any changes recently becasuse developer first know about changes )once again, then you send to developer or Assigned person.
If the actual result does not match with the expected result then it is considered as a bug.So it can be logged as a defect after confirming it is bug by reproducing it 3 or 4 times and attach the snap shot of it.
Its simple need to cross check once again with that test case and lock that as an issue, and you have to decide the priority severity and register it in bug tracking tool so your test lead developer and project manager get noticed that.
The part until logging the bug and a tutorial on 'how to' is also great except for assigning severity and priority. I disagree on this!
BA, QA team, Dev lead and some devs would hold a defects review AKA (also known as) triage meeting. This is when severity and priority are assigned. This is also the time bugs are assigned to devs if they are indeed bugs, or rejected if the behavior is expected.
If the actual result doesn't match with expected result in this situation what should we do?