Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Nagarro hiring for Software Testing roles
Nagarro is a digital engineering and technology consulting company with a large workforce in India. It works on custom software, digital product engineering, testing, cloud and data projects for clients in Europe, North America and other regions. In India it hires for software engineers, test engineers and data professionals.
For Software Testing roles, this Nagarro practice set focuses most on Test Case Design (6), Testing Types (5), Manual Testing Basics (5), STLC and Test Planning (5). It has 15 easy, 24 medium, 1 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Munich, Germany
Main India offices
Gurugram, Jaipur
Nagarro Software Testing interview process
Online assessment (aptitude + reasoning)
Coding test
Technical interview
Managerial or HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for NagarroStart 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.
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.
04
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.
05
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.
The test basis is the set of documents and knowledge from which test cases are derived. It includes requirement specifications, user stories with acceptance criteria, design documents, wireframes, API contracts, business rules and even existing system behaviour. A good test basis lets you trace each test case back to a requirement. If the test basis is weak or missing, testers must clarify it before or while testing.
08
Design EP and BVA tests for a password that must be 8 to 16 characters and contain at least one digit.
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.
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.
11
What is a user story and what are acceptance criteria?
A user story describes a feature from the user's view, usually as: As a role, I want a goal, so that a benefit. Acceptance criteria are the specific conditions the story must meet to be accepted, often written as Given, When, Then. For example, given a registered user, when they enter a wrong password three times, then the account is locked for 15 minutes. Testers use acceptance criteria as the base for test cases.
12
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.
Data mapping testing checks that each field on a screen, file or API goes to the correct table and column with the correct format. For example, the Date of Birth field on the signup form must land in users.dob as a date, and the State dropdown must store the state code, not the label. Testers use a mapping document, enter known values in the UI or API and query the database to compare field by field.
14
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
Moves to the chosen floor, doors open and close, door sensor stops closing on obstruction, overload alarm, emergency button, behaviour in a power cut, max capacity and the floor display.
Turn on the screen reader, for example NVDA with a browser, and listen rather than look. Navigate by headings to check the structure is logical, by landmarks to find main regions and by Tab through controls. Each control should announce a clear name, role and state, such as 'Subscribe, checkbox, not checked'. Check images, form errors, dynamic updates like cart counts and dialogs. Note exactly what was announced in bug reports.
17
What is regression testing, and when do you automate it?
In requirement analysis, the testing team studies the requirements to understand what needs to be tested. They identify testable requirements, clarify doubts with the business analyst or client, decide test types needed, note automation candidates and look at environment needs. The outputs are a list of questions, a requirement traceability matrix draft and an automation feasibility note. Problems found here are the cheapest to fix.
Learning, test design and execution at the same time, without scripted cases — time-boxed sessions with a charter (e.g. 'explore checkout with coupons'), noting bugs and ideas. Great for finding edge cases.
21
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.
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.
Retesting, or confirmation testing, checks that a specific bug that was fixed now works, using the same steps as the original bug. Regression testing checks that the fix or a new change has not broken other, previously working features. Retesting is planned for failed cases only, while regression covers a wider set of passing cases. Retesting usually comes first, then regression around the changed area.
26
What do you do in the test execution phase when a test fails?
Re-run the test once to confirm the failure and rule out wrong data or environment issues. Capture evidence such as screenshots, logs and the build number. Check for an existing bug, then log a new one with clear steps and link it to the test case. Mark the test as failed, and mark dependent tests as blocked if they cannot run. After the fix, retest and run related regression.
27
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.
28
What is a database view and what do you verify when testing it?
A view is a saved query that behaves like a virtual table, often used for reports or to hide sensitive columns. When testing it, compare its output with the same query run on the base tables, check filters and joins return the right rows, confirm hidden columns such as salary are really absent, check behaviour when base data changes and verify that users without permission on the base tables can still read the view if intended.
29
What is the difference between a bug and an enhancement?
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.
32
What is the difference between an error, a defect and a failure?
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.
Include the date, build or release, and planned versus executed test cases with pass, fail, blocked and not run counts. List new bugs by severity, open critical bugs with owners, retests done and any blockers such as environment downtime or missing data. Add a short note on risk and the plan for the next day. Keep it to one page so managers can read it in two minutes.
A build is a compiled version of the software created from the latest code, often many times a day, and given to QA for testing. A release is a tested, approved version delivered to customers or production, usually with release notes and a version number. Many builds can go through testing before one of them is promoted as a release. Testers always note the build number in bug reports.
38
Analytics show many users drop off at step three of a five-step checkout. How do you investigate the usability problem?
First look at what step three asks: maybe address entry, a surprise delivery charge or forced signup. Check analytics for errors, rage clicks and time spent, and watch session recordings if available. Test it yourself on mobile and slow networks. Then run a quick usability test with five users on that step. Present evidence with likely causes and options, such as guest checkout or showing charges earlier, and measure after the change.
Testing services directly without the UI, checking status codes, responses, security and performance. It finds issues early and is faster than UI tests.
40
Tell me about a time you found an important bug that others missed.
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.
Tips to crack the Nagarro Software Testing interview
Practise coding questions along with logical reasoning, as Nagarro assessments usually combine both.
Learn about Nagarro's flat, entrepreneurial culture and its CARING values for behavioural answers.
Be ready to explain testing approaches and agile practices, since many projects follow agile delivery with distributed teams.
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; Nagarro interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Nagarro Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + reasoning); Coding test; Technical interview; Managerial or HR 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 Nagarro Software Testing interview?
This practice set leans on Test Case Design (6), Testing Types (5), Manual Testing Basics (5), STLC and Test Planning (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Nagarro interviewers ask you to walk through real work.
Are these the exact questions asked at Nagarro?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Nagarro's. They are not a leaked or verified list of past questions.
Where does Nagarro hire Software Testing professionals in India?
Nagarro has large teams in Gurugram, Jaipur. Openings and locations change often, so check the Nagarro careers page and filter by city and experience.