You are simply more productive doing things you like.
If you have the option to change the process
Make it smarter and include more of what you do best.
You don't specify the kind of software you are developing, but most testing can and should be automated (for multiple reasons, such as it being a repetitive task, prone to human error, the ability to run functional tests as part of continuous integration and so on).
With regression tests having been automated, the task at hand will be to write new tests for new functionality introduced. This blends testing and development together. If tests are maintained properly and created in a reusable/modular approach, they will become easier to write with new functionality being introduced. In the longer term your team will need to put less time and effort into testing and productivity will increase overall.
If changing the process is not an option
Change your attitude.
Try changing your perspective and understand why testing is a very important part of development. You can try to develop the inner QA in yourself - identify where and why software may break. Many developers simply don't anticipate all possible or likely scenarios. They think of the straight case, where the user is doing the correct thing. Trying to break software, you'll learn how to identify common pitfalls. Then, when writing new code, you'll have these things in mind and your output will be better.
If possible, test features developed by your colleagues and let them test your code. We all tend to be more careful when testing something we created ourselves. This has another positive side - you'll always be on track who wrote what and how it's used. I've been in teams where team members were unaware what their colleagues, within the same team, were doing. With this level of awareness, it'd be easier to switch tasks or pick up a task from where a peer has left it.
Also, testing something you didn't write just the week before will make work feel less repetitive.
Whether or not you can implement automated testing make sure you keep track of the different scenarios you execute. You should do this before even starting to write code - with writing the tests you may discover issues with the requirements given. In many cases the product owner would have not anticipated a given scenario, and you'll be able to clear the requirements with them, so you can eradicate the problem before it even appears.
Nice test case organization will ensure sufficient coverage. You'll be able to track progress, spread work between the members of your team and easily verify something has been tested. Finally, when you need to identify why a bug has made it to production, you'll be able to see where the reason was - whether you made an error during coding or maybe you didn't have this scenario tested.
Note: This is my first answer ever. If you have feedback on how to improve it, please go ahead!