Ten Principles of Creating Effective Defect Reports
Defect reports are the most important outcome of any testing effort. These are equally important like a test plan and have quite significant effect on the product quality compared to many other testing deliverables.
An effective defect report certainly helps the tester in getting a much better response from the developers.
A good tester is the one who does not aspire to write a perfect defect report, but aims to write a defect report that is having following Four Simple Attributes like:
Attribute-1: It must be effective
Attribute-2: It must communicate the adequate message
Attribute-3: It must be sufficient to get the required job done
Attribute-4: It should be able to simplify the process for all concerned
To pump in the above four attributes in a defect report, Ten Basic Principles are being described here. Their prime objective is to lay maximum focus on "Attribute – 1"
1) Must be Short & Brief: It must not display your excellence of writing skills with Shakespearean English. The objective must be that
# Whatever we need to say must be brief & must be clear.
# It should be free from complicated words.
# It should not be packed with unwanted information. Contents must be absolutely relevant.
# It should not have too much of Information, most of which might not be useful.
Remember that irrelevant information is more troublesome compared to too little useful information.
2) Must be Precisely Defined: Ensure that only the real bugs are reported. Think carefully & do the proper homework to eliminate the possibility of reporting some product misunderstanding or some user error etc. In the absence of an intelligent homework prior to writing the problems, your credibility can be at stake.
Following rules of thumb shall be helpful while reporting problems.
a) Do not over report as well as do not under report.
b) Be courageous to report the genuine problems.
c) If you happen to report a problem incorrectly & discovered the error later, try to learn from it.
d) When in doubt about the validity of some problem, never have hesitation in consulting another experienced tester or even the developer.
Following considerations will be helpful while writing up the problem:
# Whether the problem is due to any issue related to setup – like it might be due to installation of improper versions or the use the incorrect login, violation of security aspects, use of incorrect command or incorrect sequence of tasks etc.
# Whether the problem is due to incomplete cleanup or due to incomplete results, due to manual interruption by some of the previous tests etc.
# Whether the problem is due to network or some other environment related issues.
3) Be objective & neutral: The problem must be defined objectively & with a neutral attitude.
There should not be any place of personal emotions & humor in your reporting. Many a times we get so much impulsive to report while taking a problem as funny from our viewpoint & don’t realize that our emotional reporting is liable to create serious barrier in healthy communication and will hamper the teamwork.
Try to redraft the comments – even if you are rightly able to contradict the developers & are having strong evidence to support your viewpoint. Never ever try to write comments that do not communicate any useful information, rather liable to be taken as accusations against any individual.
If you desire to be respected & increase your credibility, study all your comments & the problem description carefully prior to reporting.
4) Describe the problem precisely & explicitly: Instead of providing just the description as to what had happened; try to describe the problem precisely and explicitly.
Following tips will be helpful while describing the problem:
#The headline description must reveal the problem from your viewpoint.
# Avoid providing series of your actions and results in description statements.
# In case the description happens to be long, try to provide the summary of the problem in its beginning itself.
# Never think that your conclusions will always match with that of others.
# Write the problem description with an objective that it should not be misunderstood in any case.
5) Isolate the problems: The difference between a good tester & a novice is that the former puts in good amount of effort in isolating the problem.
Following tips will be helpful in isolating the problem:
# Write down the simple & short series of steps to reproduce the problem detected by you.
# Use your expertise to confirm if the problem has arisen due to something not concerned with the particular code. For instance a network problem might be the cause of a system delay or hang-ups etc., while you might be on the verge of reporting it as a problem related to the code.
# Try to pinpoint the specific input responsible for causing the problem. In case of multiple input conditions in the tests, try to change the inputs one by one to isolate the problematic one.
# The specific problematic input must be a part of the problem description as far as possible.
Remember that, If you are able to isolate the problem effectively, you will save considerable amount of time while verifying its fix.
6) Generalize the problem: As a tester when a problem is noticed by you, try to find out if the problem happens to be more of a general nature compared to what it appears. Remember that a special problem will require specialized fix while a general problem obviously require a more generalized fix.
Ask yourself as to what have you done to understand - how general your problem is?. A proper homework to identify a generalized case before writing your report will save the developer a considerable amount of time, so that he can plan a much better fix for a general case instead of fixing it the way otherwise reported by you.
7) Identify essentials to re-create the problem: It is quite significant to be able to re-create the problem. Although it is not always easy to re-create some of the bugs, do not make a mistake of making an assumption that you will be able to re-create the bug any time without actually verifying that it can be re-created.
If you are not able to re-create the problem due to any reason, it is wise to make notes in the defect remarks & try to provide maximum relevant information to the developer responsible for making its fix.
Sometimes when recreation of problem state is not feasible, you may like to invite the developer to practically inspect the system during such a state before performing a cleanup operation to restore the system. It is possible that the developer might be interested in capturing some more information during such problem state.
However when it is possible to re-create the problem, you need to describe all steps, including file names, syntax exactly used & all sequences followed when the problem was encountered & repeat such steps once again to re-create the problem. List down the details of easiest & the shortest method, conditions & environment to re-create the problem.
8) Identify the effect on the client: Try to make the best possible judgment on the likely impact, if the bug happens to get noticed under the customer environment.
For example, typographical error on a window might be of a very minor nature, but keeps on irritating the users, hence need to be fixed before the product is shipped. Never try to push the defect without proper understanding of the gravity of its seriousness & its likely effect on the customer.
9) Information for debugging: Make a comprehensive document listing out the complete information like captured logs, dumps, traces etc that would be helpful to the developer in debugging the problem. Provide every useful information to the developer. Such an information must be an important attachment to the defect report.
10) Provide documentary evidence of problem: Remember that others need to be convinced about the actual existence of the problem. They need to be explicitly told that what you got as against your expectations. Of course your set of expectations can’t be communicated orally, but need to be properly documented.
Your expectations can be derived from documentation like:
# Specifications documents
# User guides
# Past comments provided by customers
# Standards like specifications of competing products
# Results of older versions of the product.
If you feel that others may not get convinced with your bug as a valid one, you need to do more homework to provide even more concrete evidence to support your claim.
Conclusion:
Ultimately what is important is to ask yourself as to whether you have asked the right questions & have answered the right questions, while writing your defect report.
An effective defect report certainly helps the tester in getting a much better response from the developers.
A good tester is the one who does not aspire to write a perfect defect report, but aims to write a defect report that is having following Four Simple Attributes like:
Attribute-1: It must be effective
Attribute-2: It must communicate the adequate message
Attribute-3: It must be sufficient to get the required job done
Attribute-4: It should be able to simplify the process for all concerned
To pump in the above four attributes in a defect report, Ten Basic Principles are being described here. Their prime objective is to lay maximum focus on "Attribute – 1"
1) Must be Short & Brief: It must not display your excellence of writing skills with Shakespearean English. The objective must be that
# Whatever we need to say must be brief & must be clear.
# It should be free from complicated words.
# It should not be packed with unwanted information. Contents must be absolutely relevant.
# It should not have too much of Information, most of which might not be useful.
Remember that irrelevant information is more troublesome compared to too little useful information.
2) Must be Precisely Defined: Ensure that only the real bugs are reported. Think carefully & do the proper homework to eliminate the possibility of reporting some product misunderstanding or some user error etc. In the absence of an intelligent homework prior to writing the problems, your credibility can be at stake.
Following rules of thumb shall be helpful while reporting problems.
a) Do not over report as well as do not under report.
b) Be courageous to report the genuine problems.
c) If you happen to report a problem incorrectly & discovered the error later, try to learn from it.
d) When in doubt about the validity of some problem, never have hesitation in consulting another experienced tester or even the developer.
Following considerations will be helpful while writing up the problem:
# Whether the problem is due to any issue related to setup – like it might be due to installation of improper versions or the use the incorrect login, violation of security aspects, use of incorrect command or incorrect sequence of tasks etc.
# Whether the problem is due to incomplete cleanup or due to incomplete results, due to manual interruption by some of the previous tests etc.
# Whether the problem is due to network or some other environment related issues.
3) Be objective & neutral: The problem must be defined objectively & with a neutral attitude.
There should not be any place of personal emotions & humor in your reporting. Many a times we get so much impulsive to report while taking a problem as funny from our viewpoint & don’t realize that our emotional reporting is liable to create serious barrier in healthy communication and will hamper the teamwork.
Try to redraft the comments – even if you are rightly able to contradict the developers & are having strong evidence to support your viewpoint. Never ever try to write comments that do not communicate any useful information, rather liable to be taken as accusations against any individual.
If you desire to be respected & increase your credibility, study all your comments & the problem description carefully prior to reporting.
4) Describe the problem precisely & explicitly: Instead of providing just the description as to what had happened; try to describe the problem precisely and explicitly.
Following tips will be helpful while describing the problem:
#The headline description must reveal the problem from your viewpoint.
# Avoid providing series of your actions and results in description statements.
# In case the description happens to be long, try to provide the summary of the problem in its beginning itself.
# Never think that your conclusions will always match with that of others.
# Write the problem description with an objective that it should not be misunderstood in any case.
5) Isolate the problems: The difference between a good tester & a novice is that the former puts in good amount of effort in isolating the problem.
Following tips will be helpful in isolating the problem:
# Write down the simple & short series of steps to reproduce the problem detected by you.
# Use your expertise to confirm if the problem has arisen due to something not concerned with the particular code. For instance a network problem might be the cause of a system delay or hang-ups etc., while you might be on the verge of reporting it as a problem related to the code.
# Try to pinpoint the specific input responsible for causing the problem. In case of multiple input conditions in the tests, try to change the inputs one by one to isolate the problematic one.
# The specific problematic input must be a part of the problem description as far as possible.
Remember that, If you are able to isolate the problem effectively, you will save considerable amount of time while verifying its fix.
6) Generalize the problem: As a tester when a problem is noticed by you, try to find out if the problem happens to be more of a general nature compared to what it appears. Remember that a special problem will require specialized fix while a general problem obviously require a more generalized fix.
Ask yourself as to what have you done to understand - how general your problem is?. A proper homework to identify a generalized case before writing your report will save the developer a considerable amount of time, so that he can plan a much better fix for a general case instead of fixing it the way otherwise reported by you.
7) Identify essentials to re-create the problem: It is quite significant to be able to re-create the problem. Although it is not always easy to re-create some of the bugs, do not make a mistake of making an assumption that you will be able to re-create the bug any time without actually verifying that it can be re-created.
If you are not able to re-create the problem due to any reason, it is wise to make notes in the defect remarks & try to provide maximum relevant information to the developer responsible for making its fix.
Sometimes when recreation of problem state is not feasible, you may like to invite the developer to practically inspect the system during such a state before performing a cleanup operation to restore the system. It is possible that the developer might be interested in capturing some more information during such problem state.
However when it is possible to re-create the problem, you need to describe all steps, including file names, syntax exactly used & all sequences followed when the problem was encountered & repeat such steps once again to re-create the problem. List down the details of easiest & the shortest method, conditions & environment to re-create the problem.
8) Identify the effect on the client: Try to make the best possible judgment on the likely impact, if the bug happens to get noticed under the customer environment.
For example, typographical error on a window might be of a very minor nature, but keeps on irritating the users, hence need to be fixed before the product is shipped. Never try to push the defect without proper understanding of the gravity of its seriousness & its likely effect on the customer.
9) Information for debugging: Make a comprehensive document listing out the complete information like captured logs, dumps, traces etc that would be helpful to the developer in debugging the problem. Provide every useful information to the developer. Such an information must be an important attachment to the defect report.
10) Provide documentary evidence of problem: Remember that others need to be convinced about the actual existence of the problem. They need to be explicitly told that what you got as against your expectations. Of course your set of expectations can’t be communicated orally, but need to be properly documented.
Your expectations can be derived from documentation like:
# Specifications documents
# User guides
# Past comments provided by customers
# Standards like specifications of competing products
# Results of older versions of the product.
If you feel that others may not get convinced with your bug as a valid one, you need to do more homework to provide even more concrete evidence to support your claim.
Conclusion:
Ultimately what is important is to ask yourself as to whether you have asked the right questions & have answered the right questions, while writing your defect report.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-670829/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-670829/