May 19, 2018 at 19:06Defect Management Style
As a tester, I saw many defects, the reproduction of which made me difficult. I want to share some practices for processing defects - I hope that this will help to slightly improve someone's life.
When participating in software development, I saw that when writing code, programmers usually set the standard for code design (codestyle) - following certain practices designed to improve the life of programmers. My role in software development was testing. As one of my duties as a tester, I saw the production of information about the quality of software. As one of the classifications, this information could be divided into positive and negative. The positive information usually consisted in the fact that the expected behavior coincided with the real one, and the test results could be provided in the form of data in the test report (feature 1 - works, scenario 2 - works, etc.). But the negative information is most often produced and framed in the form of defects. (of course,
I met within the projects the maintenance of a knowledge base (not only defects), oriented to ensure that it is "once-and-in-time". Just like the road workers - to hand over the object, and then whatever happens.
I would like the quality assurance processes to be conducted with the expectation that after the product was transferred to release, it could be accompanied, while retaining good memories of the development team.
Typically, a defect includes:
1. Name
2. Criticality
3. Description: Information about the stand, playback steps, actual and expected result.
Depending on the bug tracking system, there may be other fields.
About what the defect consists of and the basic rules of registration, such as asking the name of the defect that answers the questions “What, where, when?” On open spaces of the Internet, including on the habr itself I met many articles. Here I want to share my own experience.
Not only programmers and testers can look at defects, but also other people who are interested in releasing and selling the product. For example: the director of the development center, the head of the sales department, the designer of user interfaces, members of the team developing another product that is integrated with the test person. And they don’t have time to study the details and analyze the effect of the defect on their area of responsibility. They do not have to be familiar with all the technical details of your product.
It should be guided by the fact that by the name of the defect it is possible to understand what functional it refers to, using the search in the documentation or in the knowledge base.
Please note that when making changes to the product, the technical description may change, but the defect usually continues to manifest itself.
And so as not to distract you from current affairs. Distraction from current affairs sometimes requires a lot of effort. And it is more profitable to spend a small amount of your time on preventing distractions than to constantly be distracted later.
When the project is small and you are the only tester (perhaps combining other responsibilities, for example, a programmer), defects can be made out as you like. But when you work in a team, a different approach is required. When you live alone in the house - you can not wash the dishes, do not put things in their places, etc. And when you live in a large family, you should respect that other family members will want to see cleanliness and order.
Regarding the stand:
It is worth considering that occasionally defects are corrected in the conditions of a hard deadline, when many people eagerly crave for their correction or double-checking, every minute goes to the account of gold - and it is worthwhile to make sure that time does not waste in vain due to careless design.
Before you start a defect, it is advisable to reproduce it, localize the conditions for its reproduction and discard the excess. If there is an assumption that some factor does not affect reproduction, it is better to prescribe it directly and not to expect that this information will be transmitted telepathically.
Just as the instruction manual for any device should have a sufficient amount of information, taking into account that it can be used by someone other than the manufacturer of these devices.
Keep in mind that team members in the project change periodically. According to my observations, people are working on the same project, without changing it and not switching to others, about 2 years. The effect of the truck should be considered . It also happens that there are several testers in a company, and it is worth considering that when leaving on vacation other testers can double-check this defect.
Ideally, a defect description can be made focused on those who work with the product for the first time and have only documentation at their disposal.
It should be borne in mind that even after closing the defect, someone may need it. The estimated number of prospects is 2 years. (Estimated calculation).
For example, when workers change windows in the stairwell, it happens that they save time and effort in taking out the trash. It seems that the garbage does not interfere with the passage, residents walk quietly. And resources are saved. BUT: after a while there comes a moment when the garbage begins to interfere. And if there is a fire (release or something else), then the trouble begins.
For example, some old defect pops up among users (or there will be a new one, the symptoms of which will coincide with the old), because of this, the company suffers damage. Begin to figure out the details. And if the defect was framed haphazardly, then the owners will clearly not be delighted with the work of the tester.
Many times I noticed that testers when describing a defect are guided by the fact that it will be fixed by the team on the same day. With approximately 80% of defects this is what happens - they are fixed on the go and few people need them. But here about 20% of defects continue to exist, and about half of the remaining ones - over a sufficiently long period of time. During this time, the composition of the team working on the product undergoes changes. And when new team members begin to work, the analysis and reproduction of existing defects begins to take a very long time. It may take a lot of time to update each defect without an adequate description, even knowing the product at the documentation level.
I will give a rough calculation. I remember that in an 8-hour working day I was able to update about 5 defects without a description. If testers spent an additional 5 minutes on each defect when making defects, making the description more detailed, then an additional 500 minutes would be spent on installing 100 defects = about 1 working day. Of these 100 defects, about 20 will remain unclosed for a sufficiently large amount of time. In the calculation of 5 defects / day, they can take about 4 working days to be updated.
When 1-2 programmers are working on a project, usually everyone fully knows all the functionality. But when, say, 10 programmers are working on a project, then everyone knows only the functionality in which he made changes. And do not force programmers to study the behavior of unfamiliar functionality for them. They have more than enough tasks to implement the new functionality.
It often happens that important details of a defect are identified after its design. They are added somewhere in the comments to the defect. It is advantageous to update the information on the steps of reproduction in the description of the defect. Especially if the defect is related to several teams. Do not force everyone to reread the comments and delve into them.
For example:
1
- screenshot of the login window.jpg 2 - screenshot of the error in the console.jpg
3 - archive with downloaded files.zip
Subsequently, during discussion, attachments can be added, their number can grow to tens. It is convenient to operate with an indication of the attachment, for example: in screenshot 15 ... use the script from attachment 7 ... see the message in the archive log 25.
If information on several similar errors is collected in one defect, for example, the description contains: The
error is displayed in browsers:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
After working on the defect, it is revealed that the defect is only partially corrected, then it’s advantageous Update the information in it without deleting the old one, but using the crossed out font:
Error after correction 01.01.2018 is displayed in the browsers:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
“What is good for a Russian is death to a German.” It is worth setting common criteria for determining the criticality of defects for testers in the company. It may turn out that everyone will consider that his defects should be fixed in the first place and not realize that at the same time resources will not be allocated to correct more critical defects.
Timeliness of institution of defects is an important matter. The faster they get started, the sooner and better they will be fixed. And the less likely it is to miss something critical in production. After viewing the defect by other team members, it may appear that the criticality is higher than it seems at first glance.
As one of the options - if a defect is discovered during a meeting or other work that cannot be distracted from, you can make a note about it on a piece of paper and write it at the end of the day.
You probably do not ignore the small garbage when cleaning the house, even if it does not interfere much. (Of course, there are those who do not maintain cleanliness and order in the house, but do not focus on them). Similarly, do not ignore minor defects. If internal agreements do not allow you to enter them in the bugtracker, then you can fix them in some other way, for example, on some page or in letters by mail.
When the product is small, minor defects are not very noticeable. But when the product becomes large - the scenarios become more capacious - the presence of minor defects begins to pester.
One can draw an analogy: imagine a small village, for example, a village of two streets, at the intersection of which there is one small hole with mud. It seems like there is a pit at each (single) intersection, but moving around the village is easy, just bypassing this pit each time. And she doesn’t bother anyone. Time passes. The settlement increases to the city of a millionaire. At each intersection, a hole in the mud. If you travel to such a city to work through a part of the city, then moving around a hole at each intersection will become far from so comfortable. And there will be a great desire to move to another city or re-elect the city administration. Similarly with software products - it should be promoted that users had a desire to work in them, instead of a desire to delete.
Other team members also have defects. And they do not have to be familiar with the activities of the tester, they may have more than their own affairs. The defect base is one of the tester’s possessions, just as the code storage system is the programmer’s possessions.
If you, as a tester, see that the defect in your product is not brought up correctly, then you should correct it. Just as it is worth maintaining order in your home, folding things in their places if the guests put something in the wrong place.
PS Recently I started working at Modulbank and I plan to add these practices to existing ones.
Foreword
When participating in software development, I saw that when writing code, programmers usually set the standard for code design (codestyle) - following certain practices designed to improve the life of programmers. My role in software development was testing. As one of my duties as a tester, I saw the production of information about the quality of software. As one of the classifications, this information could be divided into positive and negative. The positive information usually consisted in the fact that the expected behavior coincided with the real one, and the test results could be provided in the form of data in the test report (feature 1 - works, scenario 2 - works, etc.). But the negative information is most often produced and framed in the form of defects. (of course,
I met within the projects the maintenance of a knowledge base (not only defects), oriented to ensure that it is "once-and-in-time". Just like the road workers - to hand over the object, and then whatever happens.
I would like the quality assurance processes to be conducted with the expectation that after the product was transferred to release, it could be accompanied, while retaining good memories of the development team.
Typically, a defect includes:
1. Name
2. Criticality
3. Description: Information about the stand, playback steps, actual and expected result.
Depending on the bug tracking system, there may be other fields.
About what the defect consists of and the basic rules of registration, such as asking the name of the defect that answers the questions “What, where, when?” On open spaces of the Internet, including on the habr itself I met many articles. Here I want to share my own experience.
1. The name should reflect the essence of the manifestation of the defect at the application level
Not only programmers and testers can look at defects, but also other people who are interested in releasing and selling the product. For example: the director of the development center, the head of the sales department, the designer of user interfaces, members of the team developing another product that is integrated with the test person. And they don’t have time to study the details and analyze the effect of the defect on their area of responsibility. They do not have to be familiar with all the technical details of your product.
It should be guided by the fact that by the name of the defect it is possible to understand what functional it refers to, using the search in the documentation or in the knowledge base.
Please note that when making changes to the product, the technical description may change, but the defect usually continues to manifest itself.
2. It is worthwhile to focus on the fact that when reproducing a defect, colleagues do not waste time doing thought-outs instead of their work
And so as not to distract you from current affairs. Distraction from current affairs sometimes requires a lot of effort. And it is more profitable to spend a small amount of your time on preventing distractions than to constantly be distracted later.
When the project is small and you are the only tester (perhaps combining other responsibilities, for example, a programmer), defects can be made out as you like. But when you work in a team, a different approach is required. When you live alone in the house - you can not wash the dishes, do not put things in their places, etc. And when you live in a large family, you should respect that other family members will want to see cleanliness and order.
Regarding the stand:
| It’s not worth it | Better to issue | Note |
|---|---|---|
| On my grandfather's computer in the village | Machine: CPU: AMD A4-6300, RAM: 2 GB DDR3, HDD: 500GB, screen 1024x768, OS: Windows 7 x64 | It is better to indicate exactly where the defect appeared. |
| At the testing stand of Chameleonov and Butterfly | Machine1: Windows 10, GCr 20.1 Machine2: Windows 10, FF 30.1 | At the stands, something often changes, and it is worth considering this. |
It is worth considering that occasionally defects are corrected in the conditions of a hard deadline, when many people eagerly crave for their correction or double-checking, every minute goes to the account of gold - and it is worthwhile to make sure that time does not waste in vain due to careless design.
3. The description of the defect must not contain non-relevant information
| It’s not worth it | Better to issue | Note |
|---|---|---|
| 1. Drink coffee 2. Open the logon page 3. Take a bath 4. Try to log in as user1 | 1. Open the logon page 2. Try to log in as user1 | Everything that does not belong to a defect should not be mentioned in it. |
Before you start a defect, it is advisable to reproduce it, localize the conditions for its reproduction and discard the excess. If there is an assumption that some factor does not affect reproduction, it is better to prescribe it directly and not to expect that this information will be transmitted telepathically.
4. The description of the defect must contain sufficient information to reproduce
Just as the instruction manual for any device should have a sufficient amount of information, taking into account that it can be used by someone other than the manufacturer of these devices.
Keep in mind that team members in the project change periodically. According to my observations, people are working on the same project, without changing it and not switching to others, about 2 years. The effect of the truck should be considered . It also happens that there are several testers in a company, and it is worth considering that when leaving on vacation other testers can double-check this defect.
5. The base of defects in the bugtracker should be kept with the expectation of future
Ideally, a defect description can be made focused on those who work with the product for the first time and have only documentation at their disposal.
It should be borne in mind that even after closing the defect, someone may need it. The estimated number of prospects is 2 years. (Estimated calculation).
For example, when workers change windows in the stairwell, it happens that they save time and effort in taking out the trash. It seems that the garbage does not interfere with the passage, residents walk quietly. And resources are saved. BUT: after a while there comes a moment when the garbage begins to interfere. And if there is a fire (release or something else), then the trouble begins.
For example, some old defect pops up among users (or there will be a new one, the symptoms of which will coincide with the old), because of this, the company suffers damage. Begin to figure out the details. And if the defect was framed haphazardly, then the owners will clearly not be delighted with the work of the tester.
Many times I noticed that testers when describing a defect are guided by the fact that it will be fixed by the team on the same day. With approximately 80% of defects this is what happens - they are fixed on the go and few people need them. But here about 20% of defects continue to exist, and about half of the remaining ones - over a sufficiently long period of time. During this time, the composition of the team working on the product undergoes changes. And when new team members begin to work, the analysis and reproduction of existing defects begins to take a very long time. It may take a lot of time to update each defect without an adequate description, even knowing the product at the documentation level.
I will give a rough calculation. I remember that in an 8-hour working day I was able to update about 5 defects without a description. If testers spent an additional 5 minutes on each defect when making defects, making the description more detailed, then an additional 500 minutes would be spent on installing 100 defects = about 1 working day. Of these 100 defects, about 20 will remain unclosed for a sufficiently large amount of time. In the calculation of 5 defects / day, they can take about 4 working days to be updated.
6. The description of defects should take into account that programmers who have to correct a defect may not be familiar with the functionality used during playback
When 1-2 programmers are working on a project, usually everyone fully knows all the functionality. But when, say, 10 programmers are working on a project, then everyone knows only the functionality in which he made changes. And do not force programmers to study the behavior of unfamiliar functionality for them. They have more than enough tasks to implement the new functionality.
7. As you receive information about the defect, it is worth updating the playback steps.
It often happens that important details of a defect are identified after its design. They are added somewhere in the comments to the defect. It is advantageous to update the information on the steps of reproduction in the description of the defect. Especially if the defect is related to several teams. Do not force everyone to reread the comments and delve into them.
8. If you want to attach a lot of files to the defect, then before that it’s convenient to give them names starting with numbers
For example:
1
- screenshot of the login window.jpg 2 - screenshot of the error in the console.jpg
3 - archive with downloaded files.zip
Subsequently, during discussion, attachments can be added, their number can grow to tens. It is convenient to operate with an indication of the attachment, for example: in screenshot 15 ... use the script from attachment 7 ... see the message in the archive log 25.
9. It is worth noting in the description of the defect information about partial corrections
If information on several similar errors is collected in one defect, for example, the description contains: The
error is displayed in browsers:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
After working on the defect, it is revealed that the defect is only partially corrected, then it’s advantageous Update the information in it without deleting the old one, but using the crossed out font:
Error after correction 01.01.2018 is displayed in the browsers:
1. Firefox
3. Internet Explorer
10. The company should determine the standard of criticality of defects
“What is good for a Russian is death to a German.” It is worth setting common criteria for determining the criticality of defects for testers in the company. It may turn out that everyone will consider that his defects should be fixed in the first place and not realize that at the same time resources will not be allocated to correct more critical defects.
11. Defects should be started as soon as possible.
Timeliness of institution of defects is an important matter. The faster they get started, the sooner and better they will be fixed. And the less likely it is to miss something critical in production. After viewing the defect by other team members, it may appear that the criticality is higher than it seems at first glance.
As one of the options - if a defect is discovered during a meeting or other work that cannot be distracted from, you can make a note about it on a piece of paper and write it at the end of the day.
12. Minor defects should not be ignored; it is worth filing them in a bugtracker.
You probably do not ignore the small garbage when cleaning the house, even if it does not interfere much. (Of course, there are those who do not maintain cleanliness and order in the house, but do not focus on them). Similarly, do not ignore minor defects. If internal agreements do not allow you to enter them in the bugtracker, then you can fix them in some other way, for example, on some page or in letters by mail.
When the product is small, minor defects are not very noticeable. But when the product becomes large - the scenarios become more capacious - the presence of minor defects begins to pester.
One can draw an analogy: imagine a small village, for example, a village of two streets, at the intersection of which there is one small hole with mud. It seems like there is a pit at each (single) intersection, but moving around the village is easy, just bypassing this pit each time. And she doesn’t bother anyone. Time passes. The settlement increases to the city of a millionaire. At each intersection, a hole in the mud. If you travel to such a city to work through a part of the city, then moving around a hole at each intersection will become far from so comfortable. And there will be a great desire to move to another city or re-elect the city administration. Similarly with software products - it should be promoted that users had a desire to work in them, instead of a desire to delete.
13. If the defect was instituted by someone other than the tester, then if necessary, it should be corrected.
Other team members also have defects. And they do not have to be familiar with the activities of the tester, they may have more than their own affairs. The defect base is one of the tester’s possessions, just as the code storage system is the programmer’s possessions.
If you, as a tester, see that the defect in your product is not brought up correctly, then you should correct it. Just as it is worth maintaining order in your home, folding things in their places if the guests put something in the wrong place.
PS Recently I started working at Modulbank and I plan to add these practices to existing ones.
