Impact analysis
Impact analysis is another software development tool that is used by programmers to make testers' testing life easier . The main idea of impact analysis is an indication of the affected places in a project when developing new or changing old functionality. During development, there are often situations where you make changes in one place, and this affects either the entire project or several places in the project. With such changes, it is difficult to remember and test all the necessary places, especially if they are not covered by tests. As a result of this, after the next release, customers begin to complain that something is broken or not working.
Imagine that we have a well-coordinated team where programmers help testers, and testers programmers (and this, unfortunately, not everywhere) and all the efforts of the team are aimed at improving the quality of their software product. And after introducing or changing the new functionality, the programmer no longer simply commits his changes to the repository, but also opens the Excel document (in our project we adapted for this Excel, but you can also find something else) in which he points out which places of the project need to test. We illustrate it this way:
At the very beginning, a multi-colored list of priorities is seen - the importance or complexity (as it is convenient for someone) of what will be tested. Vertically we enter the brief names of the functionalities, so that it is clear to everyone what is being said. Horizontally we write out the places in the project that were affected by changes in functionality.
Next, we begin to paint the table, it is advisable to agree in advance on the criteria of importance, so that there are no questions about the color delivered, and it is even better to put colors together with those who developed and those who will test. Because the programmer does not know how long it will take the tester to check the changes, and the tester does not know how long it will take the programmer to correct the error.
')
Filling the table should be done with the programmer, because The tester does not know which tabs a particular change might have affected. The programmer can see by code all places of use of the method / class changed / implemented by him.
Plus, the impact analysis is that having returned to testing the functionality after a long period of time, or having given testing to the hands of a new person, you just have to look at the table in which priorities will be set. And it will not be necessary to spend already precious time for memories of where you need to test and where to look in the first place.
Another Excel allows you to put a comment on the cell, indicating the login of the one who set. In the comment, you can add either the ticket number or a wish for testing or insert a link to a useful document in this place.
Imagine that we have a well-coordinated team where programmers help testers, and testers programmers (and this, unfortunately, not everywhere) and all the efforts of the team are aimed at improving the quality of their software product. And after introducing or changing the new functionality, the programmer no longer simply commits his changes to the repository, but also opens the Excel document (in our project we adapted for this Excel, but you can also find something else) in which he points out which places of the project need to test. We illustrate it this way:
At the very beginning, a multi-colored list of priorities is seen - the importance or complexity (as it is convenient for someone) of what will be tested. Vertically we enter the brief names of the functionalities, so that it is clear to everyone what is being said. Horizontally we write out the places in the project that were affected by changes in functionality.
Next, we begin to paint the table, it is advisable to agree in advance on the criteria of importance, so that there are no questions about the color delivered, and it is even better to put colors together with those who developed and those who will test. Because the programmer does not know how long it will take the tester to check the changes, and the tester does not know how long it will take the programmer to correct the error.
')
Filling the table should be done with the programmer, because The tester does not know which tabs a particular change might have affected. The programmer can see by code all places of use of the method / class changed / implemented by him.
Plus, the impact analysis is that having returned to testing the functionality after a long period of time, or having given testing to the hands of a new person, you just have to look at the table in which priorities will be set. And it will not be necessary to spend already precious time for memories of where you need to test and where to look in the first place.
Another Excel allows you to put a comment on the cell, indicating the login of the one who set. In the comment, you can add either the ticket number or a wish for testing or insert a link to a useful document in this place.
Source: https://habr.com/ru/post/144609/
All Articles