Defect management style
As a tester, I saw a lot of defects, the reproduction of which made it difficult for me. I would like to share some practices of defects registration - I hope that this will help to slightly improve someone’s life.
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 lives of programmers. My role in software development was testing. As one of my responsibilities 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. Positive information usually consisted in the fact that the expected behavior coincided with the actual one, and the test results could be provided as data in the test report (feature 1 works, scenario 2 works, etc.). But negative information is most often produced and documented in the form of defects. (of course, there were other work items, such as risks, requests for change, etc.)
I met within the projects a knowledge base (not only defects), oriented towards the fact that it is “once and in production”. Just like road workers - to pass the object, and then come what may.
')
It would be desirable that quality assurance processes were conducted with the expectation that after transferring the product to release it could be accompanied, keeping good memories of the development team.
Usually the defect includes:
1. Name
2. Criticality
3. Description: Information about the stand, playback steps, actual and expected result.
Depending on the bugtracking system there may be other fields.
About what the defect consists of and the basic rules of design, such as asking the name of the defect, answering the questions "What, where, when?" On the Internet, including at the very habr met many articles. Here I want to share my own personal experience.
Defects can look not only programmers and testers, but also other people who are interested in the release and sale of the product. For example: the director of the development center, the head of the sales department, the user interface designer, the members of the team developing another product, integrated with the person being tested. And they do not have time to study the details and analyze the effect of a defect on their area of ​​responsibility. They do not have to be familiar with all the technical details of your product.
It is necessary to focus on the fact that the name of the defect can be understood to what functionality it refers to, using the search in the documentation or in the knowledge base.
It should be borne in mind that when making changes to the product, the technical description may change, but the defect usually continues to occur.
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.
When a project is small and you are the only tester (perhaps combining other responsibilities, for example, a programmer), defects can be arranged as you please. 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 big family, you should respectfully that other family members will want to see cleanliness and order.
Regarding the stand:
It should be borne in mind that occasionally defects are corrected under conditions of a tight deadline, when many people eagerly yearn for their correction or rechecking, every minute counts for gold - and it is worthwhile to make sure that time does not flow in vain due to careless clearance.
Before you start a defect, it is advisable to reproduce it, localize the conditions of its reproduction and discard the superfluous. If there is an assumption that some factor does not affect reproduction, then it is better to state it directly and not expect that this information will be transmitted telepathically.
Just as the instructions for any device must have a sufficient amount of information given that they can use someone other than the manufacturer of these devices.
It should be noted that the 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. Should take into account the effect of the truck . It also happens that there are several testers in the company, and it is worthwhile to envisage that when going on vacation, other testers could recheck this defect.
Ideally, the description of the defect can be made focused on those who work with the product for the first time and have only documentation available.
It should be borne in mind that even after the defect is closed, someone may need it. Approximate figure of prospects is 2 years. (Approximate calculation).
For example, when workers change windows in an entrance, it happens so that they save time and efforts on carrying out the garbage. It seems the garbage does not interfere with the aisle, the residents walk quietly. And resources are saved. BUT: after a while there comes a time when the garbage begins to interfere. And if a fire happens (release or some other event), then the trouble begins.
For example, some old defect pops up at users (or there will be a new one, the symptoms of which will coincide with the old one), because of this, the company incurs damage. Begin to figure out the details. And if the defect was registered as horrible, the owners obviously will not be delighted with the work of the tester.
Many times noticed that testers when describing a defect are guided by the fact that it will be corrected by the team on the same day. Approximately with 80% of defects it happens - they are corrected on the fly and they become very few people need. But here about 20% of defects continue to exist, and about half of the remaining - for a sufficiently large period of time. During this time, the composition of the team working on the product is changing. And when new team members start working, the analysis and reproduction of existing defects starts to take a very long time. It can take a lot of time to update every defect without an adequate description, even knowing the product at the documentation level.
I will give a rough calculation. I remember that during the 8-hour working day I managed to update about 5 defects without a description. If testers spent an extra 5 minutes on each defect when making defects, making the description in more detail, 100 defects would take an additional 500 minutes = about 1 working day to establish 100 defects. Of these 100 defects, about 20 will remain unclosed for a sufficiently large amount of time. It may take about 4 working days to update them when calculating 5 defects / day.
When 1-2 programmers work 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 a function unfamiliar to them. They have more than enough tasks to implement the new functionality.
It often happens that important details of a defect are revealed after its completion. They are added somewhere in the comments to the defect. It is advantageous to update information about the steps of playback 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 console error.jpg
3 - archive with downloadable files.zip
Subsequently, during the discussion, investments can be added, their number can grow to tens. It is convenient to operate with an indication of attachments, for example: in the screenshot 15 ... use the script from attachment 7 ... see the message in the archive log 25.
If information about several similar errors is collected in one defect, for example, the description is present:
The error is displayed in browsers:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
After working on a defect, it is revealed that the defect is only partially corrected, it is advantageous to update the information in it, not deleting the old one, but using the crossed out font:
The error after the correction of 01/01/2018 is displayed in browsers:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
"What is good for the Russian, then the German is death." It is necessary to set uniform 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 corrected first of all and not be aware that at the same time resources will not be allocated for the correction of more critical defects.
The timeliness of the institution of defects is an important matter. The faster they are established, the sooner and better they will be corrected. And the less likely to miss something critical in production. After viewing a defect by other team members, it may become apparent that the criticality is higher than it seems at first glance.
As one of the options - if a defect is found during a meeting or other work, to distract from which it is not possible - you can take a note about it on a piece of paper, and start it at the end of the day.
You probably do not ignore the small debris when cleaning the house, even if it does not interfere. (There are, of course, those who do not maintain cleanliness and order in the house, but do not focus on them). Likewise, minor defects should not be ignored. If internal agreements do not allow entering them into a bugtracker, then they can be fixed in some other way, for example, on some page or in letters by mail.
When a product is small, small defects are not very noticeable. But when the product becomes large - scenarios are more capacious - the presence of small defects begins to pester.
We can make this analogy: imagine a small town, for example, a village of two streets, at the crossroads of which there is one small hole with mud. It seems to be at every (only) crossroads pit, but moving around the village is easy, just by going around this pit every time. And she does not bother anyone. Time passes. The settlement increases to the city of milionnica. At each intersection in the hole with mud. If you travel to such a city to work through a part-city, then moving around one hole at each intersection will not be 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 ensured that users have 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 can be complementary to their cases. The base of defects is one of the possessions of the tester, just as the code storage system is the possessions of programmers.
If you, being a tester, see that the defect on your product is not quite correct, then you should correct it. Just as it is necessary to maintain order in my house, putting things in their places if the guests put something in the wrong place.
PS Recently I started working at Modbank and I plan to add these practices to the existing ones.
Foreword
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 lives of programmers. My role in software development was testing. As one of my responsibilities 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. Positive information usually consisted in the fact that the expected behavior coincided with the actual one, and the test results could be provided as data in the test report (feature 1 works, scenario 2 works, etc.). But negative information is most often produced and documented in the form of defects. (of course, there were other work items, such as risks, requests for change, etc.)
I met within the projects a knowledge base (not only defects), oriented towards the fact that it is “once and in production”. Just like road workers - to pass the object, and then come what may.
')
It would be desirable that quality assurance processes were conducted with the expectation that after transferring the product to release it could be accompanied, keeping good memories of the development team.
Usually the defect includes:
1. Name
2. Criticality
3. Description: Information about the stand, playback steps, actual and expected result.
Depending on the bugtracking system there may be other fields.
About what the defect consists of and the basic rules of design, such as asking the name of the defect, answering the questions "What, where, when?" On the Internet, including at the very habr met many articles. Here I want to share my own personal experience.
1. The name should reflect the essence of the manifestation of the defect at the application level.
Defects can look not only programmers and testers, but also other people who are interested in the release and sale of the product. For example: the director of the development center, the head of the sales department, the user interface designer, the members of the team developing another product, integrated with the person being tested. And they do not have time to study the details and analyze the effect of a defect on their area of ​​responsibility. They do not have to be familiar with all the technical details of your product.
It is necessary to focus on the fact that the name of the defect can be understood to what functionality it refers to, using the search in the documentation or in the knowledge base.
It should be borne in mind that when making changes to the product, the technical description may change, but the defect usually continues to occur.
2. It is worth being guided by the fact that when reproducing a defect, colleagues do not waste their time doing thought-out 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.
When a project is small and you are the only tester (perhaps combining other responsibilities, for example, a programmer), defects can be arranged as you please. 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 big family, you should respectfully that other family members will want to see cleanliness and order.
Regarding the stand:
| Do not make out so | Better to issue | Note |
|---|---|---|
| On my grandfather's computer in the village | Machine: CPU: AMD A4-6300, RAM: 2 GB DDR3, HDD: 500GB, 1024x768 screen, OS: Windows 7 x64 | It is more precise to indicate exactly where the defect appeared. |
| At the test stand of Chameleon and Babochkina | Machine1: Windows 10, GCr 20.1 Machine2: Windows 10, FF 30.1 | On the stands often something changes, and it is worth considering this. |
It should be borne in mind that occasionally defects are corrected under conditions of a tight deadline, when many people eagerly yearn for their correction or rechecking, every minute counts for gold - and it is worthwhile to make sure that time does not flow in vain due to careless clearance.
3. The description of the defect should not contain non-relevant information.
| Do not make out so | 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 | Anything 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 of its reproduction and discard the superfluous. If there is an assumption that some factor does not affect reproduction, then it is better to state it directly and not expect that this information will be transmitted telepathically.
4. The description of the defect should contain enough information to reproduce.
Just as the instructions for any device must have a sufficient amount of information given that they can use someone other than the manufacturer of these devices.
It should be noted that the 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. Should take into account the effect of the truck . It also happens that there are several testers in the company, and it is worthwhile to envisage that when going on vacation, other testers could recheck this defect.
5. The base of the defects in the bugtracker should be kept with the expectation
Ideally, the description of the defect can be made focused on those who work with the product for the first time and have only documentation available.
It should be borne in mind that even after the defect is closed, someone may need it. Approximate figure of prospects is 2 years. (Approximate calculation).
For example, when workers change windows in an entrance, it happens so that they save time and efforts on carrying out the garbage. It seems the garbage does not interfere with the aisle, the residents walk quietly. And resources are saved. BUT: after a while there comes a time when the garbage begins to interfere. And if a fire happens (release or some other event), then the trouble begins.
For example, some old defect pops up at users (or there will be a new one, the symptoms of which will coincide with the old one), because of this, the company incurs damage. Begin to figure out the details. And if the defect was registered as horrible, the owners obviously will not be delighted with the work of the tester.
Many times noticed that testers when describing a defect are guided by the fact that it will be corrected by the team on the same day. Approximately with 80% of defects it happens - they are corrected on the fly and they become very few people need. But here about 20% of defects continue to exist, and about half of the remaining - for a sufficiently large period of time. During this time, the composition of the team working on the product is changing. And when new team members start working, the analysis and reproduction of existing defects starts to take a very long time. It can take a lot of time to update every defect without an adequate description, even knowing the product at the documentation level.
I will give a rough calculation. I remember that during the 8-hour working day I managed to update about 5 defects without a description. If testers spent an extra 5 minutes on each defect when making defects, making the description in more detail, 100 defects would take an additional 500 minutes = about 1 working day to establish 100 defects. Of these 100 defects, about 20 will remain unclosed for a sufficiently large amount of time. It may take about 4 working days to update them when calculating 5 defects / day.
6. The description of defects should take into account that programmers who will have to correct the defect may not be familiar with the functionality used in playback.
When 1-2 programmers work 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 a function unfamiliar to them. They have more than enough tasks to implement the new functionality.
7. As information about the defect is obtained, it is worth updating the playback steps.
It often happens that important details of a defect are revealed after its completion. They are added somewhere in the comments to the defect. It is advantageous to update information about the steps of playback 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 need to attach a lot of files to a defect, then before that it is convenient to give them names beginning with numbers
For example:
1-screenshot of the login window.jpg
2 - screenshot of console error.jpg
3 - archive with downloadable files.zip
Subsequently, during the discussion, investments can be added, their number can grow to tens. It is convenient to operate with an indication of attachments, for example: in the 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 the partial fixes.
If information about several similar errors is collected in one defect, for example, the description is present:
The error is displayed in browsers:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
After working on a defect, it is revealed that the defect is only partially corrected, it is advantageous to update the information in it, not deleting the old one, but using the crossed out font:
The error after the correction of 01/01/2018 is displayed in browsers:
1. Firefox
3. Internet Explorer
10. The company should determine the standard of criticality of defects.
"What is good for the Russian, then the German is death." It is necessary to set uniform 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 corrected first of all and not be aware that at the same time resources will not be allocated for the correction of more critical defects.
11. Defects should be started as soon as possible.
The timeliness of the institution of defects is an important matter. The faster they are established, the sooner and better they will be corrected. And the less likely to miss something critical in production. After viewing a defect by other team members, it may become apparent that the criticality is higher than it seems at first glance.
As one of the options - if a defect is found during a meeting or other work, to distract from which it is not possible - you can take a note about it on a piece of paper, and start it at the end of the day.
12. You should not ignore minor defects, it is worth making them in the bugtracker
You probably do not ignore the small debris when cleaning the house, even if it does not interfere. (There are, of course, those who do not maintain cleanliness and order in the house, but do not focus on them). Likewise, minor defects should not be ignored. If internal agreements do not allow entering them into a bugtracker, then they can be fixed in some other way, for example, on some page or in letters by mail.
When a product is small, small defects are not very noticeable. But when the product becomes large - scenarios are more capacious - the presence of small defects begins to pester.
We can make this analogy: imagine a small town, for example, a village of two streets, at the crossroads of which there is one small hole with mud. It seems to be at every (only) crossroads pit, but moving around the village is easy, just by going around this pit every time. And she does not bother anyone. Time passes. The settlement increases to the city of milionnica. At each intersection in the hole with mud. If you travel to such a city to work through a part-city, then moving around one hole at each intersection will not be 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 ensured that users have a desire to work in them, instead of a desire to delete.
13. If the defect was initiated by someone other than the tester, then, if necessary, correct it.
Other team members also have defects. And they do not have to be familiar with the activities of the tester, they can be complementary to their cases. The base of defects is one of the possessions of the tester, just as the code storage system is the possessions of programmers.
If you, being a tester, see that the defect on your product is not quite correct, then you should correct it. Just as it is necessary to maintain order in my house, putting things in their places if the guests put something in the wrong place.
PS Recently I started working at Modbank and I plan to add these practices to the existing ones.
Source: https://habr.com/ru/post/358926/
All Articles