In the previous articles, we all discussed the cases, design methods and tools of test case design. In this article, let's talk about bugs in programs.
The so-called "(Bug)" refers to the hidden errors or defects in the program.
As early as in the appendix of the software testing work cycle, we have explained the source of the bug, click the link to view it.
Bug records should basically include:
Bug number: the unique id of the bug, so as to find the bug as soon as possible. ※.
Bug title: bug summary, explaining the general content of the bug. ※.
※bug severity, priority: as the decisive factor of whether the defect is repaired or not, and the priority of defect repair. ※. ※.
Bug generation module: record the module to which the bug belongs, which is convenient for developing and locating the problem. ※.
Version corresponding to bug: the software version corresponding to bug, which is convenient for subsequent statistical archiving and development positioning problems. ※.
Bug description: the environment, detailed steps, expected results and actual results of the bug. ※.
Attachments: including but not limited to screenshots, logs, videos, sample files and applications. It is also convenient to reproduce and solve defects. ※.
The above are the necessary conditions for reporting bugs (creating bugs), and we will fix and retest bugs later. In order to record the follow-up work, bugs should also include:
※bug status: startup, being fixed, being fixed, being tested, being tested, passing/failing the test, being closed, etc. This will be mentioned in subsequent bug cycles.
Bug fixer: Bug fixer. ※.
Bug retest person: Usually, the person who reported the bug will be returned to whom for testing, but in some cases, for example, if the bug reporter has accumulated too many tasks, it will be assigned to others, so the person in charge of bug retest will usually be recorded. ※.
Bug correction description: written by bug reviser, explaining the cause of the bug, correction ideas, etc. ※.
Description of ※bug re-examination: The re-examination personnel will write and explain the re-examination process and results. ※. ※.
※bug Remarks: Notes to record some extra information.
As the saying goes, everything has its priorities. Life is like this, so is work. Software defects are not equal to. According to the current environment, we classify different bugs according to their severity and priority, and developers can decide whether bugs should be modified and the order of bug modification ("priority of bugs") through this classification.
The specific division method varies from company to company, but the general principle is basically the same:
Severity: indicates the severity of the software defect, and the possibility and influence of the user encountering the defect. ※.
Priority: indicates the importance and urgency of fixing defects. ※.
Below we give the common methods to divide the severity and priority. It should be noted that this is just an example. The division method of each company is different, and there are some changes for your reference.
Severity:
A system crashes, data is lost, data is destroyed, security is destroyed, core functions are not realized (for example, QQ has no chat function), and the realization of main functions does not meet the requirements (for example, QQ chat function can only send messages but not receive messages).
B. Operation error, wrong result, failure to realize a certain point of the function module (for example, QQ has no message reminder), and compatibility error.
C minor problems, spelling mistakes, ugly UI layout, and rare bugs in certain situations.
D. Some suggestions on ease of use (which can also be classified into three categories)
Priority:
A. immediate maintenance prevented further testing.
B.it must be fixed before the product is released.
C. If time permits, it should be repaired.
D. it can be fixed without affecting the release.
Thirdly, the above list is just an example, and the specific defect division rules should be formulated according to actual projects and application scenarios. For example, we usually think that the defect that destroys user data is more serious than simple spelling mistakes. But what if data corruption only happens in rare cases where users rarely use it, and spelling mistakes cause problems for all users to install software? At this time, the priority and severity of data corruption and spelling errors are self-evident, and the severity and priority of spelling errors must be higher than data corruption.
Severity and priority are extremely important for people who review defect reports and decide which software defects should be fixed and in what order. If a programmer is ordered to fix 10 defects, he should start with the defects with the severity of 1 and the priority of 1 instead of fixing simple defects first.
Similarly, two project managers-one managing advertising portal/game software and the other managing hospital detector/performance testing software-will make two choices when dealing with the same problem, such as beautiful pages. In the former, the priority can be 2, while in the latter, the priority can be 3 or 4.
Ok, that's all for today. If you have any questions, please leave a message and communicate with me in time, and I will reply to you as soon as possible! Thank you ~ See you next time!