I was testing a pretty tricky defect today. I realised that I had encountered a similar defects 3-4 versions/builds back.
At first I was suprised as too why did it re-earth. Did I not test it enough before closing it?
As I pondered on it, I wondered when is the right time to close a defect.The answer will be very simple -->The moment you think it will not occur again:)
However life is not that simple now is it?
There are many things you wil have to look out for:
1.Severity of the defect.
2.Probability of it's occurance.
3.Confidence in the developer.
However I still not able to figure out when is the best time to close a defect.
1.After couple of regression rounds?
2.Just retesting it over a couple of builds/version?
3.If the unit testing results are very positive?
Any suggestions?
Subscribe to:
Post Comments (Atom)
Posts
First of all congrats for your FIRST post...now coming to your post.
ReplyDeleteHow long before you close a defect:
Context1: This defect is pending from ages suddenly got priority after it was reported from field
Context2: This defect is pending from ages, management wants to close it becoz dev's have time
I assume context1:
1)I would first get the priority of that defect
2)Check the history of this defects recurrence If any
3)Do some analysis & get Info on Impacted areas with help from dev
4)Retest that defect and If needed test the Impacted areas and then close it
Defect types:
1. Reproducible defect
2. Non reproducible defect
3. Reproducible sometime only
Now its tricky...the steps I mentioned will give different results in each of the above type of defect
1. My result would be defect is fixed & closed
2. My result would be defect is not reproducible
3. MY result would be defect any one of the above
To conclude, There is no one best answer BUT to you can take the best decision based on Information you have. REST say AAL IS WELL once you signoff :)
This is what I have to say!
ReplyDeleteThis is what, I have to say!
I think you missed out on some of the vital reasons for defect re-occurence.
1. Defects many times are also specific to the underlying technological framework. For example: Use of a .net in place of java for a certain kind of business applications wouldn't work. Reason being the dynamics of that particular business process app would best suit for Java and not .net.
2. Defect in the previous stage of development cannot be fixed in the later stages. If there is a defect in the requirement or in the game design, would lead to irreparable cracks in the code, which no matter how good the developer is trying to cover up will sprout up again.
For many such reasons, we exactly can't say if such a re-occurring defect can be closed at a certain stage.
The only solution would be mutually agreeable closure between the Prod, Dev and QA teams, and sometimes we can also involve the client in decision making for such defects.
Pl. do let me know, if my argument justifies your question?
@Ayyappa's Comments:
ReplyDeleteBest time is as soon as defect get fixed :))
In general we con’t keep the defect in our plate , just for the sake of no confidence on developer
At least in our case we don’t even know who is developer J
If this defect reoccurs in subsequent build you have to reopen again by giving additional comment or you can send a mail to development manager / respective stakeholder about this issue. And this communication should not impact defect status.
Best solution could be write a test case which produce this defect and include that test case in smoke suite (if possible) if not than include this test case in regression suite J
Ayyappa.K
Comments from me developer friends:
ReplyDelete@Sachin Bhave:
I believe issues like this usually resurface because of a fix for some other defect. Its the classical case of fixing something broke something else. I would say the developer should be confident enough that a particular bug wont occur again, but a tester should still test for it after couple of builds.
@Chaitanya Karmarkar:
To resolve this issue, please start Automating your scripts.
For example, if you are working on a retest of an issue say concerning login. Then exclude this test from Automated Script and run rest all scripts via an automated script. Now, test manually the funcationality that has been changed.
So, this way you will get more time to focus on the key area and let Automated script perform the regression.
Secondly, you should instruct the development to perform their side of Smoke Test before giving it for QA and it should be the part of the development consumed by the development time.
Lastly, please notify the development lead and project manager that the cut-off time for QA is such and such. If the development team is not able to give it by this time then it will be a disaster. Then, let the Project Lead and Project Manager answer the customer.
Hello to all! First comment :)
ReplyDeleteIt looks like you describe a situation like this:
http://www.youtube.com/watch?v=RExu7kE98R8
First of all - these things happen. The same erronous effect (lets call it like that) can happen several times in the SW life cycle. The reasons usually are:
* bad version management - the fix is overwritten by some other code
* insufficient testing (testing only the initially described scenario OR the defect is not reproducible)
* enabling disabled features
So how to decide WHEN to close the defect? As Shiv said there is no single answer. What can be done is make the decision based on all the info you have.
Should the closed defect later occur again, then you can analyze why it resurfaced and based on it react. It could be that new builds broke the same functionality (but the root-cause is different). In this case it is a NEW defect. It could be that initial tests did not cover the impact areas. This means poor planning. Or it could be that tester had a bad day and simply missed it. Which is bad QA.
But no matter what is the reason for resurfacing, the defect should get closed when the described scenario for reproducing the defect works as expected. After all, you can always log a new defect for which you need to decide when to close it.
Good to see you Evari...this blog has got some life now :)
ReplyDelete