Friday, January 20, 2006

Transition of Bugs

I do testing in application which is developed under eXtreme Programming model. Due to the short span of the development process, we always work with bitter pressure. Whenever I encounter a bug, I immediately logged the issue in the tracking tool and if necessary I would made a face to face discussion with the developers.

I was recently testing an application which had an excellent search function. Most of the pages had a data grid with 4 to 6 columns. The point here I wish to mention is, the bugs identified is taking different weightage at different levels of development process. Within a period of week, the high priority bug becomes obsolete.

When I tested the application few days before release, I encounter a bug in the data grid. Each row of the data grid has a button to Edit/Delete the entire row. By clicking the edit button, we can make necessary changes in the details. In the latest build before release, I noticed a hyperlink (apart from edit/Delete button) for the entire row in the data grid which serves the same purpose of Edit/Delete button. I logged this in the tracking tool and considering the release date I rated it as “High”. I have been asked by developers to drop the issue since it is not going to affect any part of the application. Bugs are not only the missing functionalities; an additional functionality is also a major bug. I stick with my Bug and compromised with its rating (Medium). After a prolonged conversation, I was forced to drop the issue as a known bug by considering the time frame. The fact is, what I took as consideration to rate this bug as “High” becomes the same to neglect it within an overnight. I know this is a bug, don’t have any obvious document to prove it. Merely waste of time in argument. The question is: Is rating the bug is unnecessary in XP model? Why can’t we eliminate the rating of the bug? Can’t we think about some alternative? Feel free to drop your comment here else mail me.


Yogs The Tester said...

This is nice to see that such interesting questions being asked.

From the excerpt shown over there on ur blog, it seems that you dont have the requirement document nor the specific testing lifecycle. If you do have the requirement document then it is not much difficult to prove an extra functionality added is a bug.
Correct me if I am wrong. I think that structure of a program becomes unnecessarily complicated. If the software u r releasing to the customer donot have any problem with it, then its ok to leave that functionality as a known bug. But We should at least check that that functionality do not affect the desired use of the application.


If you can provide me more details then may be I can elaborate more on this point.

Waiting for your reply.

Yogesh Y. Degloorkar

yendrum anbudan said...

hi raja,

i am new to blogs, bloggers and XP model but in this article as your are talking about bugs and so i thought of getting in.

Bugs should have the classification and Each Bug should be classified in terms of severity and priority.

if the tool has only one type of classification then it refers Severity and not Priority. In that case we have think only about the Impact and not the time bug identified.

though bug is known two things are clear form your statement.

1. The Bug is NOT Degrading the functionality, if edit/delete link is not working and field is a mandatory that has to be fixed for sure.

2. since it is about to release, the time to code, unit test, compile, release, test and approve may extend the delivery date or time so in that case, it has to be released with a note saying so so

3. If further release are coming up (near or later) then usually not required to provide a note since adding NOTE while delivering a Product is a good sign and moreover most of the clients (as of I seen) wont both unless something is missing.

correct it if I am wrong.

Yendrum Anbudan