Software testing life cycle
- demand analysis
- Test Plan
- Test design, test development
- Test execution
- Test Evaluation
How to describe a BUG
1, was found in versions
developers need to know the version of the problem, to be able to obtain the corresponding version of the code to reproduce the failure. And the version of the logo is also conducive to statistics and analysis of the quality of each version.
2, the problem of the environment
environment is divided into hardware and software environment, if a web project, need to describe the version of the browser, the client operating system, if it is app items, need to describe the model, resolution, operating system version. Detailed description of the environment is conducive to locate the fault.
3, the steps to reproduce the error
description of the shortest steps to reproduce the problem.
4, describe the expected behavior
to let developers how to guide is correct, especially the user's point of view behavioral description of how the program.
5, description misconduct
describing the error phenomenon.
BUG level
-
Collapse
impede the development or testing of the issue ; cause system crashes, freezes, infinite loop , resulting in data loss database, the database connection error, major loss of function, lack of basic modules and other issues. Such as: Code error, infinite loop, a database deadlock, important level menu functions can not be used, etc. -
Severe
primary function of the system partial loss , calling database stored error, loss of user data, a function menu can not be used but does not affect other functional tests. Functional design and demand serious discrepancies, the module can not start or call a program restart, automatic withdrawal, call the conflict between the associated procedures, security, stability and so on. Such as: data storage software error, loss of function requested by the user in the database, the program interface error, statistical numerical errors -
General
features not fully realized , but does not affect the use , defective function menu but does not affect the stability of the system. Such as: operating for a long time, a long time queries, format error, boundary condition error, there is no confirmation box to delete a database table, field too much, etc. -
Secondary
function is not fully realized, but does not affect the use of a flaw but does not affect the stability of the system menu. Such as: operating for a long time, a long time queries, format error, boundary condition error, there is no confirmation box to delete a database table, field too much, etc.
BUG developers because of a conflict and how to do
And ultimately successful on-line developer of a software project, and ultimately testers. They are the backbone of the software project teams. The work of the two complement each other.
Due to objective reasons profession, there are testers and developers professionally contradiction, conflict is a normal thing. But the common goal is the same, is to realize the needs of users, to ensure the high quality of the software delivered to users.
So:
1. First check itself is not clear whether the bug description
2. give the reason they think is a bug:
- On the demand side analysis, functional implementation and whether the demand is consistent, if not explicitly stated requirements, you can find product manager confirmed
- From a user perspective, this development is realized, it will make the user feel unreasonable or experience is not good.
3, BUG grading to be well-founded
when grading BUG, BUG reference not only to the level, but also consider whether BUG will affect the process, often the user's level and our BUG is a difference
, to be given from the user's point of view consider positioning level.
4, improve their technical and business level not only to ask questions, it is best able to propose solutions
5, after several rounds of communication, but developers still refused to accept. At this point you can initiate Bug review.
-
Decide how to deal with Bug.
-
Analysis of defects, identify prevention
measures
