How much code do you write as a tester?
The best tester I've worked with wrote quite a bit of code. He did two things:
1) If something crashed, he'd actually debug it a bit and try to produce a minimal test case rather than just emailing us a core dump.
2) He'd write acceptance tests against components. Give him a specification, or a newly-designed API, and he'd write his own test cases in addition to running the ones he was told to. Having a separate person write tests often resulted in things being tested that neither the coder nor the designer of the interface would have thought to test: the coder is writing unit tests, and the designer may be more at the level of integration tests.
Also, having someone coding to the interface sometimes threw up problems in the documentation that the implementer didn't notice. For instance, if it gave the implementer too much freedom for the API to be really flexible, but it happened to suit whoever was the first user of the component, then when the tester came along and tried to achieve something slightly different with it, he'd come back with criticism of the interface itself.
In the long run, it was really useful having these kinds of tests in addition to the top-level integration and QA that a test department might more traditionally do. Also, his bug reports were on average more surprising and yet easier to investigate than anyone else's, which is exactly what I want as a developer.
He didn't switch to developer before he retired, although I think he might have been a developer in previous jobs, I can't remember.
But, given that you have some ability, you might find that using it more as a tester will first make you a better tester, and perhaps open some opportunities there, and second might get you into the swing of writing code, which could make a transition to development easier. If your employer can see that you're writing solid code in test suites, and that you understand the design and architecture of the product, you might have a decent chance of a sideways move.