1. The impact of BUG
Spiritual destruction
Who would be willing to get the title of trash team?
BUG has infinite vitality. You will be very pessimistic and think that you are powerless. This emotion will aggravate after long hours of work.
Everyone is tired of dealing with the same problem repeatedly, and testers are tired of the long list of bugs, and mental pressure is increasing day by day.
Low productivity and low product quality consume a lot of resources. Sometimes the management did not realize what was wrong. In order to ensure the final delivery of the project, they sent a steady stream of new people to the project. The training was unable to follow up, which eventually led to the collapse of the entire product development.
Loss of image
If there are major bugs in certain products of certain companies, it will inevitably reduce the company’s image. At least we have reason to believe that the quality of the company’s products is unstable.
E-commerce can better reflect the image. If the website takes a long time to respond to customer service, or if there is a phenomenon of lost or disordered orders, such a website will be quickly abandoned by customers, and it will be difficult for customers to turn back once they leave.
The consequences of the loss of image are huge, the product is not recognized by the market, and even the company is no longer recognized by the market.
Loss of wealth
The development of the product requires capital, and the operation of the company requires capital. A bad market image requires the company to spend more money to restore its reputation.
Post-maintenance of BUG software products is also a big problem
2. The generation of BUG
Misunderstanding of communication
Shy. When communicating with customers, I always use a small voice to explain my views, and the expression is not strong enough; or sit quietly in the corner of the meeting room, watching the heated discussion of others without any thoughts.
timid. The project participants lacked understanding of the customer, which led to a blind mentality of following. When communicating, I just listened and never dared to refute or put forward opposite opinions.
rely. Some project participants think that when communicating, only one person needs to take notes of the meeting, and they always find a kind of emotional support.
contempt. Project personnel with professional knowledge do not pay attention to what the customer said, or think that what the customer said is simply a fantasy without scientific basis.
forgetful. I am confident that I can remember all the discussions in the meeting without taking notes. As a result, I forgot some of the main points and precautions in the actual design or development process.
misunderstanding. This is a common phenomenon among human beings.
Everyone has different levels of cognition, their own knowledge, and principles of dealing with things. This situation will inevitably occur. This situation can be avoided through mutual training and effective communication.
Software complexity
Programmer's error
Too tired. Let the programmer continue to develop and be exhausted to complete a certain task. At this time, he believes that rest is more important than coding quality.
Unruly. Programmers describe a beautiful utopia according to the blueprint in their minds, or use self-encoding formats as they please, completely disobeying the development guidelines of the project.
Too enthusiastic. Programmers often make such mistakes, without rigorous verification and overall consideration, arbitrarily modify the design and think it will produce better results.
Absent-minded.
Demand changes
Customers do not understand the consequences of changes in demand, and even if they do, they will insist on doing so. And in the eyes of customers, they only need to see the change, but never consider the extra working time required for the change.
The consequences of changes in requirements may cause redesign or schedule adjustments, completed work, redo, or completely abandoned, and the entire project environment may be changed as a result.
Frequent small changes or several major changes, the known or unknown dependencies between the various parts of the project will affect each other, leading to more problems.
Changes in demand have increased the complexity of project operations, created a large number of uncertainties, and may also undermine the enthusiasm of participants. A project or product whose requirements change frequently has no test value.
Time pressure
Time is a precious resource.
All software project time needs to be accurately estimated. But mixed with the unstable factors of prediction and guessing, when the deadline is approaching and the critical moment arrives, mistakes will follow.
Poor documentation
Poor or poor documentation makes code maintenance and modification extremely difficult, resulting in many errors.
The way to distinguish professional implementers is not based on his years of coding experience, but on whether he has a good habit of documenting first and implementing later.
Documents represent a special kind of memory, and its existence is not good for people or themselves.
Software development tools
Always hope to avoid the emergence of BUG through more advanced tools, which suffers from the typical silver bullet syndrome.
Development tools may enable us to get rid of certain problems and improve work efficiency. In fact, modern development tools have no significant impact on the overall software quality, especially the reliability.
3. How does the bug penetrate the test
Too costly
Formal software companies will introduce QA to carry out a full range of quality assurance work for the entire process of the project. However, the implementation of QA requires the invocation of many resources. For example, to check and review the standard artifacts output in the requirements phase, high-level analysts are required to join, but usually their time is very little precious, and they will not have too much energy to take care of this matter. .
In the design and implementation phase, with the involvement of a large amount of review work, all participants in this phase have to spend more time and energy to participate.
These forms of inspection, review, and testing prolong the development process of the entire project, and these additional working hours will directly become additional costs, greatly increasing the cost of the entire project.
Market decision
Even if the tester finds a bug in the product, the company will feel that fixing the bug will extend the release time of the entire product, may miss the peak sales season (may be from May to October each year), and disrupt the entire company's targeting of the product According to the sales plan, the software was sold after confirming that the bug in the product was not very serious. However, if this is a management and control software system for aerospace, medical, and stock trading, such as with a BUG, the consequences of publishing are very serious, but for some industries, such an approach is feasible.
Time is running out
Testing takes a lot of time. So far there is no automated testing tool that can test a set of software products comprehensively and efficiently.
The test project manager was overly optimistic after receiving the test task and did not consider the risk of the task.
Developers overestimate their own abilities, thinking that all BUGs are trivial and easy to fix. He let the testing work and coding work at the same time, so there is no way to ensure the correctness of the test. And when time is pressing, most testers just choose a few obvious program paths to test or input incomplete test data, which causes a lot of bugs and omissions.
On-site evidence
Sometimes this kind of problem is encountered, and a BUG is found but I don't know how to show it clearly. It is a shame for the testers to fail to provide sufficient evidence reports to the developers. Developers will also ridicule what the testers do based on such reports.
The reproducibility of the BUG is closely related to the cause of the BUG.
The reproducibility of the BUG also reflects the testers' familiarity with the software system.
The reproducibility of BUG is also reflected in the sequence of operations.
Overconfident
Developers are very insincere testers, they always say "I must have done nothing wrong" or "Impossible, it runs well on my machine". Sometimes project managers are also very arrogant and trust the performance of team members too much and ignore the complaints of testers or customers.
The Titanic disaster fully embodies the confidence of human beings. We have enough watertight cabins that will not sink even if we break 5 ships.
There is no detailed test plan, no rigorous testing behavior, and no longer pay attention to every small link, so the BUG will slip away quietly.
Fuzzy submission
test environment
Lack of necessary testing tools and equipment. In a relatively large website, the performance of the system under normal load conditions is very important. If the tester does not have an effective testing tool or necessary hardware equipment, it is difficult to simulate and reproduce the environment of the system load.
The necessary system configuration is missing. If it is a program developed in Java, we may verify its correctness and stability on a variety of operating systems.
The necessary test cases are missing. A good test model can reduce more BUGs, and can also find more potential BUGs. A good test case is not only a combination of a series of test methods, but its greater use lies in the comparative analysis of historical accumulated BUG records.
4. Types of bugs
BUG in the demand stage-source:
Ambiguous demand
Ignored demand
Conflicting needs
BUG in the analysis and design stage-source:
Ignore the design
Confusing design: This kind of situation occurs in the situation where the two design properties are completely opposite. If in the actual system, a certain block address is not allowed to be accessed by multiple threads, but the solution is designed to be multi-threaded, then BUG will be generated at this level, which will seriously cause the entire system to crash.
Fuzzy design: The reason for the fuzzy BUG is that the designer does not have a clear understanding of the requirements, or the requirements themselves are vague.
BUG in the realization phase-source:
Missing features
Memory overflow: It belongs to a relatively serious type of software BUG. For example, the software executes some instructions that forcibly write data to the protected address of the operating system, resulting in a complete breakdown of the entire environment; another example: division of a value by zero causes a stack overflow
Other implementations: It is difficult to locate the type of errors that occur. For example, during the productization stage, testers or end users put forward some suggestions to improve the efficiency of the program. Of course, developers do not completely deal with these problems, but these suggestions will become one. A special BUG type is kept in the project database.
BUG in the configuration phase
The BUG in the configuration phase is the most dangerous, and it is often reflected in the software delivery or the final system test.
The cause of the BUG in the configuration phase is complicated. The typical one is that the old code covers the new code; or the code on the test server is inconsistent with the latest code version of the implementer's machine. These circumstances caused the same problem to occur when the error code was modified and the regression test was repeated after a period of time.
The BUG solution in the configuration phase is also very simple. The project team can appoint a dedicated person (set member) for configuration and integrated management. The set member ensures the correct integration of the entire system and publishes the latest code to the test server or client server. At this stage, the QA (Quality Assurance) department is responsible for supervision and control, stipulates the integration time interval and the best integration time, and maintains a unified list of project team integration personnel and integration time.
Short-sighted future bug
Many software bugs are caused by the short-sightedness of designers or implementers. A well-known example is the "millennium bug" problem.
Other short-sighted BUG examples include our previous ID number. The original 15-digit number does not meet the design requirements of one person for one number at all, and the phenomenon of duplicate codes is quite serious. So there is an 18-digit number.
Another example: China Mobile has developed the 134 number. Now there is number 159 again.
BUG of static documents
The definition of a document BUG is very simple, that is, vague descriptions, incomplete descriptions, and outdated documents are all document BUGs.
Explain that vagueness refers specifically to the lack of sufficient information to determine how to handle things correctly. For example, the design document describes the calling of class instance methods, but does not specify the boundary conditions and special calling sequence.
Incomplete description means that the document information is not enough to support the user to complete a certain task. For example, a certain operation of a certain set of software has specific pre-conditions, and the customer does not obtain relevant information about the pre-operation from the document, and the customer believes that the software has a BUG.
The expired document itself is wrong and cannot be remedied. This phenomenon often occurs in the later modification of the system function without updating the corresponding document in time, resulting in inconsistency of the document.
5. The life cycle of BUG
BUG initial state (Unconfirmed&New state)
BUG allocation state (Assigned state)
BUG reallocation state (Reassigned state)
BUG repair state (Resolved&Fixed state)
BUG verification status (Vertified&Fixed status)
BUG reopen state (Reopen state)
BUG closed state (Closed&Fixed state)
6. 5 typical processes of BUG life course
(1) BUGStart-->BUG initial state-->BUG allocation state-->BUG reallocation state-->BUG repair state-->BUG verification state-->BUG closed state
The tester finds the BUG and marks the BUG as Unconfirmed&New status. In the next step, the tester removes the registration error of the BUG and sets the BUG to the Assigned status. Implementation personnel received the BUG notice
Carry out the BUG confirmation. After the confirmation is successful, the BUG status is set to the Reassigned state. When the implementer fixes the BUG, the BUG is set to the Resolved&Fixed state. The tester confirms the bug after the implementer is repaired
Recognition test, if the BUG is correctly fixed, then its state is set to Closed&Fixed state, which means that the entire life cycle of the BUG is over
(2) BUGStart-->BUG repair state-->BUG verification state-->BUG closed state
After the regression test, if part of the registered BUG reappears, the tester can directly transfer the registered BUG in the Closed&Fixed state to the repair process, and wait for the implementer to fix the BUG and set the BUG to
Resolved&Fixed status. The tester conducts a confirmation test on the BUG repaired by the implementer. If the BUG is correctly repaired, its status is set to the Closed&Fixed state, which means that the BUG is complete.
End of life cycle
(3) BUGStart-->BUG initial state-->BUG allocation state-->BUG redistribution state
The tester finds the BUG and marks the BUG as Unconfirmed&New status. In the next step, the tester removes the registration error of the BUG and sets the BUG to the Assigned status. Implementation personnel received the BUG notice
Carry out BUG confirmation, after the confirmation fails, the BUG status is set to the Reassigned status and sent back to the BUG initial stage
(4) BUGStart-->BUG initial state-->BUG allocation state-->BUG redistribution state-->BUG repair state-->BUG reopen state
The tester finds the BUG and marks the BUG as Unconfirmed&New status. In the next step, the tester removes the registration error of the BUG and sets the BUG to the Assigned status. Implementation personnel received the BUG notice
Confirm the BUG. After the confirmation is successful, the BUG status is set to the Reassigned state. When the implementer fixes the BUG, the BUG is set to the Resolved&Fixed state, but the implementer finds the BUG and other implementers
The BUG is related, which may cause this repair to be invalid, so the implementer sets the BUG to the Reopen state and sends it back to the initial stage of the BUG
(5) BUGStart-->BUG initial state-->BUG allocation state-->BUG redistribution state-->BUG repair state-->BUG verification state-->BUG reopen state
The personnel receives the BUG notification to confirm the BUG. After the confirmation is successful, the BUG status is set to the Reassigned state. When the implementation personnel fix the BUG, the BUG is set to the Resolved&Fixed state. Tester-to-implementer
After the repaired BUG is confirmed and tested, after the verification is successful, the tester suspects that the BUG is not really repaired, and the BUG is set to the Reopen state and sent back to the initial stage of the BUG
7. Keyword of BUG circulation status
Unconfirmed. This bug was discovered recently, and no one has confirmed whether it really exists. If other testers encounter the same problem, they can mark the bug as New, delete the bug, or mark it as closed.
Newly added (New). This bug was recently added to the bug list by testers, it has been confirmed to exist and must be modified. It is about to be allocated. If it is allocated, it can be marked as Assigned. If it is not allocated, it will retain the New mark or mark it as Resolved.
Confirm the assigned (Assigned). The tester assigns the task of repairing the BUG to the specific implementation personnel. If the BUG does not belong to the scope of the assigned implementation personnel, it can be set to Reassigned and wait for the relevant modification personnel to be reassigned.
Reassigned. The BUG does not belong to the scope of the assigned implementation personnel, and can be set to Reassigned and wait for the relevant modification personnel to be reassigned.
Need help (Needinfo). The tester or the implementer cannot accurately locate or describe the discovered bug, and requires the assistance of the relevant implementer to understand and fix the bug more deeply.
Repeated (Reopened). This BUG is not the first time it has been discovered, it can be marked as Assigned or Resolved.
Resolved (Resolved). Implementation personnel modify the BUG assigned to themselves, and modify the status after the modification is completed.
Reopen. When the implementer finds that some BUG has relevance, even if the BUG is correctly fixed, it will be sent to the initial state and wait for the return to confirm again. Or the tester finds that the BUG has not been really modified, reset the state.
Being verified (Verified). The tester verifies the BUG marked as Resolved.
Safely closed (Closed). The BUG has been completely resolved.
8. BUG resolution keywords
Has been fixed (Fixed), the BUG has been correctly fixed, and has been confirmed by the tester.
It cannot be repaired (Wontfix), the discovered BUG will never be repaired, or the BUG involves too wide a committee to decide.
Resolved in the next version (Later), the discovered BUG will not be resolved in this version of the product, and will be fixed in the next version.
Unsure (Remind), the BUG found may not be resolved in this version of the product, or it may be.
Duplicate, the BUG found is a duplicate of an existing BUG.
Incomplete, the bug cannot be reproduced by all methods, there is no more clue to confirm the existence of this bug, even if you look at the source code of the program, it is impossible to confirm the occurrence of this bug.
Test error (NotaBUG), the BUG report has an error, and the correct software process is reported as a BUG.
Invalid (Invalid), the problem described is not a BUG, it belongs to the tester's input error, and this item can be used to cancel it.
Problem file (Worksforme), all attempts to reproduce the BUG are invalid. If more information about the BUG appears, the BUG will be reassigned, and now it is only included in the problem file.
9. Severity level of BUG
Critical, can cause irrelevant system software (or the entire system) to be damaged, or cause serious information loss, or introduce security vulnerabilities to the system where the software package is installed.
Grave makes the package impossible or almost unavailable, or causes data loss, or introduces a security hole that allows intrusion into the user's account of the package.
Serious, the package violates the "must" or "necessary" regulations, or the package maintainers and testers believe that the package is no longer suitable for release.
Locked (Blocker), this bug hinders subsequent operations and needs to be eliminated immediately or as soon as possible.
Important (Important), the error affected the usability of the package, but it did not make everyone unavailable.
Normal (Normal) is the default and is suitable for most errors.
Minor, the error will not affect the use of the software package, and it should be easy to solve.
Trivial, the error is not important. It mostly refers to the spelling of characters on the appearance GUI and does not affect the entire project.
10. Priority of BUG handling
Fix it immediately (Immediate), this BUG has hindered development or testing and needs to be modified immediately.
Immediately repair (Urgent), this BUG hinders part of the software application, if it is not repaired, it will hinder the implementation of the following plan.
Fix it as soon as possible (High), the real thing is not very serious, fix it before the version is released.
Normal repair (Normal), there is sufficient time to repair this problem, and this BUG has little impact on the current system.
Consider repairing (Low), it is not a critical BUG, you can consider repairing when time permits.
Written at the end,
if you are interested in python automated testing, web automation, interface automation, mobile terminal automation, interview experience exchange, etc., you can follow the WeChat official account: [Programmer Erhei] to get an interview with a software test engineer data! My learning exchange group: 785128166 There are technical experts in the group to exchange and share~
If the article is of interest to you, please reach out to make a fortune and give me a like. Thank you for your support. Your likes are my motivation for continuous updates.