QA Engineer Career Guide: Manual Testing, Automation, and SDET Roles

QA postings in India range from running a client's regression sheet by hand to building test infrastructure that a whole engineering organisation depends on, and the title rarely says which. Learn to tell manual, automation, and SDET roles apart and you can prepare for the right interview, shape your resume to fit, and plan a realistic move up.

One title, three jobs: manual tester, automation engineer, SDET

A manual or functional tester reads requirements, writes and executes test cases, logs defects with clear reproduction steps, and works through regression cycles before each release. An automation engineer turns the repeatable part of that into UI and API suites, runs them in CI, and spends a good part of each week deciding whether a red build means a real bug, a broken environment, or a flaky test. An SDET (software development engineer in test) is a developer whose product is test infrastructure: frameworks, test data services, mocks, and performance harnesses. SDET loops often include the same coding rounds developers face.

Here is how a sprint runs for an automation engineer. In planning, you question acceptance criteria. What happens if the coupon expires while the user is on the payment page? Mid-sprint, you write API tests as soon as endpoints exist and UI tests once screens stop changing. Most mornings start with triage of the overnight run. Near release you join a bug bash, review open defects with the product owner, and recommend go or no-go based on risk rather than a pass count.

QA is most often confused with development and DevOps. Developers also write tests, but mostly unit tests for their own code; QA looks across features and asks what breaks for the user when the pieces meet. DevOps engineers own the delivery pipeline; QA decides which tests run inside it and which failures block a release.

Test design first, then the tools

Tools change every few years. Choosing the few tests that cover most of the risk does not, and panels probe that skill by name:

• Equivalence partitioning: group inputs that should behave the same way and test one from each group.
• Boundary value analysis: if an age field accepts 18 to 60, test 17, 18, 60, and 61, because off-by-one mistakes live at the edges.
• Decision tables: list combinations of conditions (membership tier, coupon, cart value) with the expected result of each.
• State transitions: can a cancelled order be shipped? Can a refunded payment be refunded twice?
• Risk-based testing: rank features by how likely they are to fail and what a failure costs, then spend your time in that order. Payments and login come before profile pictures.

Tool	Where you meet it	What panels expect you to know
Selenium WebDriver	Long-running enterprise and services projects, usually Java with TestNG or Python with pytest	Explicit waits, the Page Object Model, Selenium Grid for parallel runs
Playwright	Newer web projects, often in TypeScript	Auto-waiting, role-based locators, traces for failed tests, runs across browser engines
Cypress	Frontend-heavy JavaScript or TypeScript teams	It runs inside the browser, which makes debugging pleasant and multi-tab flows awkward
Postman, REST Assured	API testing, exploratory to automated	Collections, environments, Newman for CI runs; REST Assured's given/when/then style in Java
JMeter	Load and performance testing	Thread groups, ramp-up, assertions, and non-GUI mode for real load

Around these, postings ask for SQL to check the data behind a screen, Git, a CI tool such as Jenkins or GitHub Actions, and a test management tool. Differentiators include Appium for mobile, contract testing, accessibility checks, and enough Docker to stand up a test environment yourself. Many services firms value the ISTQB Foundation Level certificate; product companies seldom screen on it.

Seniority in QA and how employers differ

• 0–2 years (Trainee, Associate QA Engineer, Test Engineer). Clear test cases and bug reports, domain knowledge, regression runs, first scripts. A good bug report, with exact steps, expected and actual results, environment, and logs or a screen recording, is the quickest way to earn a developer's trust.
• 3–5 years (Senior QA Engineer, Senior Automation Engineer, SDET II). Own automation for a module, mentor juniors, decide what not to automate, and wire suites into CI while keeping them fast and green.
• 6+ years. The track splits. QA Lead and Test Manager roles own strategy, estimates, release sign-off, and people. Staff SDET and quality architect roles own frameworks across teams, test environments, and measures such as defects that escaped to production.

Services companies often run testing as a separate practice, with formal test plans, traceability matrices, client-approved cases, and more manual roles. Product companies employ fewer manual testers: developers own unit tests, and QA engineers or SDETs focus on automation and release quality. A startup may have one tester across several teams, so exploratory skill counts for more than documentation. GCCs in banking, insurance, and healthcare add audit trails and validation evidence, because regulators can ask how a release was tested.

What QA interview loops look like

1. Screening test. Aptitude and basic programming at services firms; a coding test for SDET roles.
2. Testing fundamentals. Design techniques, the defect life cycle, severity versus priority, and writing test cases for a feature live.
3. Automation round. Code in Java, Python, or TypeScript (string and collection problems are common), then questions on your framework, locators, and waits.
4. Coding and design (SDET roles). Developer-style problem solving, sometimes with a design question such as a test data service.
5. Take-home (some employers). Automate a few flows on a demo app and explain your structure.
6. Manager and HR. A bug you caught that others missed, a disagreement with a developer over severity, and how you decided a release was safe.

