Urban Company Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Urban Company hiring for Software Testing roles
Urban Company is an Indian technology platform that connects customers with trained professionals for home services such as cleaning, beauty, appliance repair, plumbing and painting. It handles booking, pricing, partner training and quality control through its app. It hires software engineers, data analysts, product managers and operations roles, and also operates in a few international markets.
For Software Testing roles, this Urban Company practice set focuses most on Agile, SQL and API Testing (6), Test Case Design (5), Bug Life Cycle and Jira (5), Manual Testing Basics (4). It has 27 medium, 13 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Gurugram, India
Main India offices
Gurugram
Urban Company Software Testing interview process
Online coding or analytics assessment
Technical round 1
Technical round 2 (design or case)
Hiring manager and culture round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Urban CompanyStart 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.
Send and receive text messages and check order and timestamps. Test sent, delivered and read status. Send emojis, long messages, links and attachments within and over the size limit. Check messages sent while offline are queued and delivered on reconnect. Verify blocking a user stops messages. Test notifications when the app is in background. Check chat history after reinstall or on a second device, and that deleted messages disappear for both users if supported.
Testing shows presence of defects, exhaustive testing is impossible, test early, defects cluster, the pesticide paradox, testing is context-dependent and absence-of-errors is a fallacy.
Shift-left means starting testing activities earlier in the life cycle: reviewing requirements, joining design discussions and writing tests before code is complete. A defect found in requirements may cost a short conversation to fix, while the same defect found in production may need a hotfix, data correction and customer support. Testers shift left by asking questions in grooming, defining acceptance criteria and reviewing designs.
Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request to a site, such as changing their email, because the browser automatically includes cookies. Prevention includes anti-CSRF tokens in forms, SameSite cookie settings and re-authentication for sensitive actions. Testers check that state-changing requests fail when the token is missing or reused, and that such actions are not done through GET requests.
07
How do you handle pressure when many bugs are found close to a release?
Model answer: Situation: two days before a release, we found 15 new bugs in checkout. Task: help the team decide what to fix. Action: I stayed calm, retested each one quickly, ranked them by user impact, and shared a clear list in triage with must-fix and can-wait items. Result: we fixed five critical bugs, released on time with documented known issues, and no critical issue reached users.
It means that finding and fixing many defects does not guarantee success if the system itself does not meet user needs. A bug-free product built on wrong or misunderstood requirements is still a failure. For example, a perfectly working report that shows the wrong business metric is useless to the client. This is why testers validate against real user expectations, not just the written specification.
09
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.
10
A form saves names with an apostrophe, like O'Brien, incorrectly or fails to save them. What do you test?
This suggests the input is not handled safely, possibly string-built SQL, which is also a SQL injection risk. Test names with apostrophes, double quotes, Hindi and other Unicode text, emojis, leading spaces and maximum length. Query the database to confirm the exact stored value and character encoding. Then check the value displays correctly everywhere it is read back. Log a high-severity bug and mention the possible injection risk.
11
Tell me about a time exploratory testing helped you find a critical bug.
Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.
12
How do you break a requirement into testable conditions?
Read the requirement and identify inputs, outputs, business rules, user roles and states. Turn each rule into a condition with an expected result, then add negative and boundary conditions. For example, 'users can withdraw up to 10,000 per day' becomes: withdraw below the limit, exactly at the limit, above the limit, multiple withdrawals adding up to the limit, and the limit resetting the next day. Each condition then becomes one or more test cases.
Open the dialog with the keyboard. Focus should move into it, usually to the first field or heading, and the screen reader should announce it as a dialog with its title. Tab must stay inside the dialog while it is open and the page behind must not be reachable. Escape and the close button should close it, and focus must return to the button that opened it. Also check it reads correctly when zoomed.
14
How do you test biometric login with fingerprint or face unlock?
Test enabling biometrics in app settings after a password login. Verify login with a registered fingerprint or face, and failure with an unregistered one, falling back to PIN or password after the allowed attempts. Remove or add a fingerprint in device settings and check the app asks for re-authentication. Test devices without biometric hardware, disabled biometrics and app behaviour after an OS update or reinstall.
15
A security scan says your login page can be loaded inside a frame on other sites. What is the risk and how do you confirm it?
Clickjacking tricks a user into clicking something on your site while it is hidden inside a frame on an attacker's page, for example a hidden Transfer button under a fake Play button. A tester checks whether sensitive pages can be loaded in an iframe on another site, and inspects response headers for Content-Security-Policy frame-ancestors or X-Frame-Options set to DENY or SAMEORIGIN. If the page loads in the frame, log it.
16
Tell me about a time you pushed for an accessibility fix the team wanted to postpone.
Situation: before a release, I found the payment form errors were not announced by screen readers and not reachable by keyboard. Task: the team wanted to defer it. Action: I recorded a short NVDA video showing a user could not finish payment, linked it to WCAG and our customer commitments, and proposed a small fix. Result: the fix took half a day, shipped in the release and we added keyboard checks to our definition of done.
17
How do you manage testing for multiple projects with competing deadlines?
Model answer: Situation: I was supporting two products whose releases fell in the same week. Task: deliver both without dropping quality. Action: I listed tasks by release date and risk, agreed priorities with both leads, blocked focus time for each product and shared daily status. I also asked a teammate to take retesting on one project. Result: both releases went out on time with no critical escapes.
18
Write a Postman test script that checks the status is 201 and the response contains an id.
pm.test('Status is 201', function () {
pm.response.to.have.status(201);
});
pm.test('Response has id', function () {
const body = pm.response.json();
pm.expect(body).to.have.property('id');
pm.expect(body.id).to.be.a('number');
});
Product risks are about the quality of the software itself: features that may fail and harm users, such as wrong interest calculation or a data leak. They decide what to test more deeply. Project risks are about running the test project: late builds, unstable environments, missing skills, unclear requirements or tight deadlines. They decide how to plan, with mitigations like buffers, backup environments or training.
21
How would you set up a testing approach for a new Agile team with no QA process?
Start small. Agree on a definition of ready and definition of done that include acceptance criteria and testing. Join refinement and run Three Amigos for every story. Set up a simple bug workflow and severity guide in the tracker, a shared test case repository and a smoke checklist for each build. Then add API checks and automated regression for stable flows. Review what works in each retrospective and adjust.
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.
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.
25
What basic security checks do you do for a mobile app?
Check that sensitive data like tokens and personal details are not stored in plain text on the device or written to logs. Verify all traffic uses HTTPS and the app rejects invalid certificates. Check session timeout, logout clearing data and that sensitive screens block screenshots if required. Test behaviour on rooted or jailbroken devices if the policy needs it, and that API keys are not visible in the app package.
26
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.
27
How do you test a mobile app when the device storage is almost full?
Fill the device storage close to the limit, then install or update the app and confirm a clear message if it cannot proceed. Inside the app, try downloads, photo capture, caching and saving drafts. The app should show a helpful error, not crash or corrupt data. Also check what happens to the local database when a write fails, and whether the app recovers after space is freed.
28
How do you test an application when requirements change frequently?
Take a backup of a test database with known data, record row counts and a few checksums, then restore it to a separate server. Compare counts, sample records, constraints and users. Measure how long restore takes against the recovery time objective, and check that point-in-time restore loses no more data than the recovery point objective allows. A backup that has never been restored is not proven, so this test should run regularly.
30
Leadership asks for a one-page quality update before a release. Which bug metrics do you report?
Keep it short and decision-oriented. Show open bugs by severity, the created versus resolved trend, blockers with owners and dates, defect leakage from the last release and modules with the most defects. Give a clear recommendation, such as ready, ready with known issues or not ready, with reasons. Use a shared dashboard for detail, and one slide or email summary for leaders who need only the risk picture.
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.
Find the documented limit, for example 100 requests per minute per key. Send requests just below and above the limit and check that extra requests get 429 Too Many Requests with a Retry-After header. Verify the counter resets after the window and that limits apply per key or per IP as designed. Check that one user hitting the limit does not block others, and that normal traffic is not throttled.
35
Write a pytest test using requests that checks a GET call returns 200 and a non-empty list.
Apply a valid coupon and check the discount and final amount. Test invalid, expired and not-yet-active coupons. Check minimum order value, maximum discount cap and category restrictions. Verify one-time-use coupons cannot be reused and that only one coupon applies if stacking is not allowed. Check case sensitivity and leading or trailing spaces. Remove the coupon and confirm the total resets. Change cart items after applying and verify the discount is recalculated.
37
How would you test a feature that is enabled for only 10 percent of users through a feature flag?
Test both states: flag on and flag off, so existing users are not affected. Verify the targeting rule assigns the right users and that a user stays consistently in the same group. Test switching the flag on and off in a live session and confirm data created with the flag on still works after it is turned off. Check analytics events for both groups and confirm the flag can be rolled back quickly.
38
What is the difference between a known issue and an open bug at release time?
An open bug is any defect not yet resolved. A known issue is an open bug that the team has consciously agreed to release with, after assessing its impact, and has documented in release notes or support notes, often with a workaround. Every known issue is an open bug, but not every open bug should ship. QA makes sure known issues are listed and approved by the product owner.
Cause-effect graphing is a black box technique that models input conditions (causes) and output actions (effects) with logical relations like AND, OR and NOT. The graph is converted into a decision table, and each column becomes a test case. It is useful when outputs depend on combinations of inputs, such as loan approval based on income, age and credit score. It helps find missing or contradictory rules in the requirement.
40
The developer says "it's not a bug". What do you do?
Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.
Tips to crack the Urban Company Software Testing interview
Practise DSA and low-level design for engineering roles, such as designing a booking or slot allocation system.
For analyst roles, prepare marketplace metrics like fill rate, repeat rate and partner earnings, and practise related SQL queries.
Understand the two-sided marketplace model of customers and service partners, and discuss how both sides stay satisfied.
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; Urban Company interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Urban Company Software Testing interview?
Candidates usually go through 4 stages: Online coding or analytics assessment; Technical round 1; Technical round 2 (design or case); Hiring manager and culture 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 Urban Company Software Testing interview?
This practice set leans on Agile, SQL and API Testing (6), Test Case Design (5), Bug Life Cycle and Jira (5), Manual Testing Basics (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Urban Company interviewers ask you to walk through real work.
Are these the exact questions asked at Urban Company?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Urban Company's. They are not a leaked or verified list of past questions.
Where does Urban Company hire Software Testing professionals in India?
Urban Company has large teams in Gurugram. Openings and locations change often, so check the Urban Company careers page and filter by city and experience.