Posted by
Amit Kulkarni [Admin]
| Posted in
bugs
,
change request
,
customer
,
defect
,
delivery
,
deployed
,
fix
,
impact
| Posted on
9/24/2009 06:36:00 PM
Posted by Amit Kulkarni [Admin] | Posted in bugs , change request , customer , defect , delivery , deployed , fix , impact | Posted on 9/24/2009 06:36:00 PM
Just wondering how things work with Bugs and Defects. We know for the fact that these are terms used and they do not have the same meaning. I wonder then who is responsible for a bug and defect. Well, the answer is pretty simple! As a tester your job is to find the bugs - so have you created on your own any. No. You just found the bugs which were there in the application, so the responsibility lies with developer. On the other hand if defect then only the responsibility lies with tester. Am I going away from the basic topic here?
Both the terms are very well known to testers. These terms appear to be synonyms of each other but they do carry a different meaning - but what would be the IMPACT!
If you are testing any application and you come across the bugs - you will file them and they will be fixed by developers. This is how the cycle goes on until we have an application which is ready to deploy with zero bugs. Now can we deploy a product with bugs? No. How will you deploy an application when you know it contains bugs?
With bugs you can not deploy/deliver the product to the customer. You need to make sure that all the bugs which are there get fixed and if any new bugs produced during this activity then fix those too and then you are ready to deliver. The impact of having bugs in the application can halt the delivery of it.
What about defects? Well, these will be found out by the client when the application was deployed or delivered. Defects are found when the application goes live. It can be customer or any user who report the defect and then the customer can question us - how did this happen? In this case, the responsibility lies with tester, as they were unable to catch it in the first instance.
So once we deployed/delivered the application to the customer - if they comes up with any defects then the emphasis on whether to fix them or not. If the customer thinks that these defects will hamper their application at a larger extent then they have all the right to get it fixed. The customer comes with the request to fix them up. Here the "change request" cycles start and we need to fix them.
Best Regards,
Amit
testing is my passion!!!
http://bugteaser.blogspot.com
Subscribe to:
Post Comments (Atom)
Hi Amit,
I think much depends on the definitions you assign for "bug" and "defect." This is important because these terms are often used in the reporting and analytics of the software you're using to track your bugs/defects. Which toolset are you using and how are bugs/defects defined there?
In your definition it appears you are saying defects are bugs found after the code is deployed. However, I've typically seen defects be defined as any problem with the application under test (documentation errors, missing functionality, etc.) with bugs just being one type of defect.
Regardless of how you define it, it should be the goal of the team to eliminate the bugs before deployment. Once deployed the cost of fixing a defect/bug is exponentially higher. There is also cost associated with lack of credibility in the product.
Thanks for a thought-proving article.
A Rose by any other name in my opinion.
Ode to a 'Bug'
----------------
In the beginning there were 'bugs', they were not considered to be a good thing. But they were real and present, and in mass numbers at times.
These bugs were 'defects' in the code or design of the system, and as such caused an 'issue' for the people both using the system and building it.
Thus if a bug was found an issue was raised by the users and they would point out the defect to the developers.
The developers would fix the defect so that is would no longer be an issue and as a result remove the bug from the system.
But in some instances the defect was found to actually be an 'anomaly' caused by an 'inadequacy' in the original specification of the system.
This caused the system to naturally contain a defect that would eventually become an issue because it would just bug users because it was present.
Now because the inadequacy propagated the anomaly which led to the defect and caused an issue the end-users would just have to live with the bug.
Alas, the end-users complained and then management got involved. To smooth things over they proclaimed that the bug is not a defect and there was no longer an issue.
Instead they stated that the issue caused by the anomaly due to the inadequacy was actually a 'functionally unreproducible business application response', or FUBAR.
This FUBAR in turn would just make the 'system not available for use', or SNAFU.
This SNAFU was the real culprit behind the FUBAR and explained the inadequacy which removed the anomaly that raised the issue that was depicted by the defect which just bugged users.
This eventually led the users to believe that no matter what, a 'bug' will eventually lead to a FUBAR that causes a SNAFU.
- Jim Hazen
Yvette,
I appreciate your thought on my post.
Here is what I mean:
Bug: Which is found before the application goes into production (release)
Defect:Which is found after the application goes into production(release).
Best Regards,
Amit
testing is my passion!!!
http://bugteaser.blogspot.com