Let's start by looking at some tasks - who is responsible for what?

The developer is responsible for the implementation of the technical specifications: finalize the code, add new functionality, check how it will work at the level of Unit tests or a direct case. After that, the code is sent for review, and then it is transferred to testing. That is, the developer creates “own child”, and at the same time he may not notice any inaccuracies. The tester is responsible for compliance with direct and indirect requirements. For example, cases that are implicit at first glance, which are not taken into account in the formulation of the problem or are missed. For indirect cases, you can contact the BA, your Team Lead, or the Customer for clarification. Then, the tester starts to “probe” the new revision according to the requirements, and try to break what was created by the developer in order to find flaws that could affect the system. Thus, the tester turns into a "destroyer", because it is important to predict what the user can "break" when using the product.

Why is it better not to go beyond your duties?

Developers can only be good testers and vice versa if they fulfill their role as testers (or, respectively, developers). To perform a particular role, you need to know and be able to apply specific soft and hard skills. For example: in order for a developer to test well, he needs to understand the theory of testing, testing methods, test design techniques and learn how to write test documentation correctly. Also, you need to be able to use different tools for testing. And vice versa - in order for a tester to be able to program well, you need to learn OOP (object-oriented programming), learn how to put it into practice and delve into the language in which development is carried out. The snag is in the approach to the task and the priority of directions. Imagine - the developer needs not only to implement the task in accordance with the requirements, but also to predict what and where can go wrong. Thus, at first time is spent on development, and after that - on testing. It is important to remember that when developing yourself, it is much more difficult to notice flaws. In addition, the developer looks at the code from the side of the set requirements, and for high-quality testing, he will have to “switch” to the logic and thinking of the tester or a user. Another problem with such a flow is the long implementation of the project. Part of the functionality is developed, tested, and the next part is waiting for its turn. Thus, a developer doing the work of a tester becomes a bottleneck. This leads to a greater delay in the delivery of both the entire project and individual improvements or corrections of the defects found. This all translates into a delay from the original deadlines, an increase in the budget and problems with the implementation and delivery of the product to the customer. Due to the division of tasks, the development will be significantly accelerated and the quality of the product will increase. Since everyone is responsible for their own piece of work, specialists do not need to be torn between tasks and change the type of work and view of the same code.