Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Coforge hiring for Software Testing roles
Coforge, formerly NIIT Technologies, is an Indian IT services company focused on industries such as banking, insurance, and travel and transportation. It provides application development, testing, cloud, data and integration services. In India it hires for software engineers, test engineers, data analysts and data engineers.
For Software Testing roles, this Coforge practice set focuses most on Testing Types (6), Test Case Design (6), Bug Life Cycle and Jira (5), Agile, SQL and API Testing (5). It has 18 easy, 19 medium, 3 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Noida, India
Main India offices
Noida, Greater Noida, Bengaluru, Pune, Hyderabad
Coforge Software Testing interview process
Online assessment (aptitude + reasoning)
Technical MCQs or coding test
Technical interview
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for CoforgeStart 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.
Exhaustive testing means trying every possible input, path and combination, which is practically infinite for real software. Even a single text field accepting 20 characters has more combinations than you could ever run. So testers use risk and techniques like equivalence partitioning and boundary value analysis to select a small set of tests that give high confidence. The goal is enough coverage of important risks, not every possible case.
Give a clear title, such as 'Checkout: Place Order button not reachable by keyboard'. Include the page URL, browser, operating system and assistive technology with versions. Write exact steps, what was announced or happened, and what was expected. Add the WCAG success criterion, such as 2.1.1 Keyboard, and the user impact. Attach a screenshot or audio recording, and suggest a fix when obvious. Severity should reflect whether users are fully blocked.
A duplicate bug is a new report for a problem that is already logged. Before raising a bug, search the tracker by key words, module, error message and recent open bugs, and ask teammates working on the same area. If a similar bug exists, add your extra information, such as another browser or data set, as a comment instead of a new ticket. This keeps the backlog clean and saves triage time.
07
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.
08
What is the difference between path parameters, query parameters and the request body?
Path parameters identify a specific resource and are part of the URL, as in /users/42. Query parameters filter, sort or paginate and come after a question mark, as in /users?city=Pune&page=2. The request body carries data for creating or updating, usually JSON, in POST, PUT or PATCH. Testers check invalid values in each: a wrong ID in the path, unknown query parameters and missing body fields.
Data-driven testing runs the same test steps many times with different input and expected values taken from a table, CSV, JSON or spreadsheet. For example, one login test can run with valid users, locked users, wrong passwords and blank fields. It reuses the logic, makes adding cases easy and maps well to equivalence partitioning and boundary values from manual design. Tools support it through parameterised tests, such as pytest.mark.parametrize.
10
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.
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.
First ask what type of pen and who the users are. Functional: it writes smoothly, ink flows without leaking, the cap or click mechanism works and the ink colour matches the label. Non-functional: comfort of grip, writing length before ink runs out, performance at different temperatures and on different paper. Negative: dropping it, pressing hard, leaving it uncapped. Safety: the cap is non-toxic and has an air hole. This shows structured thinking, not just a list.
Verify a correct OTP within validity logs the user in. Verify a wrong OTP shows an error and an expired OTP is rejected. Check the OTP length and that only digits are allowed. Test resend: it is disabled during the countdown, and the old OTP stops working after resend. Check the maximum number of wrong attempts locks verification. Verify auto-read on mobile, paste support, and behaviour when the network drops during submission.
14
How do you test dark mode and large font settings in an app?
Switch the device to dark mode and check every screen: text must remain readable, icons and images visible, and no white flashes during navigation. Switch back while the app is open. Then increase the system font size to the largest setting and confirm text does not overlap or get cut off and buttons remain usable. Also test display size or zoom settings and both orientations.
A test condition is an item or event of the system that can be verified by one or more test cases, derived from the test basis. For example, for a login requirement, conditions include valid login, wrong password, locked account and remember me. Test conditions answer what to test, while test cases describe how to test it with steps, data and expected results. Listing conditions first helps check coverage before writing detailed cases.
Severity = impact on the system. Priority = urgency to fix.
Logo misspelt on the homepage → low severity, high priority.
Crash in a rarely used report → high severity, low priority.
Both are temporary pieces of code used in integration testing when some modules are not ready. A stub replaces a called lower-level module and returns fixed responses, used in top-down testing; for example, a stub payment service that always returns success. A driver replaces a calling higher-level module and sends inputs to the module under test, used in bottom-up testing. In API testing, mock servers play the role of stubs.
20
When is manual testing a better choice than automation?
Manual testing is better for exploratory testing, usability and look-and-feel checks, features that change often, one-time tests and early testing of new functionality. Automation pays off for stable, repetitive tests such as regression suites, data-driven checks and smoke tests run on every build. Most teams combine both: manual for discovery and judgement, automation for speed and repeatability.
21
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.
Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.
The Page Object Model is a design pattern where each page or major component gets a class that holds its locators and actions, such as LoginPage with a login method. Tests call these methods instead of using locators directly. When the login button changes, you update one place instead of fifty tests. Tests become readable, like steps a manual tester would write, and duplication drops. Keep assertions mostly in tests, not page objects.
26
A feature passed all your test cases, but users say it is confusing. What went wrong?
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.
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);
-- alternative using DENSE_RANK
SELECT DISTINCT salary FROM (
SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
FROM employees
) t WHERE rnk = 2;
29
What is SQL injection and how can a tester check for it at a basic level?
SQL injection happens when user input is added directly into a database query, letting an attacker change the query to read or modify data. A tester can enter inputs like a single quote or ' OR '1'='1 in login, search and URL parameters and watch for database errors, unexpected results or a login bypass. Only test in approved environments. The real fix is parameterised queries, not input filtering alone.
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.
31
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.
32
What is the difference between ad hoc testing and monkey testing?
Ad hoc testing is informal testing without test cases, done by a tester who understands the application and tries likely weak areas based on experience. Monkey testing gives random inputs and actions, often without knowing the application, to see if it crashes. Ad hoc testing is targeted and good at finding logical bugs, while monkey testing is good at finding stability issues and is often automated.
AI assistants can draft test cases from requirements, suggest edge cases, generate first versions of scripts and test data, and some tools self-heal locators when the page changes. Risks are confident but wrong output, tests that assert the wrong behaviour, hidden locator changes that mask real bugs and leaking confidential data into external tools. Treat AI output like a junior's draft: review it, run it and keep human judgement on what matters.
35
What is a test scenario for the login functionality at a high level?
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.
Response time is the total time from sending a request to receiving the complete response, as the user experiences it. Latency is the delay before the first byte of the response arrives, mostly network and waiting time. Throughput is how many requests or transactions the system handles per unit of time, such as 500 requests per second. Good performance usually means low response time at the required throughput.
38
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.
39
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.
40
What is network condition testing for mobile apps?
It checks app behaviour on different networks: Wi-Fi, 4G, 5G, slow 2G or 3G, high latency, packet loss and no network. Also test switching between Wi-Fi and mobile data in the middle of an action, and airplane mode. The app should show loaders and clear offline messages, retry safely without duplicate actions and not freeze. Network throttling tools in developer options or proxy tools help simulate these conditions.
Tips to crack the Coforge Software Testing interview
Learn travel and insurance domain basics like bookings, policy lifecycle and claims, which are key Coforge verticals.
Revise SQL, Java or Python and testing concepts for the technical interview.
Know that Coforge was earlier called NIIT Technologies and be able to describe its industry-focused strategy.
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; Coforge interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Coforge Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + reasoning); Technical MCQs or coding test; Technical interview; 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 Coforge Software Testing interview?
This practice set leans on Testing Types (6), Test Case Design (6), Bug Life Cycle and Jira (5), Agile, SQL and API Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Coforge interviewers ask you to walk through real work.
Are these the exact questions asked at Coforge?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Coforge's. They are not a leaked or verified list of past questions.
Where does Coforge hire Software Testing professionals in India?
Coforge has large teams in Noida, Greater Noida, Bengaluru, Pune, Hyderabad. Openings and locations change often, so check the Coforge careers page and filter by city and experience.