Printable View
I have a few doubts in assigning severity and priority for the following Bugs found :
1. Need a Alert at an option
2. Drop-Down list is not Aplphanumeric and numerical order.
3. Navigation Problem
4. Error Handling Bugs
5. A link is not working
6. A link between the two modules is not functioning.
Out of above mentioned Bugs to whom we give the most sevrity and priority and what severity level of these Bugs.
[quote=vijenjoy2k2;19598]i have a few doubts in assigning severity and priority for the following bugs found : 1. Need a alert at an option 2. Drop-down list is not aplphanumeric and numerical order. 3. Navigation problem 4. Error handling bugs 5. A link is not working 6. A link between the two modules is not functioning. Out of above mentioned bugs to whom we give the most sevrity and priority and what severity level of these bugs.[/quote]
(severity:high,medium,low
priority: critical,major,minor)
1. Need a alert at an option
severity:low (functional point of view)
priority : major (usability point of view)
2. Drop-down list is not aplphanumeric and numerical order.
Severity:low(all gui bugs are of low severity because it'l not affect the funtionality of an application).
Priority: critical
3. Navigation problem
severity:high
priority: critical
4. Error handling bugs
severity:low
priority:minor
5. A link is not working
severity:high
priority:critical
6. A link between the two modules is not functioning.
Severity:high
priority:critical.
"severity assigned by testers"
"priority assigned by test lead/qa lead"
hope this resolved ur doubt.if i am wrong in any way please let me know.
Thank you,
ria..
What is RE- testing
When the tester reports a bug, then it is fixed by the developer. To see that the fix is proper or not, the tester tests it again. This is called retesting. After retesting, the bug can be in the following status: Fixed, reopened etc..
[QUOTE=sopova123;29682]When the tester reports a bug, then it is fixed by the developer. To see that the fix is proper or not, the tester tests it again. This is called retesting. After retesting, the bug can be in the following status: Fixed, reopened etc..[/QUOTE]
Hi Sopova
Well i feel Re-Testig would not be the correct word here.
To see that the fix is proper or not, and also whether that fix has caused in any other bug/improperty in the application the tester tests it again. This is called Regression testing and not re-testing :)
Well re-testing is something done for "more coverage", for example testing the same testcase with different input values will come under re-testing.
Also if the same 'build/release' is retested again with same set of testcases then we say the build was re-tested.
Regards
Sabarish
Hi Sabariish,
I think I am very sure of the definitions.
Retesting is testing whether the bug which is found has been fixed or not.
Regression testing is after fixing the bug whether it has afected any other functionality or not . Ie. this bug does not introduce any new bug. To test the other areas to see whether they are impacted by it or not.
Could you please tell us what do you call the phase when a bug is fixed by the developer and has come back to the tester to update the status for it.
[QUOTE=sopova123;29767]Hi Sabariish,
I think I am very sure of the definitions.
Retesting is testing whether the bug which is found has been fixed or not.
Regression testing is after fixing the bug whether it has afected any other functionality or not . Ie. this bug does not introduce any new bug. To test the other areas to see whether they are impacted by it or not.
Could you please tell us what do you call the phase when a bug is fixed by the developer and has come back to the tester to update the status for it.[/QUOTE]
Hi Sopova
:)
1) Lets take a real time scenario:
A tester reports a bug on Build#1, Developer accepts it as a bug in his triage meetings. Now once the severity and priority of the bug is decided (i.e development point of view), the developer works on the issue and fixes it.
Once the fix is done he will form a new Build lets say Build#2. Once this build comes for testing we say the build is in regression testing phase and not re testing.
More over to test whether a bug is fixed or not will be done in regression testing phase.
2) To end with the ISTQB standard definition for both retesting and regression is as follows:-
Retesting Testing : re-execution of testcases on same application build with diferent inputs or testdata.
Regression Testing : re-execution of testcases (Can be selected or whole set of testcases) on modified build to ensure bug fix work *completeness* and *correctness*.
Hi sabariish,
Could you please tell us what exactly comes under retesting. Is bug retesting a part of retesting or is just another name for it.
From ur definitions I can make out one thing. Please tell me if I am correct or not.
When I execute a test case and it fails , I log a bug. Now when the bug comes in build 2 after a fix, I again execute the same test case but with different inputs now.
Is that what you mean to say.
Thanks in advance
[QUOTE=sopova123;29955]Hi sabariish,
Could you please tell us what exactly comes under retesting. Is bug retesting a part of retesting or is just another name for it.
From ur definitions I can make out one thing. Please tell me if I am correct or not.
When I execute a test case and it fails , I log a bug. Now when the bug comes in build 2 after a fix, I again execute the same test case but with different inputs now.
Is that what you mean to say.
Thanks in advance[/QUOTE]
Hi Sopova
Yes, Bug retesting can be termed as a part of re-testing. But to say re-testing is just to see only the bug reported is fixed is not appropriate.
The following may come under Retesting:-
- Test the application again or re-execution of tests with different inputs or multiple test data
- Check whether the bug reported is fixed
- Check only the module in which the changes were made
- testing the functionality of the module again and again by different test engineers in a team(On the same build)
Whereas Regression Testing:-
In Regression Testing , we test the whole appliaction after change is made to make sure that the changes does not effect previous functionality. Usually a new build is formed with all the "bug fixes" made and then given for testing so that any regression bugs are found.
hi friend
ur definition about retesting and regression testing is a little bit wrong
In Retesting we dnt have need to check the functionality of the module,we just retest the previous failed testcases again and again whenever they have not passes.
In Regression testing ,again we dnt need to check the whole application we just check these modules of that application which are connected to each other in the form of functionality.
with regards
amit tewari
Retesting have two types:
1) Retesting: Re-execution of tests which have previously been executed in-correctly(failed), in order to verify the fixed bug and subsequent revision of that same product.
2) Regression Testing: Selective retesting of a system or component to verify that modifications have not caused any effect (no ripple effect) on the dependant component of the system or dependent component still complies with its specified requirements
Hi,
If severity is to mention then anyone can do it, but priority will depends on time lines and user requirements.
[QUOTE=vijenjoy2k2;19598]I have a few doubts in assigning severity and priority for the following Bugs found :
1. Need a Alert at an option
2. Drop-Down list is not Aplphanumeric and numerical order.
3. Navigation Problem
4. Error Handling Bugs
5. A link is not working
6. A link between the two modules is not functioning.
Out of above mentioned Bugs to whom we give the most sevrity and priority and what severity level of these Bugs.[/QUOTE]
hi to all
i think sopova and sabariish are fighting each other .... really i'm proudof u both but u both r wrong about retest and regression testing.........amitefextra answer is correct.....don't get confused.........
With Reg
ABU
You both sopova and sabariish may correct if I will say Under regression testing by knownly or unknownly you are doing retesting.i.e Under regression testing yau may need to do retesting.This ans is not 100% correct always, but it may help for further discussion, Hope...;)
ya, amit tewari answer is correct,
Retesting: repeated test in same build..
regression : repeated test on modified build.
let me explain a simple example.
when we r testing a object by taking some test data, if the data is wrong by the testing people, thn its come under retesting.Test data related defect is ur retesting which is fixed by testing team.Test script related defect that is also comes under retesting.When the defect is code related , and after solving that defect by developer, we get a modified build, so on that we go for regression testing ensure that the modification in coding is effect any other related functionality?
JP
[QUOTE=Ria.STP;19624](severity:high,medium,low
priority: critical,major,minor)
1. Need a alert at an option
severity:low (functional point of view)
priority : major (usability point of view)
2. Drop-down list is not aplphanumeric and numerical order.
Severity:low(all gui bugs are of low severity because it'l not affect the funtionality of an application).
Priority: critical
3. Navigation problem
severity:high
priority: critical
4. Error handling bugs
severity:low
priority:minor
5. A link is not working
severity:high
priority:critical
6. A link between the two modules is not functioning.
Severity:high
priority:critical.
"severity assigned by testers"
"priority assigned by test lead/qa lead"
hope this resolved ur doubt.if i am wrong in any way please let me know.
Thank you,
ria..[/QUOTE]
[QUOTE=vijenjoy2k2;19598]I have a few doubts in assigning severity and priority for the following Bugs found :
1. Need a Alert at an option
2. Drop-Down list is not Aplphanumeric and numerical order.
3. Navigation Problem
4. Error Handling Bugs
5. A link is not working
6. A link between the two modules is not functioning.
Out of above mentioned Bugs to whom we give the most sevrity and priority and what severity level of these Bugs.[/QUOTE]
Hi
Ria was given correct priority and seviurity...
but at the time of defining Severity of the bug we need to concentrate on the functional impact on the application with the bug...
while defining Priority we need to concentrate business requirement.
I think u got the answer .......