Test report

The tester must constantly provide his boss with up-to-date information about his work. According to such reports, if they are made correctly, the boss draws a conclusion about the state of the project as a whole. Not only about the work of one tester or the entire testing team, but also about the work of the development team and the stage at which the project is. Also, such reports allow you to make an analysis for planning future releases, etc.

There are many examples when this work was not done or was done in an inappropriate way, from which the authorities had a feeling of uncertainty with all the ensuing consequences. I'll tell you the brightest one.

Once a tester was assigned to a new project. Since he did not know him well, he was given the task of sorting out and recording observations. Since it was something informal, we agreed that we would write in Google Doc. The person began to perform the task, after a week this task was checked, the tester was patted on the shoulder and he continued to work. Months passed, the authorities began to worry about why there were no tickets in the bugtracker and nothing was being done on the project. We began to figure it out, it turned out that the person continues to write in the same Google doc. Nobody said “Pot, don’t boil” and didn’t stop the tester, but he regularly continued to understand and record observations, while not making himself felt. There are bugs, and he found them, but he didn’t tell anyone, but only wrote them down in a file, which everyone forgot about a week later.

In fact, the expectation was that the person would continue to work formally, i.e. in the bugtracker, giving developers work to do with their tickets, but this did not happen. It seemed that the man did nothing, even though he worked. It is clear that the problem was not only on the part of the tester, but if he had made a regular report on his activities, misunderstandings could have been avoided.

Often, the lack of information creates a feeling of poor testing of the product, that this or that part of the functionality was not tested. To prevent this from happening, you need to draw up detailed reports, this is especially important on large projects.

Test benches and test data

In different companies, this happens in different ways, but it often happens that an employee is granted rights to the customer's working server or is given his database for testing. It would seem that what could go wrong?

If someone has access to the customer's server, on the one hand, this is convenient, you can see the problems from the front row and not guess the error from the photo. But there is a risk of corrupting customer data, which can lead to serious consequences. I am already silent about those cases when such access is generally prohibited by law.

There was a case when the customer's server fell off for 3 days. The developer all this time could not understand why this happened, and frantically searched for an error, and the business suffered losses. As a result, it turned out that the company hired Indians for outsourcing, where the people, without further ado, gave everyone admin rights. To everyone - this means, even to the girl who works in the company for 3 days, but there was no company in her village, so they have an even shorter acquaintance period. But the girl turned out to be terribly talented, she managed to find the basic entity in the admin panel and changed its type, after which, naturally, everything fell off and stopped working. It's not hard to guess how she soared through the ranks after that.

The same nonsense and with the data from the customer. Again, I'm not talking about cases where this is prohibited by law. If it is possible to work on real data, this is great, but you need to be careful with this. Everyone must have heard stories about randomly sending emails or messages from the test server to real users. Now, this is not a joke. This really happens, and quite often. It's fine if these messages are titled as test messages and have sane content, but it happens that people take courage and write something that the entire application development team later regrets.