Tester vs developer
Today I would like to touch on the subject of the software development process. More specifically, this article is about "How not to turn an office into a battlefield of testers and developers."
Six months ago, I plunged into software testing, it was interesting for me, and I realized that this is really mine. For hours I stuck on the testers' forums, read books and studied software development. In forums, groups and conversations, I often noticed jokes about the interaction of testers and developers, but I did not understand these jokes and did not pay attention to it. At least, until I got an internship in one software development company.
After a couple of months, I began to catch up with the meaning of these jokes and active discussions of Tester vs Developer. Since I was the first tester in this company, it was difficult to get comfortable. Tasks with an empty description, but with the names “test and sign off,” “check the site,” “the application does not work,” there was no end, and the developers and project manager did not know the concept of QA at all. Everyone is familiar with this phrase “Without TK - the result of the HZ”, so it was the same there. In addition to all this, no one was worried about the fact that the product was “crooked” to say the least. In most cases, it was like this: you get the task “test” - you test, report on the defects found and pass them on to the developer, but the developer could have this task for months. As a result, the chef considered that the tester in the state was superfluous and for me this nightmare was over, but the product remained “crooked”.
')
There are various disputes, disagreements, but it seems to me that it is high time to come up with some simple approach to avoid such cases.
Screenshot from the conversation of software testers:
Find the defect - document it - submit it to the developer for correction. But again, everything seems to be simple, if not for the developer’s reaction to his mistakes. Probably, he simply forgot that the task of the tester is to search for errors and failures in the functioning of the object. As a result, we, as a friendly community, began to give different advice to the poor lady. Many offered to resolve the issue through the tmlid, and some even offered to fill the face for such an attitude. Well, I offered my own version, but it seemed strange to many.
After a while I got on an interesting project in which the project manager was a bridge between the tester and the developers. I don’t know how effective this concept is, but we have never had a fight over all the time. As a bug tracking system, we used Trello. This system is convenient because it is all built on the basis of the board and everything that is in it is on one screen: the tasks, the history of changes, and any comments. But this is also the main disadvantage of the program. It is too simple and not intended for large teams.
From the project manager a task arrived, during testing each bug was made up as a separate card and attached to the "Bugs" block with the label "Failure" and with a detailed description. Then the project manager asked the priority card and threw one of the developers. Sometimes it happens that the deadlines are on fire and before meeting with the customer you need to check the most important points. In this case, the project manager asked the high priority of business logic-related bugs, and the bugs associated with the UI were postponed until later. Many will have the question "Who then will be responsible for the missed bugs in the prod?", Unfortunately we do not know.
The most important thing in this process is that the tester does not interact with the development team, therefore, there are no shouts, quarrels and disputes:
If your team has an adequate project manager or product owner, try testing this approach. I think that many will like it.
Of course, there are companies in which the attitude of developers and testers is perfect. For example, in which the developer is responsible for the missed bugs in production and user complaints. In this case, the developer himself will be interested in a good relationship with the tester. But again, the question arises, "How many companies work according to this principle?"
Thank you all for your attention.
Six months ago, I plunged into software testing, it was interesting for me, and I realized that this is really mine. For hours I stuck on the testers' forums, read books and studied software development. In forums, groups and conversations, I often noticed jokes about the interaction of testers and developers, but I did not understand these jokes and did not pay attention to it. At least, until I got an internship in one software development company.
After a couple of months, I began to catch up with the meaning of these jokes and active discussions of Tester vs Developer. Since I was the first tester in this company, it was difficult to get comfortable. Tasks with an empty description, but with the names “test and sign off,” “check the site,” “the application does not work,” there was no end, and the developers and project manager did not know the concept of QA at all. Everyone is familiar with this phrase “Without TK - the result of the HZ”, so it was the same there. In addition to all this, no one was worried about the fact that the product was “crooked” to say the least. In most cases, it was like this: you get the task “test” - you test, report on the defects found and pass them on to the developer, but the developer could have this task for months. As a result, the chef considered that the tester in the state was superfluous and for me this nightmare was over, but the product remained “crooked”.
')
There are various disputes, disagreements, but it seems to me that it is high time to come up with some simple approach to avoid such cases.
Screenshot from the conversation of software testers:
Find the defect - document it - submit it to the developer for correction. But again, everything seems to be simple, if not for the developer’s reaction to his mistakes. Probably, he simply forgot that the task of the tester is to search for errors and failures in the functioning of the object. As a result, we, as a friendly community, began to give different advice to the poor lady. Many offered to resolve the issue through the tmlid, and some even offered to fill the face for such an attitude. Well, I offered my own version, but it seemed strange to many.
After a while I got on an interesting project in which the project manager was a bridge between the tester and the developers. I don’t know how effective this concept is, but we have never had a fight over all the time. As a bug tracking system, we used Trello. This system is convenient because it is all built on the basis of the board and everything that is in it is on one screen: the tasks, the history of changes, and any comments. But this is also the main disadvantage of the program. It is too simple and not intended for large teams.
From the project manager a task arrived, during testing each bug was made up as a separate card and attached to the "Bugs" block with the label "Failure" and with a detailed description. Then the project manager asked the priority card and threw one of the developers. Sometimes it happens that the deadlines are on fire and before meeting with the customer you need to check the most important points. In this case, the project manager asked the high priority of business logic-related bugs, and the bugs associated with the UI were postponed until later. Many will have the question "Who then will be responsible for the missed bugs in the prod?", Unfortunately we do not know.
The most important thing in this process is that the tester does not interact with the development team, therefore, there are no shouts, quarrels and disputes:
- Yes, it's a bug!
- No, this is a feature!
If your team has an adequate project manager or product owner, try testing this approach. I think that many will like it.
Of course, there are companies in which the attitude of developers and testers is perfect. For example, in which the developer is responsible for the missed bugs in production and user complaints. In this case, the developer himself will be interested in a good relationship with the tester. But again, the question arises, "How many companies work according to this principle?"
Thank you all for your attention.
Source: https://habr.com/ru/post/311430/
All Articles