Expedia Group Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Expedia Group hiring for Software Testing roles
Expedia Group is a global online travel company that owns brands such as Expedia, Hotels.com and Vrbo. Its platforms help travellers search and book hotels, flights, holiday rentals and packages, while partners use its tools to reach customers. In India it has technology centres that hire software engineers, data scientists, analysts and quality engineers for its travel platforms.
For Software Testing roles, this Expedia Group practice set focuses most on Test Case Design (9), Bug Life Cycle and Jira (7), Agile, SQL and API Testing (5), Testing Types (4). It has 2 easy, 32 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Seattle, USA
Main India offices
Gurugram, Bengaluru
Expedia Group Software Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (system design or domain)
Hiring manager and behavioural round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Expedia GroupStart 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
How do you test session management in a web application?
Check that a new session ID is created after login, and that the session expires after the defined idle time. Verify logout invalidates the session on the server, so pressing back or reusing the old cookie does not work. Check that cookies use Secure, HttpOnly and SameSite flags. Test concurrent logins if they are limited, and that changing the password ends other sessions. Session IDs must not appear in URLs.
Escalate immediately with the impact on the schedule. While it is down, prepare test data, review and update test cases, and test what you can elsewhere: API tests against another environment, UI on a developer machine or a staging copy. Track the lost hours in the status report. When the environment returns, run smoke first, then the prioritised list, and ask whether the release date or scope needs to change.
Defect age is how long a defect stays open, measured either in time, from the date it was logged to the date it was closed, or in phases, from the phase where it was introduced to the phase where it was found. High defect age signals slow fixing or triage. Phase-based age shows how late defects are caught; a requirement defect found in UAT has a high age and is costly.
05
Notifications arrive late, and some screens look broken, only on certain Android phone brands. Why can this happen and what do you test?
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.
06
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.
07
How do you link stories, test cases and bugs in Jira for traceability?
Create test cases as linked issues or in a test management add-on and link each one to its story with a tests relationship. When a test fails, create the bug from the test execution or link it to both the test and the story with is blocked by or relates to. Use the same fix version for all. A story then shows its tests and open bugs, which makes sign-off and the traceability report easy.
08
You join a project in the middle of a release. How do you plan your testing?
Spend the first day learning the scope: read the release notes, user stories and test plan, and ask the lead what is at risk. Get access to the environment, tracker and test repository. Pick up a clearly defined module, run its existing test cases to learn the application and note gaps. Ask questions early in stand-up. Within a few days, take ownership of retesting and regression for that module.
A deadlock happens when two transactions each hold a lock the other needs, so neither can continue. The database detects it and kills one transaction with an error. During testing it usually appears under concurrent load, for example two users booking the last seats at once, as random failures or 'deadlock detected' entries in logs. Testers report the exact actions and timing, and developers fix it with consistent lock order or shorter transactions.
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.
Contract testing checks that a service provider and its consumers agree on the API format, such as request fields, response fields and status codes, without running a full end-to-end environment. The consumer defines what it expects, and the provider's build verifies it still meets that contract. It catches breaking changes early in microservice systems, where full integration environments are slow and fragile.
Valid login, wrong password, empty fields, case sensitivity, max length, SQL-injection strings, password masking, 'remember me', lock-out after N attempts and the forgot-password link.
Recovery testing checks how well the system recovers from crashes, hardware failures, network loss or other failures. For example, kill the server during a file upload, or disconnect the network during payment, and verify the system restores a consistent state, does not lose or duplicate data and resumes or shows a clear message. It also measures recovery time against agreed targets, which matters for banking and healthcare systems.
Verify each status change appears in order: placed, accepted, preparing, picked up and delivered. Check the rider's location updates on the map at the expected interval. Test the estimated time updates when there is a delay. Verify notifications for each status. Check behaviour when the network drops and recovers, when the app is reopened, and when the order is cancelled midway. Confirm tracking stops after delivery and the rating screen appears.
19
Write test cases for a coupon code field at checkout.
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.
Contrast ratio compares the brightness of text and its background, from 1:1 to 21:1. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, which is about 18 point or 14 point bold. User interface parts such as input borders and icons need 3:1. AAA raises text to 7:1. Testers check this with a contrast checker or browser developer tools, including placeholder, disabled and hover states.
22
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.
23
What are the main testing differences between Android and iOS?
Android has many manufacturers, screen sizes and OS versions with custom skins, so device fragmentation and background-kill behaviour need more coverage. iOS has fewer devices but strict permission, privacy and store review rules. Navigation differs: Android has a system back button or gesture, iOS relies on in-app navigation and swipe back. Notification, permission and file-access behaviours also differ, so test cases need platform-specific steps.
24
An automated test keeps failing because an element's ID is generated differently on every build. What do you do?
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.
25
The developer says "it's not a bug". What do you do?
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.
Length partitions: below 8 (invalid), 8 to 16 (valid), above 16 (invalid). Boundaries: 7, 8, 9, 15, 16 and 17 characters. Digit partitions: contains a digit (valid), no digit (invalid). Sample tests: 'abc1234' with 7 characters is rejected, 'abcdefg1' with 8 is accepted, a 16-character value with a digit is accepted, 17 characters is rejected, and 'abcdefgh' with no digit is rejected. Also test empty input and spaces.
29
The sprint ends tomorrow and two stories are still in testing. What do you do?
Tell the Scrum Master and product owner today, not at the review. Focus testing on the acceptance criteria and the riskiest paths of the story with the most value, and ask a developer to help with test data or simple checks. If a story cannot be finished with quality, it should be carried over, not marked done with untested parts. Raise the cause in the retrospective, such as late handover.
Testing services directly without the UI, checking status codes, responses, security and performance. It finds issues early and is faster than UI tests.
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.
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.
35
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.
36
A requirement says the page should load fast. How do you turn it into a test case?
The word fast is not testable, so ask the product owner for a measurable target, for example the page loads within 3 seconds on a 4G network for 95 percent of requests. Agree on the conditions: device, network, data size and whether it is first load or cached. Then write the test with those conditions and expected time. Record the agreed number in the story so the expected result is not open to opinion.
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
39
What is localisation and internationalisation testing?
Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.
40
A developer changed a shared header component used on every page. What testing do you plan?
Retest the change itself, then run a focused regression on every page type that uses the header: home, listing, detail, checkout and account. Check navigation links, search, login and logout state, cart count and the mobile menu. Do cross-browser and responsive checks because layout changes affect all sizes. A quick visual comparison against the previous build helps spot alignment issues across many pages.
Tips to crack the Expedia Group Software Testing interview
Practise DSA problems and be ready to discuss time and space complexity of your solutions in clear terms.
Prepare for design questions on systems like hotel search, booking or pricing, focusing on scale, caching and reliability.
Use the STAR method for behavioural questions and show curiosity about travel technology and customer experience.
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; Expedia Group interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Expedia Group Software Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (system design or domain); Hiring manager and behavioural 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 Expedia Group Software Testing interview?
This practice set leans on Test Case Design (9), Bug Life Cycle and Jira (7), Agile, SQL and API Testing (5), Testing Types (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Expedia Group interviewers ask you to walk through real work.
Are these the exact questions asked at Expedia Group?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Expedia Group's. They are not a leaked or verified list of past questions.
Where does Expedia Group hire Software Testing professionals in India?
Expedia Group has large teams in Gurugram, Bengaluru. Openings and locations change often, so check the Expedia Group careers page and filter by city and experience.