Skip to content
Get Daily Deck Careers

Quality Assurance and Testing

Finding out what breaks before users do. Still one of the most realistic first jobs in tech, and a well-worn route into several others.

Last reviewed 6 August 2026.

What the job is actually like

Working out how a feature could fail, then checking whether it does. Writing and maintaining automated tests, investigating failures that may be real bugs or may be the test being wrong, and reporting findings in a way developers can act on. There is repetitive work, particularly early, and the interesting part is the reasoning about what is worth testing at all.

This suits you if

  • You are the person who instinctively tries the odd input to see what happens
  • You are careful and can be precise about what you observed versus what you assumed
  • You are comfortable delivering unwelcome news politely and repeatedly

Probably not, if

  • You would resent work that is often invisible when done well
  • You want to build features rather than examine them

A roadmap

Lengths are what this typically takes alongside other commitments, not a promise. The "prove it" line matters more than the timeline — that is what someone hiring will look at.

  1. Testing as thinking

    Boundary cases, equivalence classes, and the discipline of asking what assumptions a feature is making. This is the part that is actually hard; the tooling is not.

    Typically
    One to two months
    Prove it
    A test plan for a familiar app that finds cases its developers plainly did not consider.

  2. Reporting properly

    Reproduction steps, expected versus actual, environment, severity. A bug report that cannot be reproduced is wasted work for everyone.

    Typically
    Weeks, then permanently
    Prove it
    A report someone else could follow to reproduce the problem first time.

  3. One programming language

    Python or JavaScript, to the level of writing and debugging your own code. Manual-only testing roles are shrinking; this is the step that keeps this path open.

    Typically
    Two to four months
    Prove it
    Automating a check you previously did by hand.

  4. Test automation

    A UI automation framework such as Playwright, plus API testing. Also learning what not to automate — brittle tests that fail randomly are worse than no tests.

    Typically
    Three to five months
    Prove it
    A small automated suite against a real site that passes and fails for the right reasons.

  5. Into the pipeline

    Getting tests running automatically on every change, and understanding why a test that only runs on your machine has limited value.

    Typically
    One to two months
    Prove it
    Tests running in CI on every commit, with results someone else reads.

What AI has changed

Generating test cases and boilerplate test code is fast now, and simple scripted manual testing is under real pressure. But generated tests have a particular weakness worth understanding: they tend to test that the code does what it does, rather than what it should do, so they pass while the feature is wrong. Deciding what is worth testing, recognising that a passing suite is giving false comfort, and exploratory testing — where a person pokes at something with curiosity and a hypothesis — have not been automated. Manual script-following as a career is closing; testing as a thinking discipline is not.

Common mistakes

  • Staying purely manual. This is the single biggest risk to a long career on this path.
  • Automating everything possible rather than what is valuable, producing a slow, flaky suite nobody trusts.
  • Writing bug reports that cannot be reproduced.
  • Treating a green test suite as proof of quality rather than absence of one kind of evidence.
  • Regarding QA as a lesser role rather than a specialisation, which shows in the work.

This is included because it is realistic. Graduates who cannot get an engineering offer often can get a testing one, and it is a genuine job rather than a consolation prize.

It is also a door. People move from testing into development, DevOps and product regularly, because a tester who has learned to automate has already proved they can code, and already understands the product better than most new hires. If you take it, take it with the intention of learning to write code, not only to run through scripts.

This is one view, not the answer

Career advice is opinion shaped by a moment in time, and this page says which moment. Weigh it against people actually doing the job now — their account of the last six months is worth more than any guide.