Introduction
The defect report is the most important thing that can be submitted during the test. Its importance is not less than the test plan, and is more affected by the quality of the product in the testing process. Therefore, it is necessary to learn how to write a valid defect report. Effective defect reports will be able to:
l Reduce the secondary defect rate of the development department
l Improve the speed of development and modifying defects
l Improve the credit of the test department
l Enhance collaboration in testing and development departments
Why is the test person getting more feedback from development than getting from other departments? To a certain extent, this answer is the defect report, which can make the whole process more smooth in accordance with some simple rules. But our goal is not to write a very perfect defect report, but to communicate the correct information, allowing the work to complete and simplify the effective defect report of the process.
This article mainly tells two aspects of the defect report: 1) The description of the description; 2) Abstract. First let's take a note.
Defect notes
Here is to make sure you are a few key points for your next defect report:
l Condense - streamlined, clear and short
l Accurate- is accurate, is this in the end? Or is the user operates an error, or it is wrong, and so on?
l NEUTRALIZE - Declaring the facts in neutral language, without prejudice, no humorous or emotional language.
l PRECISE - What is the problem?
l Isolate - What kind of problem is this? Try to narrow the scope of this issue.
l Generalize - Is there any other place to have such problems?
l RE-CREATE - How to trigger and reproduce this bug? (Environment, steps, prerequisites)
l Impact - What is the impact of this defect? What impact does it affect?
l Debug - How to make the development easier to modify this bug? (Tracking, screenshot, log, direct access, etc.)
l evidence-evidence, how to prove this bug?
Write a valid defect report does not need a good text skill, just verify that you correctly answer the above questions, the key is to confirm that you have overwritten all your defect reports.
Key points for effective defects
streamline
Clear and short. First, remove unnecessary words; second, do not add unrelated information. It is most important to include the appropriate information, but ensure that this information is useful. Regardless of the reason, you should provide more information for those who do not describe how to reproduce or understand, you should provide more information. The unnecessary information written is also a problem.
Streamlined example defect notes Don't write this: TMI (TOO MUCH INFORMATION) When I am concentrating on testing, I report a memory error. At this time, I found a Gui I am not familiar with, I tried a multilateral value and the wrong condition, but Operating normally. Finally, I invited the data, and click the forward button. At this time, the system is abnormal, and repeatedly trying to prove that in any case, as long as the "product description" does not have data, click forward or exit even cancel, system It will stop. To write this: In the product information page, if the product's description field is empty, advance, exit, and cancel the feature will cause the system to accidentally stop. accurate
Confident, you are being submitted is really a bug, if you have an error, you will lose your credibility, you will lose your credibility. So before submitting a bug, you must consider:
l Will this problem due to a certain reason for installation? For example, whether the correct version is installed and the various prerequisites have been met? Is it wrong if you log in, safe setting, command or operation?
l Whether there is any cleaning, or the result is incomplete, or because some changes were previously tested?
l Will it be a network or environment?
l Do you really understand the result of your expectation?
There is usually a lot of situations that will affect our test results, so that you know these influences and consider these effects when you report BUG. This is also an aspect of a nickname or has an experience. If you can't make sure you find it is really a bug, follow the experienced testers or development discussion far more than directly submitted BUG to be wise.
But at the same time, please remember such a sentence: "It may be wrong, but not reported is a crime" (it is a bit like China's "Ning Ke, you can't let one"), don't let it be afraid of reporting an error. BUG, you have to do just Jin Li to make sure you have a good news, and if you discover a question that has been reported is wrong, it is sure that you have learned from it.
Neutral language
Objective telling this problem, testers do not use humorous or other statements with emotional colors when reporting BUG. In your opinion, I don't know how to smile for those who are under the pressure of Schedule. With an emotional, there is no benefit of modifying BUG in addition to the communication barriers and collaborative difficulties in Team within Teams and collaboration. Even if the developer has doubtful to the bug you report, now you find evidence to prove that you are right, don't do this, what you have to do is reporting this question, and coupled to developers Help information, long, help to increase your credibility. Before submit BUG, read your bug carefully, delete or modify which may make others generate ambiguity sentence.
Neutral Language Example: This example is that the tester is developing a bug, requiring more information, and the reply bug's comment when there is an error:
Enter any illegal data will abort. Ok: Function ABC will abort any illegal data, for example: -1, -36, -32767
accurate
People who see your bug report may not need to know what kind of problem this is, so testers must correctly describe what they want, some of which are operational steps and results, for example: "I press it. Key, then the phenomenon A appears, then press the back button, phenomenon B appears, then enter the command 'xyz', phenomenon C appeared ", seeing such an explanation, it is difficult for others to understand what problems, three phenomena Which one is wrong. In any case, when the bug is described very long, it must be described in the beginning of this bug. Don't think that you can understand the abstract words you wrote in the bug report, don't think about reading your description, others will have the same conclusion with you. Your purpose is not to write a deep article that is difficult to understand, but a description that is not misunderstood by others. I want to do this only clear and accurate and objective description you discovery, not a brief explanation. Accurate example: Bug description: This despise is difficult to let people know what is wrong. Is it a printed port delay or a printer that is not ready or the information of the printer's display panel is incorrect. The problem occurs when the print port is delayed, and the printer's ready light is always unlimited. At this time, "Print IPDS from TRAY1" is displayed on the printer display panel: how to happen when describing the short language overview problem. When the printer is printing, cancel printing will cause the printer hang. The problem occurs when the print port is delayed, the printer's penetration light is always unlimited, and "Printing ipds from tray1" is displayed on the printer display panel.
Position
For testers, what extent should be positioned, each company or each department has different provisions and expectations. Regardless of these requirements, there must be some effective things to locate problems for a testers. When trying to isolate a problem, you need to consider the following points:
l Try to find the shortest, easiest steps to reproduce this problem, which usually takes a long time.
l Ask yourself if you will be this problem caused by the external special reason? For example, if the system hangs or delay, will it be because of the network problem? If you are doing a point-to-right test, can you say which component has an error? Is there any way to narrow the scope of the determination of the error component?
l If you test a project with multiple input conditions, you can try constantly changing the input value, then view the results until you find the error caused by the result.
In the problem description, the test input values you are using are accurately described in the same range as possible. For example, if you find a script in the test, you will be wrong when you print a script, then you should first think of whether you print all the types of scripts will be wrong.
Test staff positioning BUG's ability to a certain extent is an embodiment of the additional value of Tester. Effective BUG positioning can save all the time of the same group, while saving your time to recall BUG.
induction
Under normal circumstances, developers will only "accurate" to modify the bugs in accordance with your report, and will not change the corresponding other related bugs because the testers do not summarize. For example, I reported such a bug, which is a problem with the save function of my text handler. When saving a file named "My File", the text handler will be turned off. However, this happens while the file is saved in a file length of 0, or attempts to save in a remote disk, a read-only disk generates this situation. If you can write like this will save a lot of time, and you can improve the quality of your system.
When you find a question, use a reasonable step to determine that this problem is usually still an occasion or occurs in special conditions. Incident: BUG report content should not be written: When using illegal characters as a file name, the system will appear the "file could not find" error prompt information. To write this: When you use an illegal character as a file name, the system will appear "File Can't find" error prompt information. Every time I have this problem when I am inserted into characters, but there is no problem without inserting characters.
Reproduce
Some bugs are easy to reproduce, some is difficult, if you can reproduce a bug, you should accurately explain the necessary conditions. You should list all steps, including accurate combinations, file names, and sequence of operation you encounter or reproduce this problem. If you can confirm that this problem occurs under any file, any operation sequence, etc., it is best to give a clear example to help development.
If you have been tested but find a problem with you, then provide effective information to your developers as much as possible. Do not clear your test data before the development does not reproduce or develop, or you do not clear your test data, or at least you want to back up these data. Don't give you a question before you don't verify this problem. If you can't reproduce or don't do it, you must be reproduced, you must label in the bug's report.
influences
What is the impact of a bug in the customer's environment? Many bugs are obvious. For example: When entering the system, tap the Enter key and the system will drop. The problem is not so obvious. You may find a typographic error or spelling in a window. For testers, it may feel a small problem, even a negligible problem, but for users, this It is the first thing he contacts your product, and if this word is more sensitive, it is very uncomfortable. In this case, even if we think this is a small problem, you must also implement it before Modify it. If you think this problem will not give a significant impact on our customers, you can release it out.
debugging
How will developers debug this problem? Is there any tracking, screenshot, log, etc. to capture this bug, is included in your bug report? What is the location of the file and access to access?
evidence
What can I prove that this bug does exist? Are you sending a desired result and actual results? Is there a document to support your expectations? Since you have submitted Bug, it means that you think this is a bug, then you can provide you can provide and persuade others to recognize that this is really a bug information! This information may include operation guidance, documentation, prerequisites, and more, it is possible to be a crushing information that customers have previously fed back, or some of the standards in the software of competitors, or from the previous versions. And don't think everyone will look like you, don't expect others to have the same conclusion with you, and don't think you can think that this is a bug after three worships in the past. Consider all the reasons why you think this is a bug and is younger in your bug report. If you realize that others may think that it is not bug, you must do this.
Strengthen memory
You don't need to get the following focus every time you report BUG, you need to strengthen memory, then you can believe in hand when you report BUG. This is the smallest and most effective way to improve software quality consumption, even if it is likely to think it is. Usually a bad bug report is not because we can't write, but because we didn't consider and answer the correct question, this is the role of strengthening memory.
I don't know if you have found an interesting question, that is, the first letters of the words mentioned earlier are "Can Pig Ride?" This is short enough and relatively easy to remember. If you spend 20-30 minutes to see these 10 words and their meaning, it is estimated that it will leave a certain impression in your mind. If you think that 10 words are really difficult, then we can compress Let's remember that Pig is good. If you do it on these three points (precise, isolate, generalize), you are good enough, in most cases, it will be helpful when you do a bug report. template
A good BUG template helps us to confirm that we provide the correct information when reporting BUG and answered the correct problem. Some BUG tracking tools will automatically generate bug templates when discovering bugs. However, in this way, you still need to use "copy" and "paste" to put the information in your bug report, below is a bug template:
product detailed information:
Product name
Version, update history
System Detailed information:
Computer Type: Personal Computer Model, Main Machine Model, Operating System Version
RAM
hard disk
Peripheral accessories
Network connection method
Detailed configuration information
Brief description of the problem:
Detailed description of the problem:
Can you reproduce it?
Conditions and steps of reproduction:
Is this question have been effectively isolated and positioned?
Is there a summary of this problem?
Additional bug debugging information. (How to view system logs, screenshots, etc.)
Effective BUG reports, in a lot of cases, not all, but by answering the correct question to get a valid report. Here 10:
l Condense
l Accurate
l neutralize
l precise
l isolate
l generalize
l Re-create
l Impact
l Debug
l evidence
A quick list is provided to ensure that you really answer the correct question and if this will be made to your project or even the entire company you have even.
Bug title
Bug's title is a strong communication tool between the project team members. In many cases, people who can do decisions will not look at the bug's description, but only check the headline of the bug, then Just conclusion. The usual product manager, Team Leader has other managers who will only pay attention to the headline of the bug.
The header of the bug must be short and the accurate information is required to describe and communicate. Because of the length limit, this summary is generally shorter, using some abstracts that do not cause ambiguity, better syntax and sentences. Because many users are accustomed to searching with keywords, it is necessary to use some refined key words in the bug's title, like hang, abnormal abnormality, spelling errors, etc. are more effective and powerful search critical. word. If the length allows, it is necessary to add five W (Why, WHEN, WHO, WHERE, WHAT) of the bugs, etc.
Some bug tracking tools will automatically describe the bug's bug's bug's headline, never use such default headings, as well as special and accurate. For example, the title below does not provide sufficient information.
Title: An error occurred while saving and recovering data members.
A better title may be like this: In the WinNT environment, XYZ's saving and recovery data failed, and the data is lost. Usually in the bug's title you will not get any information you want, the following is a few points that should pay attention to the BUG title:
Simple, clear instructions (can not just say a problem)
Recommendation (if the length is allowed):
l use meaningful words
l Describe the environment and impact
l Answer 5W1H problem
l use shorthand
l Relative to the description, the syntax is not very important
l Do not use the default title provided by the test tool
to sum up
In order to find and discover problems in software, the test will cost a lot of time. Once discovered, it is necessary to try to use the smallest price to make this problem to be resolved. Make sure the Bug report includes the necessary appropriate information than superb writing skills.
Not all people will complete the bug's report, and many tabs typically rely on the bug's title to help them make decisions, so describing your bug titles with exact languages.
The better your bug report is written, the less the time to modify this bug, the less time is relatively. Your credibility and product contribution will also get a good improvement, because your bug report is good enough and can trust, and other testers will work accordingly.
reference:
REX Black, The Fine Art of Writing a Good bug report, http://www.rexblack.consulting.com
