McKinsey & 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 McKinsey & Company hiring for Software Testing roles
McKinsey & Company is a global management consulting firm that advises companies, governments and institutions on strategy, operations, technology and organisation. In India it has client service offices as well as large knowledge and capability centres that support consultants worldwide with research, analytics and digital work. It hires business analysts, research analysts, data scientists and software engineers in India.
For Software Testing roles, this McKinsey & Company practice set focuses most on Testing Types (7), Test Case Design (6), Accessibility & Usability Testing (4), Agile, SQL and API Testing (4). It has 4 easy, 30 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
New York, USA
Main India offices
Gurugram, Mumbai, Bengaluru, Chennai
McKinsey & Company Software Testing interview process
Online problem-solving assessment or game-based test
Case interview round 1
Case interview round 2 with personal experience questions
Final partner round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for McKinsey & 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.
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.
03
What is a performance bottleneck and where do bottlenecks usually occur?
A bottleneck is the component that limits the whole system's performance, so adding load beyond it increases response times or errors. Common places are slow database queries or missing indexes, too few database connections or threads, CPU or memory limits on servers, slow third-party APIs, large uncompressed files and chatty code that makes many small calls. Monitoring each layer during a test shows which resource saturates first.
Focus order is the sequence in which keyboard focus moves through interactive elements; it should follow the visual reading order. Visible focus means the focused element clearly shows a ring or highlight. Test by pressing Tab through the page and watching where focus goes. Common bugs are focus jumping to the footer, focus going behind an open dialog and designers removing the outline with CSS, leaving keyboard users lost.
06
What is data integrity and what are its main types?
Data integrity means data stays accurate and consistent through its life. Entity integrity: every row has a unique, non-null primary key. Referential integrity: a foreign key always points to an existing parent row, such as every order pointing to a real customer. Domain integrity: values stay within allowed types and ranges, enforced by data types, CHECK and NOT NULL constraints. User-defined integrity covers business rules, such as an order total never being negative.
07
How do you make test cases reusable and easy to maintain?
Write one clear objective per case, keep steps short and avoid hard-coding data that changes. Put shared steps such as login into a common precondition instead of repeating them. Use consistent naming, link each case to a requirement and group them by module. Keep expected results specific but not tied to exact pixel layouts. Review and update cases whenever a story changes, so the suite stays trustworthy for regression.
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
What is the difference between smoke testing in CI and full regression?
Interrupt testing checks how the app behaves when something interrupts it: an incoming call, SMS, notification, alarm, low battery warning, network change, plugging in a charger or switching to another app. The app should pause correctly, keep the user's data and resume where the user left off. For example, a call during a payment must not cause a double charge or lose the transaction state.
Won't Fix means the bug is acknowledged as real, but the team decides not to fix it, usually because the impact is very low, the feature is being retired or the cost of fixing is higher than the benefit. The decision is made by the product owner, often in triage with dev and QA leads. The tester should make sure the reason is recorded and, if user-facing, documented as a known issue.
Define goals and three to five realistic tasks, such as 'Book a train ticket for next Friday'. Recruit participants who match real users. In the session, explain that you are testing the product, not them, ask them to think aloud, and avoid hinting even when they struggle. Record the screen with consent, note where they hesitate or fail, and finish with a short questionnaire. Then group findings by severity and frequency.
17
The product team wants to skip UAT to ship faster. What do you advise?
Explain the risk: system testing proves the software matches the specification, but only users confirm it fits real business work. Propose a lighter option instead of none: a short, focused UAT on critical flows with two or three key users, or a staged rollout to a small user group with monitoring and quick rollback. If they still skip it, record the decision and the accepted risks with the product owner.
18
A bug happens only in production and not in the QA environment. How do you investigate?
Collect exact details: user, time, device, browser and request IDs. Compare production with QA for configuration, feature flags, data volume, third-party integrations, versions and caching. Ask for production logs and error traces through the support or dev team. Try to reproduce in QA with production-like data or in a staging environment. Once found, add a test for the gap and fix the environment difference if one caused it.
19
How do you do cross-browser testing and choose which browsers to cover?
Use analytics to pick browsers and versions that most real users have, plus the ones listed in the requirement, usually the latest two versions of major desktop and mobile browsers. Run the main flows on each and check layout, fonts, forms, date pickers, file upload and JavaScript errors in the console. Use responsive mode for screen sizes, and real devices or a cloud device lab for mobile browsers.
20
Customer records are being moved from an old system to a new one. How do you test the migration?
Compare record counts per table before and after. Check field mapping, data types, formats, encodings and default values for a sample of records, including edge cases like nulls, special characters and very old records. Verify relationships are kept, such as each order still linked to its customer. Run key business reports in both systems and compare totals. Test the rollback plan and confirm the new application works with migrated data.
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.
22
Why do performance reports use percentiles like p90 and p95 instead of averages?
An average hides slow requests. If 90 requests take 1 second and 10 take 10 seconds, the average is 1.9 seconds, which looks fine, but one user in ten waits 10 seconds. The p95 value means 95 percent of requests were faster than it, so it shows what most users actually experience, including the slow tail. Service level targets are usually written as percentiles, such as p95 under 2 seconds.
23
Tell me about a device-specific bug you found and how you reported it.
Model answer: Situation: users of one budget phone model reported that the camera upload screen was black. Task: reproduce it. Action: I borrowed the same model, found the issue only appeared when the battery saver was on, and logged the bug with the device model, OS version, logs and a video. Result: the developer fixed the camera initialisation, and we added that model to our device matrix.
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.
25
How do specification-based techniques differ from experience-based techniques?
Specification-based (black box) techniques derive tests systematically from requirements: equivalence partitioning, boundary values, decision tables, state transitions and use cases. They give measurable coverage. Experience-based techniques rely on the tester's knowledge and intuition: error guessing, exploratory testing and checklist-based testing. They are good at finding defects the specification never mentioned. Strong testers use specification techniques for coverage and experience techniques to fill the gaps.
Set browser zoom to 200 percent and check that all text is readable and no content or buttons are cut off. Then zoom to 400 percent, or use a 1280 pixel wide window, which gives a 320 CSS pixel viewport; content should reflow into one column without horizontal scrolling, except for things like data tables and maps. Also increase text spacing and the operating system font size to check that labels do not overlap.
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.
28
What is the difference between statement coverage and branch coverage?
Statement coverage measures the percentage of code statements executed by tests. Branch coverage measures whether every decision outcome, true and false, has been executed. Branch coverage is stronger: for 'if (amount > 1000) applyDiscount()', one test with 1500 gives 100 percent statement coverage, but you need a second test with 500 to cover the false branch. 100 percent branch coverage implies 100 percent statement coverage, not the other way round.
Model answer: Situation: before a release of an insurance app, all regression tests had passed. Task: I was doing a final exploratory round. Action: I renewed a policy on the last day of the month and saw that the premium was calculated for 31 days in a 30-day month. I logged it with exact data and the formula difference. Result: the date logic was fixed before release, and I added month-end cases to the suite.
31
What do you check in mobile accessibility testing?
Turn on the screen reader, TalkBack on Android or VoiceOver on iOS, and check every button, image and field has a meaningful label and the reading order is logical. Check text scales with system font size, colour contrast is sufficient and touch targets are large enough, about 48 by 48 density-independent pixels. Make sure information is not shown by colour alone and that the app works without complex gestures.
32
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.
33
How do you keep yourself updated with testing practices and tools?
Model answer: I follow testing communities and blogs, practise on public demo sites and read release notes of the tools I use. Last month I learned API schema validation from an online course and tried it on a practice API. I also share one new idea in our team chat each week. This keeps me improving and helps the team pick up useful practices without waiting for formal training.
34
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 test readiness review is a checkpoint before formal test execution starts, where the team confirms everything needed is in place. It checks that the build is deployed and smoke tested, the environment and test data are ready, test cases are reviewed and approved, access and tools work, and entry criteria are met. It prevents wasted days when execution starts and testers discover a missing service or empty database.
A regression bug is a feature that worked before but broke after a new change, such as login failing after a profile page update. It is usually treated with higher priority because it affects existing users. In Jira, add a label such as regression, set the affected version and link it to the story or change that caused it. Tracking these labels over time shows where regression coverage is weak.
39
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.
40
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.
Tips to crack the McKinsey & Company Software Testing interview
Practise structured case interviews out loud, focusing on breaking problems into clear parts and doing quick mental arithmetic accurately.
Prepare detailed personal stories on leadership, impact and handling conflict, since McKinsey asks probing follow-up questions on each story.
For analytics roles, revise SQL, Python and statistics along with case skills, because both are often tested together.
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; McKinsey & Company interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the McKinsey & Company Software Testing interview?
Candidates usually go through 4 stages: Online problem-solving assessment or game-based test; Case interview round 1; Case interview round 2 with personal experience questions; Final partner 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 McKinsey & Company Software Testing interview?
This practice set leans on Testing Types (7), Test Case Design (6), Accessibility & Usability Testing (4), Agile, SQL and API Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most McKinsey & Company interviewers ask you to walk through real work.
Are these the exact questions asked at McKinsey & Company?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like McKinsey & Company's. They are not a leaked or verified list of past questions.
Where does McKinsey & Company hire Software Testing professionals in India?
McKinsey & Company has large teams in Gurugram, Mumbai, Bengaluru, Chennai. Openings and locations change often, so check the McKinsey & Company careers page and filter by city and experience.