Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Thoughtworks hiring for Software Testing roles
Thoughtworks is a global technology consultancy known for agile software delivery, continuous delivery and its Technology Radar publication. It works on custom software, data platforms and digital transformation for enterprise clients. In India it hires for developers, quality analysts, data engineers and data scientists. Teams usually work closely with client engineers.
For Software Testing roles, this Thoughtworks practice set focuses most on Agile, SQL and API Testing (8), Bug Life Cycle and Jira (6), Performance and Security Basics (5), Test Case Design (5). It has 3 easy, 33 medium, 4 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
Chicago, Illinois, USA
Main India offices
Pune, Bengaluru, Chennai, Gurugram, Hyderabad
Thoughtworks Software Testing interview process
Online coding assessment
Code pairing round
Technical interview
Cultural fit or social change round
Leadership round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for ThoughtworksStart 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.
A performance baseline is a set of measurements of the current system under a known load, such as response times, throughput, error rate and resource usage. Every new build or release is compared with it to spot regressions. For example, if the checkout API had p95 of 800 milliseconds at 200 users last release and now shows 1.5 seconds, the change needs investigation. A benchmark compares against an industry or competitor standard.
Android phone makers ship their own skins and settings on top of Android, so the same app can behave differently. Common problems are aggressive battery savers that kill background tasks and delay notifications, different permission screens, custom fonts and display scaling, camera differences and modified WebViews. Pick devices from the brands most used by your audience and test background work, notifications, camera and layout on each.
04
How do you test form accessibility, including labels and error messages?
Check that every field has a visible label tied to it, so clicking the label focuses the field and a screen reader announces it. Required fields must be indicated in text, not only by colour or an asterisk without explanation. Submit with errors and check that messages are specific, appear next to the field, are announced by the screen reader and focus moves to the first error. Also check autocomplete for name, email and address.
05
Tell me about a time you designed tests for a feature with unclear requirements.
Model answer: Situation: I got a story for 'flexible EMI options' with only one line of description. Task: test it within the sprint. Action: I listed my assumptions on tenure, interest and rounding, reviewed them with the product owner in a 15-minute call, and wrote test cases only after we agreed. Result: three rules were changed before coding finished, and the feature passed UAT without rework.
06
How do you handle a bug found late in a release cycle?
Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.
08
A training portal is adding recorded video lessons and podcasts. What accessibility checks do you run?
Check that prerecorded videos have accurate, synchronised captions, not just auto-generated ones with errors, and that audio-only content like podcasts has a transcript. Important visual information that is not spoken should have audio description or be covered in the transcript. Media should not autoplay with sound, and player controls must work by keyboard and be announced by screen readers. Also check that nothing flashes more than three times per second.
09
Write a JQL query for open high or highest priority bugs in the current sprint of project PAY.
project = PAY
AND issuetype = Bug
AND statusCategory != Done
AND priority in (Highest, High)
AND sprint in openSprints()
ORDER BY priority DESC, created ASC
10
Your automated accessibility scan shows zero errors. Is the page accessible?
Not necessarily. Automated tools catch only a part of WCAG issues, such as missing labels and contrast. A clean scan still needs manual checks: keyboard-only navigation, focus order, a screen reader pass, meaningful alt text and link names, error handling, zoom and reflow and dynamic content. Report the result as 'no automated violations found' and add the manual checklist outcome before claiming conformance.
11
An API returns 200 OK but the body contains an error message. Is that a bug?
Usually yes. Status codes should reflect the result so clients and monitoring can react correctly; an error with 200 can hide failures and break retries. A validation error should return 400 or 422, a missing resource 404 and a server failure 500. Check the API contract first: some legacy APIs document this pattern. If it is not documented, log it as a defect with the request and response attached.
Build a permission matrix with roles as rows and actions as columns, such as create, edit, delete, publish and view, marking allowed or denied from the requirement. Write a positive test for each allowed cell and a negative test for each denied one. Test through the UI and also call the APIs directly, because hidden buttons are not security. Check role changes take effect immediately and that users cannot access other users' data by changing IDs.
In sprint planning, review each story's acceptance criteria and estimate test effort, including test data and regression. Write test cases in the first days while development starts. Ask for early builds so testing is spread across the sprint, not crowded at the end. Keep time for regression and bug retesting in the last two or three days. Track progress on the board and raise risks in stand-up.
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.
JSON schema validation checks that a response has the expected structure: required fields are present, data types are correct, formats like email or date are valid and no unexpected fields appear. Instead of checking only one value, it protects against contract changes that break the app. In Postman you can validate a response against a schema in the test script, and run it on every request in a collection.
20
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.
21
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.
22
What is the difference between DELETE and TRUNCATE?
I agree the split with the team at sprint planning. Testing new stories manually comes first because it blocks the sprint goal. I then automate the stable flows from the previous sprint, so scripts are not rewritten while features change. For example, I block two afternoons a week for automation and report progress in stand-up. If a release is at risk, I pause automation and tell the lead openly.
The result is a failure, not a pass. Failed requests often return quickly, so they make response times look better than they are. Check which requests fail and with which errors, such as 500, 503 or timeouts, and when errors started relative to the load level. Look at server logs, connection pool and thread limits. Also confirm the script is not wrong, for example expired tokens or bad test data.
26
Tell me about a time you mentored a junior tester.
Model answer: Situation: a new fresher on my team was writing very long, unclear bug reports. Task: help her improve quickly. Action: I reviewed five of her bugs with her, showed a simple template, paired with her on two exploratory sessions and gave weekly feedback. Result: within a month developers stopped asking her for clarification, and she later found and reported a major session bug on her own.
27
How do you handle it when a reviewer criticises your test cases?
I treat review comments as free help. I ask for specifics if a comment is unclear, fix valid points quickly and explain my reasoning if I disagree, with the requirement in hand. For example, a senior once said my cases missed negative paths; I added them and also made a personal checklist for future reviews. Repeated comments show me a skill gap I should work on, not a personal attack.
Re-check environment, data, browser and steps; check the logs; try the reporter's setup; add video and console logs; mark it 'cannot reproduce' only after discussing with the developer, and keep monitoring.
-- Compare counts and sums side by side; both columns must match
SELECT
(SELECT COUNT(*) FROM staging_orders) AS src_count,
(SELECT COUNT(*) FROM dw_orders) AS tgt_count,
(SELECT SUM(amount) FROM staging_orders) AS src_amount,
(SELECT SUM(amount) FROM dw_orders) AS tgt_amount;
The tests verified the specification but did not validate the user experience. The test cases probably checked only functional outcomes and missed usability: unclear labels, too many steps or poor error messages. Next time, add usability heuristics to reviews, do exploratory sessions as a real user persona and involve users in UAT or demos. Log the current feedback as improvement items with clear examples.
-- orphan orders indicate a broken foreign key or bad data load
SELECT o.order_id, o.customer_id
FROM orders o
LEFT JOIN customers c ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL;
Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).
36
A user updates their phone number in the app, but the old number still appears in reports. What do you check?
First query the main users table to see whether the update was saved. If it was, check where the report reads from: a view, a reporting copy, a cache or a nightly ETL table. The report may simply be stale until the next refresh, which may be by design. If the main table still has the old value, check the API request, the update query and any errors in logs, then log a bug with both query results.
Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.
38
How do you test API error handling for invalid input?
Send requests with missing required fields, wrong data types, values beyond limits, invalid formats such as a bad email, unknown fields and an empty or malformed JSON body. The API should return a 4xx code such as 400 or 422, a clear error message that names the field, and no stack trace or database details. Also check that nothing was partly saved in the database after the failed request.
39
Product is running an A/B test on the checkout button. What does QA need to verify?
QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.
40
A manager says the app has 50,000 daily users, so the load test must run 50,000 virtual users at once. How do you respond?
Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.
Tips to crack the Thoughtworks Software Testing interview
Practise pair programming with test-driven development, since Thoughtworks interviews often include coding together with an interviewer.
Read the latest Thoughtworks Technology Radar and form opinions on a few tools or techniques it lists.
Prepare to discuss social and economic justice values, which Thoughtworks openly includes in its culture discussions.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Thoughtworks interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Thoughtworks Software Testing interview?
Candidates usually go through 5 stages: Online coding assessment; Code pairing round; Technical interview; Cultural fit or social change round; Leadership round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Thoughtworks Software Testing interview?
This practice set leans on Agile, SQL and API Testing (8), Bug Life Cycle and Jira (6), Performance and Security Basics (5), Test Case Design (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Thoughtworks interviewers ask you to walk through real work.
Are these the exact questions asked at Thoughtworks?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like Thoughtworks's. They are not a leaked or verified list of past questions.
Where does Thoughtworks hire Software Testing professionals in India?
Thoughtworks has large teams in Pune, Bengaluru, Chennai, Gurugram, Hyderabad. Openings and locations change often, so check the Thoughtworks careers page and filter by city and experience.