Automation Basics for Manual Testers Interview Questions for Software Testing
33 Automation Basics for Manual Testers questions with answers for software testing roles — 9 easy, 16 medium, 8 hard.
About Automation Basics for Manual Testers
Manual testing interviews increasingly ask how you would move into automation. This topic covers what to automate, locators, waits, the Page Object Model, flaky tests, data-driven tests, simple Playwright, Selenium and pytest scripts, CI suites, Git basics and realistic ROI. You are not expected to be an expert, but you should show you understand how automation works and where manual testing still matters.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What is test automation and what problems does it solve?
Test automation means using scripts and tools to run tests, compare results and report them without a person doing each step. It solves slow and repetitive regression, gives fast feedback on every code change in CI, runs the same checks exactly the same way every time and covers many data combinations. It does not replace thinking: exploratory testing, usability judgement and new feature testing still need manual testers.
02
Which test cases are good candidates for automation?
Good candidates are stable, repeatable and high value: smoke tests, regression of core flows such as login and checkout, data-driven checks with many inputs, API tests and cross-browser runs of the same flow. Poor candidates are features still changing every sprint, one-time tests, tests needing human judgement like look and feel, and flows that are hard to make reliable, such as real OTP or CAPTCHA. Start with what runs most often.
03
What is a locator and what types of locators exist?
A locator tells the automation tool how to find an element on the page so it can click, type or check it. Common types are ID, name, CSS selector, XPath, link text, and in modern tools role-based locators such as a button with name Login, plus label, placeholder and test ID locators. A good locator is unique, readable and unlikely to change when the page design changes.
A fixed sleep, such as waiting five seconds, is either too long, which makes the suite slow when the page loads in one second, or too short, which makes the test fail when the server is slow. Both waste time and cause flaky results. Instead, wait for a real condition: an element to appear, a network response to finish or a loading spinner to disappear. Modern tools do much of this automatically.
05
Write a basic Selenium test in Python that opens a page and checks its title.
An assertion is the check in an automated test that compares the actual result with the expected result and fails the test if they differ, like the expected result column in a manual test case. A good assertion checks the outcome that matters to the user, such as the order confirmation number appearing, not just that a page loaded. It should be specific, give a clear failure message and avoid fragile details like exact timestamps.
07
Write a Gherkin scenario for applying a valid coupon at checkout.
Feature: Coupon at checkout
Scenario: Valid coupon reduces the total
Given I am logged in with 1000 rupees of items in my cart
And the coupon 'SAVE10' gives 10 percent off
When I apply the coupon 'SAVE10'
Then the discount shown is 100 rupees
And the order total is 900 rupees
08
Which basic Git commands should a manual tester learn before working on automation?
Start with: git clone to copy the test repository; git pull to get the latest changes; git checkout -b feature/login-tests to create a branch; git status and git diff to see changes; git add and git commit -m to save work with a message; and git push to send the branch so you can raise a pull request for review. Also learn to resolve simple merge conflicts and never commit passwords.
09
Tell me about a time you started learning automation while working as a manual tester.
Situation: our regression took three days every release. Task: I wanted to help but knew only manual testing. Action: I spent an hour daily learning Python and Playwright, automated the login and search smoke cases first and asked a developer to review my code each week. Result: in two months my scripts ran in CI on every build, saving about a day per release, and I moved into a hybrid QA role.
10
How do Selenium, Playwright and Cypress differ at a high level?
Selenium is the oldest, uses the WebDriver standard, supports many languages like Java, Python and C# and every major browser, and is common in older enterprise suites. Playwright supports TypeScript, Python, Java and .NET, runs Chromium, Firefox and WebKit, and has built-in auto-waiting, tracing and parallel runs. Cypress runs inside the browser with JavaScript or TypeScript, has a friendly runner and is popular with front-end teams.
11
Why are stable locators like data-testid or roles preferred over position-based XPath?
A position-based XPath such as /html/body/div[3]/div[2]/button breaks whenever a developer adds a wrapper div or reorders the layout, even though the feature still works. That creates false failures and maintenance work. Locators based on a dedicated data-testid attribute or the accessible role and name, like a button named Submit, stay valid through design changes and describe intent clearly. Testers should ask developers to add test IDs.
12
Write a CSS selector and an XPath for a Login button that has the attribute data-testid='login-btn' and the text Login.
/* CSS selector using the test id */
button[data-testid='login-btn']
// XPath using the test id
//button[@data-testid='login-btn']
// XPath using the visible text
//button[normalize-space()='Login']
13
What are implicit waits, explicit waits and auto-waiting?
An implicit wait, in Selenium, sets a global time the driver keeps retrying to find any element before failing. An explicit wait waits for a specific condition, such as an element being clickable or a spinner disappearing, and is more precise. Auto-waiting, built into Playwright and Cypress, automatically waits for elements to be visible, enabled and stable before acting. Mixing implicit and explicit waits in Selenium can cause unpredictable delays.
The Page Object Model is a design pattern where each page or major component gets a class that holds its locators and actions, such as LoginPage with a login method. Tests call these methods instead of using locators directly. When the login button changes, you update one place instead of fifty tests. Tests become readable, like steps a manual tester would write, and duplication drops. Keep assertions mostly in tests, not page objects.
15
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
A flaky test passes and fails on the same code without any change. Common causes are timing problems such as fixed sleeps or missing waits, tests depending on each other or on shared data, unstable locators, animations, third-party services, test order in parallel runs and environment issues like slow servers. Flaky tests destroy trust in the suite, so teams quarantine them, find the root cause and fix it rather than adding retries forever.
Data-driven testing runs the same test steps many times with different input and expected values taken from a table, CSV, JSON or spreadsheet. For example, one login test can run with valid users, locked users, wrong passwords and blank fields. It reuses the logic, makes adding cases easy and maps well to equivalence partitioning and boundary values from manual design. Tools support it through parameterised tests, such as pytest.mark.parametrize.
18
How do you convert existing manual test cases into automated scripts?
Pick a small set of stable, high-value regression cases first. Review each one: make steps precise, remove judgement-based checks and define clear expected results. Prepare test data that the script can create and clean up. Build reusable page objects and helpers for common steps like login. Automate, run several times to confirm stability, then link each script to its manual case ID and mark the manual case as automated.
19
What is the difference between UI automation and API automation, and which gives faster feedback?
UI automation drives the browser or app like a user, so it checks the full experience but is slower and breaks more often with design changes. API automation sends requests directly to services and checks responses, which is much faster, more stable and can run before the UI exists. API tests give faster feedback, so teams place most business rule checks at the API level and keep a smaller set of UI journeys.
20
Write a pytest test using requests that checks a GET call returns 200 and a non-empty list.
Stop using the dynamic ID. Look for a stable alternative: the element's role and visible name, its label, a stable attribute, or a relative locator based on a nearby fixed element. The best long-term fix is asking developers to add a data-testid attribute. Avoid partial matches on random strings, which can break again. Then update the locator in the page object so every test using it is fixed at once.
22
Managers say the automation test report is hard to understand. What should a useful report include?
A useful report shows total tests run, passed, failed and skipped, the run time, the environment, build number and browser. For each failure it should show the test name, the failing step, the error message, and a screenshot, video or trace, plus logs. Trends across runs help spot flaky tests. Linking failures to Jira bugs or manual case IDs helps managers see real product risk, not just numbers.
Visual regression testing takes screenshots of pages or components and compares them with approved baseline images to detect unexpected layout, font, colour or spacing changes that functional assertions miss. When a difference crosses a threshold, a person reviews it and either accepts the new baseline or logs a bug. Dynamic content like dates and ads must be masked, and the same browser and screen size must be used to avoid noise.
24
How do you capture screenshots, videos and traces when an automated test fails?
Most frameworks support this through configuration. In Playwright, set screenshot to only-on-failure, video to retain-on-failure and trace to on-first-retry in the config, then open the trace viewer to step through actions, network calls and the page state. In Selenium, call save_screenshot in a teardown hook when a test fails. Store these artefacts in CI so anyone can debug the failure without rerunning it.
25
Describe a time an automated test caught a regression that manual testing would have missed.
Situation: a small tax rounding change was made late on a Friday. Task: no manual regression was planned for pricing. Action: our nightly API suite failed one data-driven case where a 3-item cart was off by one rupee; I checked the trace, reproduced it manually and logged it with the failing input. Result: it was fixed before release, and the team agreed to keep pricing tests in the pull request suite.
26
An automated test passes on your laptop but fails in the CI pipeline. How do you troubleshoot?
Check the CI logs, screenshots, video or trace to see exactly where it failed. Then compare the environments: headless versus headed browser, screen size, browser version, time zone, environment URLs and secrets, test data and network speed. Run the test locally in headless mode with the CI settings. Common causes are timing, missing data in the CI environment and tests depending on run order. Fix the cause, not with a sleep.
27
How do you decide which automated tests run on every pull request and which run nightly?
Pull request checks must be fast, usually under ten to fifteen minutes, and highly reliable, so they include unit tests, API tests for changed services and a small UI smoke set of critical flows. The full UI regression, cross-browser runs, long data-driven suites and performance checks run nightly or before release. Tag tests by suite, measure run times and flakiness, and move tests between suites based on value and speed.
28
Leadership asks whether test automation is worth the investment for your project. How do you estimate the ROI?
Compare cost and savings over time. Cost includes building scripts, framework setup, tools, CI infrastructure and ongoing maintenance, often a large share of total effort. Savings include manual execution hours saved per run multiplied by runs per year, earlier bug detection and faster releases. For example, a 40-hour manual regression run every two weeks saves about 1000 hours a year. Tests that run rarely or break often may never pay back.
29
Your team has 500 manual regression test cases and wants to start automating. Where do you start?
Do not automate all 500. First clean the suite: remove duplicates and outdated cases. Rank the rest by business risk, run frequency and stability. Start with a smoke set of 20 to 30 critical journeys and move rule-heavy checks to the API level. Choose a tool that fits the team's skills, build a simple framework with page objects and CI runs, then expand in batches while tracking time saved and flakiness.
30
A manager wants 100 percent test automation. How do you respond?
I agree with the goal of faster and more reliable testing, but explain that 100 percent is neither possible nor useful. Exploratory testing, usability, visual judgement and brand-new features need people, and some flows like real payments or OTP are costly to automate reliably. I would propose clear targets instead, such as automating all critical regression and smoke flows, with metrics like regression time cut from three days to four hours.
31
Your automated tests pass one by one but fail randomly when run in parallel. How do you fix the test data so tests are independent?
Each test should create the data it needs, usually through an API or database helper, use unique values such as an email with a timestamp, and clean up afterwards. Avoid tests that depend on data made by another test or on a shared account other tests change. For fixed reference data, seed it before the suite runs. Independent data allows tests to run in parallel and in any order without random failures.
32
Your team wants to use an AI tool to generate test cases and automation scripts. What benefits and risks do you point out?
AI assistants can draft test cases from requirements, suggest edge cases, generate first versions of scripts and test data, and some tools self-heal locators when the page changes. Risks are confident but wrong output, tests that assert the wrong behaviour, hidden locator changes that mask real bugs and leaking confidential data into external tools. Treat AI output like a junior's draft: review it, run it and keep human judgement on what matters.
33
Tell me about a time you worked with developers to make an application easier to automate.
Situation: our UI scripts broke almost every sprint because of generated IDs and CSS class changes. Task: as the QA lead I needed stable tests. Action: I showed developers the failure history, proposed adding data-testid attributes and accessible labels to key components and added a short checklist to the pull request template. Result: within two sprints locator-related failures dropped by most of the previous level and maintenance time fell sharply.
Frequently asked questions
How important is Automation Basics for Manual Testers in Software Testing interviews?
Manual testing interviews increasingly ask how you would move into automation. This topic covers what to automate, locators, waits, the Page Object Model, flaky tests, data-driven tests, simple Playwright, Selenium and pytest scripts, CI suites, Git basics and realistic ROI. You are not expected to be an expert, but you should show you understand how automation works and where manual testing still matters.
How should I use the Automation Basics for Manual Testers sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.