Manual QA tester to FDE: from test cases to automated checks

What you bring from the test team

Before the questions, take stock of the artefacts you have produced for years:

• Test cases and test plans — preconditions, steps, expected result. That is a specification of behaviour.
• Bug reports — steps to reproduce, environment, severity, screenshots. FDEs write these for client issues constantly.
• Requirement traceability matrix — which requirement each test covers. Close to how acceptance criteria are tracked on a client project.
• Regression suites — the list of things that must keep working after every change.
• UAT sign-off sheets — working directly with business users to confirm a system does what they need.

What you usually have not done: written production code, designed an API, deployed a service, or worked with language models. That is the gap, and no amount of testing experience covers it. It takes months of deliberate practice.

The interview bank

"You've only tested software. Why should we trust you to build it?"

"I agree that testing is not building, and I've spent the last several months learning Python, SQL and API basics to close that gap. What testing gave me is the habit of asking how something breaks before it ships. My first project shows both: I wrote a small service, then converted my own manual test cases for it into automated checks that run on every change. I can walk you through the code and the failures the tests caught."

"How would you test a feature that uses a language model, where the answer changes each time?"

"I wouldn't test for an exact string. I'd build a golden set of inputs where I know what a correct answer must contain or must not contain — for example, the right policy clause, no invented refund amount — and check each response against those rules. I'd track the pass rate over the whole set rather than one run, and I'd include inputs designed to trick it, like a question outside the documents it has access to, where the correct behaviour is to say it doesn't know."

"A client says the system is broken. What do you do in the first hour?"

"Reproduce it before touching anything. I'd get the exact input, time, user and environment, just as I would for a bug report, and check whether it's the system, the data or the client's expectation. Then I'd tell the client what I've confirmed and what I haven't, with a time for the next update. Most of my QA work was exactly that loop, just with an internal developer instead of a client."

"What's the difference between a test passing and a feature being ready?"

"A passing test only proves the cases we thought of. Readiness also depends on the cases we didn't — real data volumes, bad inputs, permissions, what happens when a dependency is down. In UAT I often found issues that every test case missed because a real user did things in an order nobody planned. That's why I'd want to watch a client use a deployment before calling it done."

The first project: test cases become code

Take a small, realistic function — say, one that decides whether an order is eligible for a refund under a written policy — and express your manual test cases as a data table that a script runs. Then add a second harness for an AI-drafted reply, using rules rather than exact matches. Everything below is synthetic.

from datetime import date

def refund_eligible(order_date, request_date, item_opened, amount):
    """Synthetic policy: refunds within 7 days; opened items not refundable;
    orders of ₹50,000 or more need manual review."""
    if amount >= 50000:
        return "manual_review"
    if item_opened:
        return "no"
    return "yes" if (request_date - order_date).days <= 7 else "no"

# Manual test cases, now as data: (id, inputs, expected)
cases = [
    ("TC01", (date(2026, 9, 1), date(2026, 9, 5), False, 1200), "yes"),
    ("TC02", (date(2026, 9, 1), date(2026, 9, 8), False, 1200), "yes"),   # boundary: day 7
    ("TC03", (date(2026, 9, 1), date(2026, 9, 9), False, 1200), "no"),    # day 8
    ("TC04", (date(2026, 9, 1), date(2026, 9, 2), True, 1200), "no"),
    ("TC05", (date(2026, 9, 1), date(2026, 9, 2), False, 50000), "manual_review"),
]
failed = [cid for cid, args, exp in cases if refund_eligible(*args) != exp]
print("policy tests:", "all passed" if not failed else f"failed {failed}")

# Rule-based checks for an AI-drafted customer reply (stub responses shown)
def check_reply(reply, must_include, must_not_include):
    text = reply.lower()
    return all(p in text for p in must_include) and not any(p in text for p in must_not_include)

golden = [
    ("Your order is within our 7-day window, so a refund can be processed.",
     ["7-day"], ["guarantee", "₹"]),
    ("We guarantee a full refund of ₹5,000 immediately.",
     ["7-day"], ["guarantee", "₹"]),
]
results = [check_reply(r, inc, exc) for r, inc, exc in golden]
print(f"reply checks passed: {sum(results)}/{len(results)}")

The second stub reply fails, as it should: it invents a promise and an amount the policy never mentioned. Explaining why that check exists is the most FDE-like part of the project. Extend it by putting the function behind a small web API, running the tests automatically on each commit, and writing a short deployment note for a hypothetical client.

Implementation engineer first, SDET as the bridge

A tester moving towards FDE is often best placed first as an implementation engineer, solutions engineer or junior forward deployed engineer, where client-facing validation is part of the job. QA automation or SDET roles are a reasonable bridge if you want to build coding depth before facing clients. Check which engineering skills your resume already evidences with the free skill check, and read what a forward deployed engineer does if you have not already.

The FDE for Freshers programme starts from software foundations, so a tester without development experience does not have to skip steps.