The severity is assessed by the tester and is generally ranked on a scale of 3 levels. The severity of the defect is an element that makes understanding the impact that the defect can have on the systems and the business easier. If the bug found is reproducible, it should be mentioned along with its occurrence (Does the bug happen every time?).
In order to facilitate the understanding of the defect by the teams in charge of making the amendments, it is important to document the description of the expected behavior versus the observed behavior during the testing phases. When this part is well documented, there will be no going back and forth between the testing teams and the teams in charge of carrying out the necessary corrective actions and the bug fixing turnaround time will be faster. The description thus has to contain all the necessary steps to reproduce the bug, as well as the step at which the defect was spotted. This will cause delays in the bug fixing process. If a developer investigating the bug can’t understand its details, it is very likely that the report will be sent back to the tester to be completed with more explanations and details. The nature of the defect has to be clearly explained. Which devices have been affected by the bug? It will also be required to provide the version of the product and database tested, and if the tests have been carried out in production, pre-production or during acceptance phases. It is necessary to give as much detail as possible on the environment, the context, in which the bug happened: the browser used and its version, the OS used and its version, the device brand, the model… It gives a quick overview of the issue encountered during the tests and is the equivalent of the subject of an email. The summary is a general description of the bug.
0 kommentar(er)
