I am going to completely disagree with any of the answers here who claim that "QA is where incompetent programmers go".
Testing in the industry is a rapidly evolving beast. There was, perhaps, a time when Quality was solely the realm of folks who clicked on things or manually tested(though I think the attitude that QA is 'failed' devs is still inaccurate.) Today the industry is moving towards test automation but job titles and expectations haven't really caught up.
Automated testing, in it's variety of forms, is in some ways more challenging than software development. Depending on the type of testing being done, QA(or QE as is often being called now) typically must have a really good understanding not only of the product(s) they test, but the products that those targeted products integrate with AND the infrastructure and use cases for all of those products.
When I dev I have a product and a feature to implement(in a very simplistic way.) When a QE is working they have a feature to be tested - but this means they need to consider all of the ways that feature might be used, edge cases, integration points and potential future directions that feature might be used. Additionally they need to keep, in some way, an understanding of their current regression suite(s) and know where this new feature and it's changes should go and what changes need to be made in the regression suite(s) in order to facilitate that. Additionally they need to know the code and environment(infrastructure/platform/etc) well enough to provide useful, meaningful feedback. TL;DR - QE(and much of QA) is no longer pushing a button and saying "Herf Derf this didn't work". Rather QE is writing the frameworks, expectations and doing the ground work to make testing that lets the Devs and Product Owners test stuff themselves.
So QA vs QE. QA is Quality Assurance which is where any of the remnants of manual testers would be. But it's blending with Quality Engineering - where the focus is on developers who can automate complex system interactions in order to provide a health check for any changes in code, any environmental changes or for systems in general. I think there is definitely a stereotype against QA, as evidenced in answers about QA on 'The Workplace' and that may be something you don't want to fight against. In which case, especially if you are implementing automated testing, I would recommend talking to your supervisors about the role 'Quality Engineer' as it tends to convey the technical aspects of the job a bit more.
That being said. Yeah, there are some folks, again as demonstrated any time QA comes up in the various Stackexchange communities, that will think less of you for having anything to do with QA. These often, but not always, are the same folks that think having a separate Quality team test or inspect their code is useless("Because devs can write unit tests!") To be honest, good companies and good people to work for should be interested in what you did rather than a title. If you were training others, doing testing plans and strategies and creating a Quality org from the ground up in your company(or played a part in doing that) and you were working to automate test coverage, triaging, reporting and tools to support that then you've got some serious chops to add to your resume.
Consider, for a moment, the Big 4. They all have pretty serious quality organizations within their company. At least two push to have 2:1 or 1:1 ratio of Dev to QE for all of their products. The other two, from what I know, go with the rough 'rule of thumb' of 4:1(dev:QE). This shows in what they do. They aren't going to look down on you for having 'QA' on your resume especially when it's paired with the work you are doing(which isn't easy by any stretch of the imagination.)
To leave aside my obvious gripes with how folks like to talk about QA. QA is just another role that brings with it challenges that companies are very interested in solving. Having experiences doing that makes you more valuable. Having a background in development(as many QA have and all QE have) means that you are better poised to bring automated solutions to these challenges. QA expands your pool of opportunities, it will only limit it with companies that are uninterested in Quality as a metric for their products and who, thus, place QA experience at a lower 'rank' than developer positions.