About the sad test
Everyone seems to know that testing is necessary, important and useful. In this post I would like to go over the points that make our testing necessary, important and useful.
Due to the fact that we are working with a developing web application that has many partners, updates and new functionality have to be rolled out often and in many ways. From this follows the basic principle of our testing - to catch as soon as possible what has broken, without prejudice to the speed of development .
Short:
')
To search for bugs, we use unit-tests, the Selenium plugin for FireFox, and manual interface testing.
I have been convinced of the need for unit tests to track bugs more than once and still believe in their power. At the moment we have written several dozen unit-tests, covering, of course, not all the functionality, but a substantial part of the typical user actions: registration, mark, creating a plan, and so on.
Unlike the "standard" unit-tests, we cover with a test not a specific function in the code, but some kind of user action. There is a test verifying the creation of friendship between users. When it starts, it consistently runs through all possible cases - users are already friends, users cannot become friends, because some conditions are not met, and so on. The test contains a mini-TZ on the logic of the application. The number of tests is growing with the introduction of new functionality. The binding for the tests was written by themselves, from third-party sources only PHPUnit_assert was happy to use.
After writing major edits, each of the development team on its local server should test the code, check whether its edits violate the basic social network algorithms, and so on. Such an approach reduces the time it takes to develop new features, and, of course, minimizes the appearance of new random errors.
We took for an axiom that it is impossible to intercept all errors that track unit tests - there are cases when it is necessary to urgently upload an update to the site. To do this, tests are run automatically on the main server every 6 hours. The result of the execution goes to the log file, the failed tests are sent to e-mail me and the development manager, SMS is sent.
Among the tools for front-end testing, we chose the Selenium IDE plugin for FireFox. The plugin is used to test input forms, the appearance of spinners, the emergence of pop-up windows and similar things. As an example, manually registering a user is very inconvenient to test, and with the help of the Selenium test, the test takes only a few seconds.
The new functionality is primarily tested manually. I try to try all possible options. For example, the interface of adding a place should work out not only the gradual filling in of all the information about the place (on our website this interface is divided into 4 screens), but also situations when the user at once decided not to add a place, did not completely fill in the necessary form or tried to skip one of the steps. In this case, you must at least display an error message. Later, according to the results of manual testing, Selenium tests are written.
Most often, the error cannot be corrected at the same moment, after its detection, which means that they need to be stored somewhere. For these purposes, we chose Google documents, where we created a table with the following fields:
The picture is clickable.
The priority field has several options for filling:
I work with the head of the development department with this table most of the time. There was an attempt to connect developers to adding new records and editing old ones, but programmers find it inconvenient to work in the table . If someone from the team finds an error, then he informs me about it on Skype or by e-mail.
As a result, the life cycle of the error found looks like this:
1. A bug was found and listed in the table;
2. If the bug is given priority P0 or P1, it goes to the current sprint as an unplanned task;
3. The programmer fixes a bug, when I close, I will find out about it;
4. I check the fix - you cannot skip this step and update the table.
Before the start of each sprint, I and Product Owner compile a list of errors that need to be fixed in the next sprint. As a rule, the list includes no more than 10 bugs requiring analysis, identifying problems and editing the code. Most often, the list includes unclosed P2. It would be more convenient to immediately add all new bugs to Aconote - then the need for a document with bugs disappears, but seeing a pool of unclosed tasks for bugs after the sprint is not the best option.
The analysis allows to draw the attention of the development team to repeated or typical errors of the code, layout, in order to prevent them and to save time for debugging.
In my experience, I note, bugs often arise from the fact that the task was not described in sufficient detail, or was not divided into subtasks . I will give an example, it was necessary to make a list of friends from the social network Facebook, to realize the opportunity to invite them to register with our service. The task is completed, but the page with the list itself was not brought to mind, because there was also a search for friends. The programmer did not take the initiative and the task of debugging the search did not stand, as a result of a bug.
The second type of bugs in popularity in our AlterGeo team are bugs that are located at the junction of the functional . For example, adding a new type of event. In this case, the bug may well manifest itself in the event tapes on one of the platforms, be it a website, a mobile version, or one of the mobile applications.
The convenient statistics that we build in the same table allows us to estimate the rate of appearance and correction of bugs, but for convenience, it is placed in a separate tab. The graph we have compiled not only reflects the general trend of errors, but also trends for each of the priorities.
Summing up, I repeat. Our approach to fixing bugs in the application is not aimed at trying to fix all the errors. Instead, we want to find bugs as early as possible without losing the pace of development. What is symbolic - after we recognized that developers will always be wrong and took this into account in their work, the quality of the application has increased dramatically.
PS Thank you for reading the article to the end. Any questions? Ask, it will be interesting to answer!
Due to the fact that we are working with a developing web application that has many partners, updates and new functionality have to be rolled out often and in many ways. From this follows the basic principle of our testing - to catch as soon as possible what has broken, without prejudice to the speed of development .
Short:- Code coverage unit-tests
- Selenium
- Automatic testing
- Detailed declaration of each error
- Weekly analysis and evaluation of detected bugs
- Acunote Sync
')
We search and find
To search for bugs, we use unit-tests, the Selenium plugin for FireFox, and manual interface testing.
I have been convinced of the need for unit tests to track bugs more than once and still believe in their power. At the moment we have written several dozen unit-tests, covering, of course, not all the functionality, but a substantial part of the typical user actions: registration, mark, creating a plan, and so on.
Unlike the "standard" unit-tests, we cover with a test not a specific function in the code, but some kind of user action. There is a test verifying the creation of friendship between users. When it starts, it consistently runs through all possible cases - users are already friends, users cannot become friends, because some conditions are not met, and so on. The test contains a mini-TZ on the logic of the application. The number of tests is growing with the introduction of new functionality. The binding for the tests was written by themselves, from third-party sources only PHPUnit_assert was happy to use.
After writing major edits, each of the development team on its local server should test the code, check whether its edits violate the basic social network algorithms, and so on. Such an approach reduces the time it takes to develop new features, and, of course, minimizes the appearance of new random errors.
We took for an axiom that it is impossible to intercept all errors that track unit tests - there are cases when it is necessary to urgently upload an update to the site. To do this, tests are run automatically on the main server every 6 hours. The result of the execution goes to the log file, the failed tests are sent to e-mail me and the development manager, SMS is sent.
Among the tools for front-end testing, we chose the Selenium IDE plugin for FireFox. The plugin is used to test input forms, the appearance of spinners, the emergence of pop-up windows and similar things. As an example, manually registering a user is very inconvenient to test, and with the help of the Selenium test, the test takes only a few seconds.
The new functionality is primarily tested manually. I try to try all possible options. For example, the interface of adding a place should work out not only the gradual filling in of all the information about the place (on our website this interface is divided into 4 screens), but also situations when the user at once decided not to add a place, did not completely fill in the necessary form or tried to skip one of the steps. In this case, you must at least display an error message. Later, according to the results of manual testing, Selenium tests are written.
Declare
Most often, the error cannot be corrected at the same moment, after its detection, which means that they need to be stored somewhere. For these purposes, we chose Google documents, where we created a table with the following fields:
- Baggage number (it is more convenient to operate when communicating with developers)
- Who discovered it (the author, the one who can ask additional questions)
- The place where they found
- Type of
- The condition of occurrence (if someone wants to repeat)
- Description (what specifically does not suit)
- It should appear (which as a result must be seen)
- Comments (just in case, attach a screenshot for example)
- Dates (opening, closing)
- Artist (who corrected)
- A priority
The picture is clickable.
The priority field has several options for filling:
- P0 - high priority bugs that need to be addressed right now. Most often these are errors concerning our partners or errors of the main functionality of the service.
- P1 - must be solved today
- P2 - decide for the current sprint
- P3 - decide for the current sprint, if time remains
- P4 - minor bugs, typos
I work with the head of the development department with this table most of the time. There was an attempt to connect developers to adding new records and editing old ones, but programmers find it inconvenient to work in the table . If someone from the team finds an error, then he informs me about it on Skype or by e-mail.
As a result, the life cycle of the error found looks like this:
1. A bug was found and listed in the table;
2. If the bug is given priority P0 or P1, it goes to the current sprint as an unplanned task;
3. The programmer fixes a bug, when I close, I will find out about it;
4. I check the fix - you cannot skip this step and update the table.
Are planning
Before the start of each sprint, I and Product Owner compile a list of errors that need to be fixed in the next sprint. As a rule, the list includes no more than 10 bugs requiring analysis, identifying problems and editing the code. Most often, the list includes unclosed P2. It would be more convenient to immediately add all new bugs to Aconote - then the need for a document with bugs disappears, but seeing a pool of unclosed tasks for bugs after the sprint is not the best option.
We analyze
The analysis allows to draw the attention of the development team to repeated or typical errors of the code, layout, in order to prevent them and to save time for debugging.
In my experience, I note, bugs often arise from the fact that the task was not described in sufficient detail, or was not divided into subtasks . I will give an example, it was necessary to make a list of friends from the social network Facebook, to realize the opportunity to invite them to register with our service. The task is completed, but the page with the list itself was not brought to mind, because there was also a search for friends. The programmer did not take the initiative and the task of debugging the search did not stand, as a result of a bug.
The second type of bugs in popularity in our AlterGeo team are bugs that are located at the junction of the functional . For example, adding a new type of event. In this case, the bug may well manifest itself in the event tapes on one of the platforms, be it a website, a mobile version, or one of the mobile applications.
The convenient statistics that we build in the same table allows us to estimate the rate of appearance and correction of bugs, but for convenience, it is placed in a separate tab. The graph we have compiled not only reflects the general trend of errors, but also trends for each of the priorities.
Summing up, I repeat. Our approach to fixing bugs in the application is not aimed at trying to fix all the errors. Instead, we want to find bugs as early as possible without losing the pace of development. What is symbolic - after we recognized that developers will always be wrong and took this into account in their work, the quality of the application has increased dramatically.
PS Thank you for reading the article to the end. Any questions? Ask, it will be interesting to answer!
Source: https://habr.com/ru/post/135180/
All Articles