Testing: 20 beginner principles
It all started in the office kitchen with a dispute that broke out between me, the manager of business processes and risks and my colleague from the department of technical sales support. At that time, he studied at the course of one and a half year basic programming courses at the local institute of information technology, and I just analyzed the processes, calculated the risks, justified proposals for the purchase of software. He sat opposite and told how difficult it was to learn, how tightly subjects were given to him and how ready he was to deduct, paying more than 50 thousand. I don’t know what they poured for me instead of tea, but I confidently and rudely said: “You know, I will also go since October and you will see that my semi-technical education and the age of 27 years is not an obstacle for mastering all this”. He twisted at the temple ...
I will not talk about the difficulties of learning and the successful protection of my full-fledged, but very trivial program project in English, but I’ll tell you about the consequences of my studies. At the end of the training, I realized that I was fed up with work and wanted something completely different. As you know, sometimes dreams come true and we were offered to undergo a three-month internship as testing engineers with a decent salary in one large IT office. Normal people refused ...
... and I decided to work there for almost a year. This year has become for me a year of growth, progress, development and new, interesting discoveries in the IT sphere. Today I work in another, no less IT-shnoy place, but the experience remains. And I want to share it. On Habré, there are many articles about testing, about covering code with tests, about automation, and very little information for newbies who just come to testing and really want to work with dignity and also live to write autotests and utilities. For them, I will set out 20 principles that I managed to take out of work and which allowed me to become one of the leaders of the team as soon as possible.
1. Find out what you are testing. Determine which industry the program belongs to, by what means and in what languages ​​its components are written, which database is used, which protocols are involved. Be sure to specify in which countries it will be used. For example, if you test telecommunications software and it is sold all over the world, it would not be out of place to inquire about the North American NANP numbering plans.
2. Find out who your customer or end user is. Become the end user yourself. Do not forget that the software can be used by people who are absolutely far from IT and their work style is completely different. Check what the user can change, what access rights can be set and what can be broken in theory with these rights in the program.
3. Map the devices with which the software can interact, sort through the combinations of these devices. Obviously, today, the software can work on a variety of devices running under different operating systems, with different screen resolutions, control systems, and so on ... Make a map of the devices that run your software for yourself, write down the basic specifications, think of possible combinations of iron and software. This will greatly facilitate the work.
4. Break the program into pieces. Little things do not happen. Study the program thoroughly: from the exit button to the very last function. You need to know the principles and dependencies of the work of all related modules, this is testing the environment, which allows you to identify a huge number of bugs that, when skipped, will certainly become client-side. For example, there was a case that one of the program versions did not respond to the exit button, but was closed only with a cross. The bug was missed and returned with a client case.
5. Learn about the types of testing . Here colleagues, books and Wikipedia to help you. There are functional, regression, saniti, load and so on. testing. Sooner or later you will touch all kinds and appreciate the advantages of each, therefore knowledge of the principles and secrets accumulated by previous generations will not hurt.
6. Get to know the bugtracker. Review the required fields, get a test bug, study the responsible ones - this will allow you to save time in the future and create cases that will not come back to you with hundreds of clarifying questions.
7. Read the bugtracker. This is the most powerful combat test encyclopedia where experience has been gained precisely on your narrow problem. You will see where the most common problems are, segmented by severity and complexity. This is a great tool for deep familiarity with the profession.
8. Record all the vulnerabilities that you encounter, even if it is not quite bugs. Such places can often cause errors in the program. You will have your own handbook of experience, which you will open and supplement each time you start testing the next version.
9. Reproduce critical situations. Do not rejoice when you see a bug. First, reproduce it a couple of times, analyze possible causes, carefully describe the conditions of reproduction: equipment, time, procedure. This will help developers reproduce the error on their part and understand the reasons for its occurrence.
10. Watch for logs , if any. Be sure to collect any logs that the program under test is able to record. These are not necessarily multipage logs in the console, these can be hung pages in the web, error windows, lines with an error code. If it is not possible to copy or upload information, take a screenshot. All the information received in the case form in the form of attachments - the developers do not have to find out from you that for the window fell. In addition, if the bug is not reproduced, the presence of a screenshot or a log with a fall is a reason to have a valid case.
11. Think wide. Remember that your software does not live its life in a vacuum on a separate clean computer or gadget and study competitors, if possible. Probably something unobvious and adjoined will become more visible to you from the side after studying the functionality of someone else. Or maybe you can just offer to implement an effective feature.
12. Consult with colleagues : testers, developers and managers. They are authors, sources of user and professional experience. If you don’t know something specific (for example, hardware settings), then it’s better to ask your colleagues than Google’s - they have done this repeatedly and will definitely help. Believe me, it may be worse if, for example, your incorrectly configured equipment suddenly gives you new IPs via DHCP.
13. Learn new testing features. Read books, communities (the same Habr), do not stop in your development, try to write simple scripts, learn more about test automation.
14. Do not be lazy to double-check the functionality after fixing the bug. You will be asked to do it anyway, but if suddenly you find out that there is no such case, do not be lazy - choose free minutes and check. The case could have intentionally or unintentionally forgotten to be included in the test plan, and replaying the bug would be unpleasant.
15. If you can create a load - create it. The load means not only mass calls or interconnections, for example, but also situations with large amounts of data, several users, etc ... Ask for help from colleagues. Get more test data, add multimedia if necessary. Contact the managers - it is very likely that they have unnecessary test client data on which you can test the software in conditions as close as possible to the workers.
16. Learn operating systems and programming languages. Even if you cannot write a serious block of code, you will understand the program architecture much better, foresee where problems may arise and what they are connected with.
17. Examine and verify the documentation. Documentation is part of the software that is also being tested. If you do not get such a case, do not rejoice, but, on the contrary, be sure to read it - there you will see new possibilities of working with software, and, perhaps, you will encounter inconsistencies or outright mistakes.
18. Transfer experience. So the testing departments are arranged, that people often change in them. Be sure to help a new person: explaining a question, you will not only consolidate your knowledge, but also see a solution that was close, but was not.
19. Plan. Of course, you will have a test plan with invented time. But the main plan is what you have made up for yourself, with your criteria of quality. Methodically note what has been done, check the progress of the work, ask for help if you do not have time. Proper organization of time works wonders and allows you to engage in self-education, or even distract with time around workers, but extraneous things.
20. Do not trust others. Oddly enough, but it is. If you see that a specific case or a similar case for the version before the current one was tested by your colleague, do not fully trust its conclusions and test plan, try to make something of your own, based on them. I think by 20 point the reasons for the distrust will become clear to you.
Testing engineers, testers, testers often ridicule, parody, write about us demotivators and IT jokes. So they are needed. For the stability of the programs, the release of successful releases, the lack of customer dissatisfaction. A real tester will never get away from the problem, he is part of the team and no matter which: fashionable agile or the old functional hierarchy.
Testing is knowledge, responsibility and some luck. So good luck!
I will not talk about the difficulties of learning and the successful protection of my full-fledged, but very trivial program project in English, but I’ll tell you about the consequences of my studies. At the end of the training, I realized that I was fed up with work and wanted something completely different. As you know, sometimes dreams come true and we were offered to undergo a three-month internship as testing engineers with a decent salary in one large IT office. Normal people refused ...
... and I decided to work there for almost a year. This year has become for me a year of growth, progress, development and new, interesting discoveries in the IT sphere. Today I work in another, no less IT-shnoy place, but the experience remains. And I want to share it. On Habré, there are many articles about testing, about covering code with tests, about automation, and very little information for newbies who just come to testing and really want to work with dignity and also live to write autotests and utilities. For them, I will set out 20 principles that I managed to take out of work and which allowed me to become one of the leaders of the team as soon as possible.
1. Find out what you are testing. Determine which industry the program belongs to, by what means and in what languages ​​its components are written, which database is used, which protocols are involved. Be sure to specify in which countries it will be used. For example, if you test telecommunications software and it is sold all over the world, it would not be out of place to inquire about the North American NANP numbering plans.
2. Find out who your customer or end user is. Become the end user yourself. Do not forget that the software can be used by people who are absolutely far from IT and their work style is completely different. Check what the user can change, what access rights can be set and what can be broken in theory with these rights in the program.
3. Map the devices with which the software can interact, sort through the combinations of these devices. Obviously, today, the software can work on a variety of devices running under different operating systems, with different screen resolutions, control systems, and so on ... Make a map of the devices that run your software for yourself, write down the basic specifications, think of possible combinations of iron and software. This will greatly facilitate the work.
4. Break the program into pieces. Little things do not happen. Study the program thoroughly: from the exit button to the very last function. You need to know the principles and dependencies of the work of all related modules, this is testing the environment, which allows you to identify a huge number of bugs that, when skipped, will certainly become client-side. For example, there was a case that one of the program versions did not respond to the exit button, but was closed only with a cross. The bug was missed and returned with a client case.
5. Learn about the types of testing . Here colleagues, books and Wikipedia to help you. There are functional, regression, saniti, load and so on. testing. Sooner or later you will touch all kinds and appreciate the advantages of each, therefore knowledge of the principles and secrets accumulated by previous generations will not hurt.
6. Get to know the bugtracker. Review the required fields, get a test bug, study the responsible ones - this will allow you to save time in the future and create cases that will not come back to you with hundreds of clarifying questions.
7. Read the bugtracker. This is the most powerful combat test encyclopedia where experience has been gained precisely on your narrow problem. You will see where the most common problems are, segmented by severity and complexity. This is a great tool for deep familiarity with the profession.
8. Record all the vulnerabilities that you encounter, even if it is not quite bugs. Such places can often cause errors in the program. You will have your own handbook of experience, which you will open and supplement each time you start testing the next version.
9. Reproduce critical situations. Do not rejoice when you see a bug. First, reproduce it a couple of times, analyze possible causes, carefully describe the conditions of reproduction: equipment, time, procedure. This will help developers reproduce the error on their part and understand the reasons for its occurrence.
10. Watch for logs , if any. Be sure to collect any logs that the program under test is able to record. These are not necessarily multipage logs in the console, these can be hung pages in the web, error windows, lines with an error code. If it is not possible to copy or upload information, take a screenshot. All the information received in the case form in the form of attachments - the developers do not have to find out from you that for the window fell. In addition, if the bug is not reproduced, the presence of a screenshot or a log with a fall is a reason to have a valid case.
11. Think wide. Remember that your software does not live its life in a vacuum on a separate clean computer or gadget and study competitors, if possible. Probably something unobvious and adjoined will become more visible to you from the side after studying the functionality of someone else. Or maybe you can just offer to implement an effective feature.
12. Consult with colleagues : testers, developers and managers. They are authors, sources of user and professional experience. If you don’t know something specific (for example, hardware settings), then it’s better to ask your colleagues than Google’s - they have done this repeatedly and will definitely help. Believe me, it may be worse if, for example, your incorrectly configured equipment suddenly gives you new IPs via DHCP.
13. Learn new testing features. Read books, communities (the same Habr), do not stop in your development, try to write simple scripts, learn more about test automation.
14. Do not be lazy to double-check the functionality after fixing the bug. You will be asked to do it anyway, but if suddenly you find out that there is no such case, do not be lazy - choose free minutes and check. The case could have intentionally or unintentionally forgotten to be included in the test plan, and replaying the bug would be unpleasant.
15. If you can create a load - create it. The load means not only mass calls or interconnections, for example, but also situations with large amounts of data, several users, etc ... Ask for help from colleagues. Get more test data, add multimedia if necessary. Contact the managers - it is very likely that they have unnecessary test client data on which you can test the software in conditions as close as possible to the workers.
16. Learn operating systems and programming languages. Even if you cannot write a serious block of code, you will understand the program architecture much better, foresee where problems may arise and what they are connected with.
17. Examine and verify the documentation. Documentation is part of the software that is also being tested. If you do not get such a case, do not rejoice, but, on the contrary, be sure to read it - there you will see new possibilities of working with software, and, perhaps, you will encounter inconsistencies or outright mistakes.
18. Transfer experience. So the testing departments are arranged, that people often change in them. Be sure to help a new person: explaining a question, you will not only consolidate your knowledge, but also see a solution that was close, but was not.
19. Plan. Of course, you will have a test plan with invented time. But the main plan is what you have made up for yourself, with your criteria of quality. Methodically note what has been done, check the progress of the work, ask for help if you do not have time. Proper organization of time works wonders and allows you to engage in self-education, or even distract with time around workers, but extraneous things.
20. Do not trust others. Oddly enough, but it is. If you see that a specific case or a similar case for the version before the current one was tested by your colleague, do not fully trust its conclusions and test plan, try to make something of your own, based on them. I think by 20 point the reasons for the distrust will become clear to you.
Testing engineers, testers, testers often ridicule, parody, write about us demotivators and IT jokes. So they are needed. For the stability of the programs, the release of successful releases, the lack of customer dissatisfaction. A real tester will never get away from the problem, he is part of the team and no matter which: fashionable agile or the old functional hierarchy.
Testing is knowledge, responsibility and some luck. So good luck!
')
Source: https://habr.com/ru/post/193138/
All Articles