Bug Descriptions

How much is enough?

Another discussion happening on Eric’s blog relates to whether solutions should be part of the bug description added by the tester. My response is “Yes definitely” so far as it stays focussed on the functionality and mentions intended behaviour  vs. current /flawed/ behaviour along with context. I do not expect the tester to provide technical solutions within the ambit of defect management tool even if he is so adept because then he will step on toes which are not within his territory. Though he may have good intentions he would spend productive ‘testing’ time  on programming aspects and may inadvertently invite trouble.

My consolidated response reproduced below –

<quote>

If describing the solution (over and above the steps to reproduce the problem) means explaining the intended behaviour as against actual flawed behaviour I would say the defect management tool should include such comments from the tester and as you mentioned by wording it appropriately. As is words and appropriateness of it is a universal must-do not limited to defect management, isn’t it.

The bug description must describe the bug fully and properly in all its ramifications. Period. Extraneous information (unrelated to the bug) would confuse matters – I agree.

The bug must be explained clearly with the help of screenshots/other evidences as gathered by the tester. Details *as relevant* is required since being brief and then exchanging to&fro notes may impact resolution of the bug per se and even cause loss of historical bug data which is valuable even from an analysis perspective.

Without knowing the specifics of your bug and looking at it from here it seems a modification of the bug description (via a revision history) rather than rejection would have been the way to go…

I think the testers are budding business analysts which most developers tend not to be (considering their job responsibilities especially for large applications where her/his focus is limited to development/ maintenance of a module or two). This means that the tester should use the near considerable (expected) application knowledge at her/his disposal and suggest (vehemently at times) how the functionality ought to be. This is a service which needs to be acknowledged by all & sundry including the developers. The tester’s knowledge would fall short of expectations at times and maybe overruled by the developers, business analysts or even the customer. This to a tester must not be a deterrent but an acceptance of human failing with the incentive of the knowledge becoming more wholesome…

<unquote>

The link to the Eric’s blog post is here.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s