Exercises and questions interviewers use for testers

1. "Write test cases for the coupon field on this checkout page." Strong answers cover valid, expired, and invalid codes; case and whitespace; minimum cart value boundaries; stacking with other offers; removing the coupon; two tabs applying it at once; and whether the server re-checks what the browser sends.
2. "The upload field accepts PDFs up to 5 MB. What do you test?" Exactly 5 MB and just over it, an empty file, an executable renamed to .pdf, a corrupt PDF, a dropped connection mid-upload, and whether the server enforces the limit as well as the browser.
3. "Walk me through your framework as if I have to maintain it tomorrow." Layers, configuration, test data, reporting, and why each exists.
4. "This locator breaks every sprint: //div[3]/div/span[2]. Fix the strategy." Prefer roles, labels, or dedicated data-testid attributes, and ask developers to add test IDs where they are missing.
5. "A test passes locally and fails one CI run in ten. How do you investigate?" Fixed sleeps, shared test data, order dependence, slower CI machines, animations. Retries can confirm flakiness; they do not fix it.
6. "Which tests would you deliberately not automate?" One-off checks, screens still being redesigned, and judgements about usability.
7. "Test a POST /orders endpoint." Status codes, response schema, authentication, duplicate submissions, malformed payloads, and side effects in the database.
8. "Plan a load test for a flash sale." Workload model, ramp-up, think time, test data, percentiles rather than averages, and an environment close to production.
9. "Give an example of a high-severity, low-priority defect." A crash in an admin report used once a year is the usual answer; a misspelt company name on the home page is the classic opposite.

Across all of these, panels listen for whether you start from risk and the user, ask clarifying questions before listing cases, and can explain why each test exists.

Resume bullets that show testing judgement

Lead each role with the domain and the kind of testing you did, then show scale and outcome. A skills line reading "manual, functional, regression, smoke, sanity, and UAT testing" says little; one bullet about a defect that would have cost real money says a lot. The ATS-friendly resume guide covers layout and keywords.

Sample bullets (the figures are examples, not benchmarks):

• Built a Playwright and TypeScript suite of 180 UI and API tests for a loan application flow, running in parallel on every pull request in GitHub Actions; regression dropped from two days of manual effort to about 25 minutes.
• Designed boundary and decision-table cases for an EMI calculator across 12 loan products and found 9 rounding defects before UAT, including one that overcharged interest after part-prepayment.
• Stabilised a nightly Selenium and TestNG run by replacing fixed sleeps with explicit waits, isolating test data per thread, and quarantining unstable tests with tracking tickets, until the team trusted the suite as a release gate.

What weakens a QA resume:

• "Designed a framework" when you added tests to an existing one. You will be asked about decisions you never made.
• Selenium listed without the language you used it with.
• No numbers at all: how many tests, how often they run, how long regression takes.
• No domain. Experience testing banking, e-commerce, or healthcare software is a selling point.

From manual testing to automation in practical steps

Most people make this move inside their current company first, so start where you are:

1. Learn one language properly, ideally the one your project already uses. Java is common on services projects and TypeScript on newer product teams. Loops, collections, classes, and exceptions come before any tool.
2. Automate API tests first. They are quicker to write and far less flaky than UI tests. Start in Postman, then move to REST Assured or pytest with the requests library.
3. Add UI automation with page objects and explicit waits.
4. Put it in CI with Git, a pipeline, and a report someone else can read.
5. Offer to automate part of your project's regression pack. An internal win becomes a resume bullet and a reference.

Projects that impress a panel:

• A framework for a small open-source web app you run in Docker, with page objects, data-driven tests, parallel CI runs, and a README explaining each design choice.
• An API suite for a public API with schema validation and negative tests, plus a short note on the inconsistencies you found.
• A JMeter plan against your own local app, with results and a reasoned guess at the bottleneck.

SDETs often move into software engineering, testers who enjoy pipelines into DevOps, and UI automation specialists into frontend development, where component testing is part of the job.

QA openings and what to do this week

• Read three postings and label each manual, automation, or SDET; how to read a job description covers the signals.
• Practise the coupon exercise aloud against a fifteen-minute timer, asking clarifying questions first.
• Put the domain at the top of each role on your resume and one number in each bullet.
• Working in a services firm and aiming for a product team? Read moving from a service company to a product company.
• Check which automation tools current postings name. uHired's job pages include a live snapshot of the skills postings mention, so you can see whether Selenium, Playwright, or Cypress comes up more where you are applying.

Openings by location: Bengaluru, Pune, Hyderabad, across India, and remote.