team scrum codes more than it can test

The sprint is estimated according to the testing capacity, the devs end up working on new cards to take advantage of the time and not be idle.

Taking on new work is the last thing the Developers should do. They've already got work in progress, untested, and their commitment is to create an increment that is Done. If testing is needed then, as a matter of professional commitment, they will do whatever it takes to assist with that.

When the sprint ends, I always have a large balance of user stories to test, and I move them to the next sprint. This ends up generating a backlog, which will compromise the current sprint.

No, it's worse than that. You've eroded the Sprint boundary and removed transparency over the undone work, which ought to be accounted for on the Product Backlog, as well as over the failure of the Developers to make and honor a shared commitment.

The problem is that you are starting work instead of finishing it. Instead of figuring out what the developer can do to help get work fully complete, they are starting new work and creating an inventory. Inventories are waste. In addition, they could be building this new work on top of untested (incomplete) work that may not yet be stable, so this could be done at risk of not-insignificant rework.

Along these same lines, hand-offs are waste. When you take a unit of work and hand it off from a developer to a tester, you also need to convey information in addition to the work product. You could do this up-front, by also handing over relevant documentation or you could do this just-in-time by answering questions or addressing concerns as they come up. Either way, though, you need to invest time in making sure that all the people involved in getting work done have the same understanding.

You're in an interesting position where you have an equal number of developers and testers. Most organizations that I've seen have far fewer test specialists than developers on a team. Having equal numbers can open the possibility of pairing. For each unit of work, one developer and one tester work together from start to finish to understand the requirement, making sure that it's a high-quality requirement (complete, consistent, unambiguous, testable), talking through the design and implementation to understand how it satisfies the requirement, and then testing the solution as it is developed to build quality in.

You may also want to prepare your organization to scale. You may find that it's not possible or desired to support an equal number of development specialists and test specialists. Having the test specialists teach basic-to-intermediate testing skills to the developers can allow a single developer to take a unit of work from start to finish. The test specialists can support the most complex cases while continuing to build test-related skills among the developers.

Regardless of the approach that you take, if you start thinking about how much time or effort it will take for the team to finish the work, you'll probably start seeing better Sprint Planning events that let you more accurately forecast the work needed to achieve the Sprint Goal.

Goog morning guys, thanths for your help, i will check with my team yours propositions.