Reframing QA or support experience for engineering roles

By forge Research·6 min read·

QA and support experience gets screened out of engineering roles when it reads as manual work. The fix is to lead with the code you wrote, such as test frameworks, automation and tooling, and to describe your title accurately without overstating it.

TL;DRthe 30-second version
  • Automation and test-framework work is read as engineering. Manual testing is not.
  • Moving from QA to development gets harder with each year. Juniors switch most easily.
  • Internal transfers are possible but slow. One large firm made people wait six to twelve months.
  • Describe what you built. Do not change your title to one you did not hold.
Where this comes from
A small number of long discussions about QA, test and support roles between 2021 and 2026, several with hiring managers in them. Most individual questions on this topic never got a public reply. How forge collects this.

Why the screen fails

A QA engineer at a large company applied for backend roles and was rejected at the resume stage each time, and concluded that hiring managers did not see QA as technical. Replies drew a line between two kinds of work. Automation and building test frameworks were viewed favourably. Manual testing was not.

One reply added a caution: a rejection may simply mean other applicants had more directly relevant experience. Reframing helps only if there is real development work to show.

What counts as development work

The test candidates were given for any role with test in the title: does the job involve writing software? If yes, it is an engineering role with a testing focus.

Read as engineeringRead as manual
Writing an automated test suite or frameworkRunning test cases by hand
Building tools the team usesLogging bugs for others to fix
Working in the build and release pipelineFollowing a release checklist
Finding a root cause in the codeReporting that something failed
Scripting a repeated support fixAnswering tickets one at a time

How to write it

  • Lead with code. Put the framework, tool or automation first in each bullet, then what it tested.
  • Name the stack. Languages, test frameworks and pipeline tools, as you would for a development role.
  • Show scale. How many tests, how much time saved, how many releases it covered.
  • Count the experience. A year in an automation role is a year of relevant experience. Say so.
  • Add proof outside work. A side project or open-source contribution in the kind of development you want.

Where the line is on titles

Some replies suggested using a title such as software engineer in test. That is fine if it describes the job and your employer would confirm it. Changing a title to software engineer when you were not one is a different thing: background checks compare titles, and interviewers will ask about the work. Keep the official title and let the bullets show the engineering.

Before you take a QA role

Students weighing a testing internship or graduate offer got consistent advice. Prefer a development role when you have the choice, even at slightly lower pay, because the move across later is hard. In one comparison, commenters favoured a development offer over a testing offer that paid more. One employer paid its testing interns far less than its development interns.

There was a counterview. People from teams with dedicated testers described that work as valued, and automation skills as useful. If you take the role, ask how much of it is writing code and whether people have moved into development from it.

The internal route

Moving teams inside the same employer avoids the resume screen. It can be done, slowly: one large firm required six to twelve months in role and told the current manager. Ask about the transfer policy before you join, and start building relationships with the team you want early.

A caveat

Evidence here is thin and comes mostly from software hiring in Singapore. Views on testing roles differ between employers, and some treat them as a standard route into development.

Related guides

Frequently asked questions

Can I move from QA to software engineering?

Yes, most easily early in your career and when your QA work involved writing code. Candidates described the move as harder with each year in a manual role.

Is SDET experience counted as software engineering experience?

Usually, when the role involved building automation or frameworks. Hiring-side replies viewed automation work favourably.

Should I change my job title on my resume?

No. Keep the title your employer would confirm and use the bullets to show the development work. Background checks compare titles.

Should I take a QA internship if I want to be a developer?

Take a development role if you have one. If not, a testing role with real coding is useful, so ask how much of the work is writing software.

How long before I can transfer internally from QA to development?

It depends on the employer. At one large technology firm the wait was six to twelve months.

Stop reading. Start practising.

Try a few real questions — free.

You know the format now. Reading about the test won't move your score — timed reps will. Do a free diagnostic, earn credits just for signing up, and see exactly where you stand.