Pine Labs Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Pine Labs hiring for Software Testing roles
Pine Labs is an Indian merchant commerce and payments company known for card payment terminals at retail stores. It offers point-of-sale payments, EMI and buy-now-pay-later options at checkout, online payments and gift card solutions through Qwikcilver. It serves merchants in India and other Asian markets and hires software engineers, quality engineers, data analysts and product roles.
For Software Testing roles, this Pine Labs practice set focuses most on STLC and Test Planning (5), Agile, SQL and API Testing (5), Bug Life Cycle and Jira (5), Database Testing (5). It has 2 easy, 33 medium, 5 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Noida, India
Main India offices
Noida, Bengaluru
Pine Labs Software Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (design or domain)
Hiring manager and HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Pine LabsStart 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.
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.
03
A hotfix build arrives and you have only 15 minutes before deployment. How do you sanity check it?
Read the hotfix ticket to know exactly what changed. First verify the fix with the original reproduction steps and data. Then check the directly connected flows, for example if the fix is in coupon calculation, test applying, removing and paying with a coupon. Finish with a quick smoke of login and the main business flow. Report the result immediately, mentioning what was and was not covered.
A flaky test passes and fails on the same code without any change. Common causes are timing problems such as fixed sleeps or missing waits, tests depending on each other or on shared data, unstable locators, animations, third-party services, test order in parallel runs and environment issues like slow servers. Flaky tests destroy trust in the suite, so teams quarantine them, find the root cause and fix it rather than adding retries forever.
05
A manager wants 100 percent test automation. How do you respond?
I agree with the goal of faster and more reliable testing, but explain that 100 percent is neither possible nor useful. Exploratory testing, usability, visual judgement and brand-new features need people, and some flows like real payments or OTP are costly to automate reliably. I would propose clear targets instead, such as automating all critical regression and smoke flows, with metrics like regression time cut from three days to four hours.
06
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.
07
Search works fine in QA but is very slow in production. Could a missing database index be the reason, and how do you check?
Yes, very likely. An index lets the database find rows quickly, like the index of a book. With a small QA table, a full table scan is still fast, but with millions of production rows it becomes slow. Compare indexes on the searched columns in both environments and ask a developer to check the query plan. Test key queries on production-size data in staging, and include data volume in future performance checks.
08
What is the difference between an error, a defect and a failure?
Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.
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.
12
Write a pytest test using requests that checks a GET call returns 200 and a non-empty list.
First ask the product owner or business analyst for the expected behaviour and write down the answers as draft acceptance criteria. Meanwhile, explore the feature, compare it with similar existing features and list assumptions. Share the assumptions in the story so everyone agrees before you sign off. Raise the missing criteria in the next refinement so future stories are not picked up without them.
15
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.
16
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.
QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.
19
Tell me about a time you organised or ran a bug bash before a release.
Situation: a new seller onboarding flow was due in a week and only two testers had seen it. Task: I wanted wider coverage quickly. Action: I set up a one-hour bug bash with developers, product and support, shared test accounts, focus areas and a simple bug form, then triaged findings with the lead. Result: we found 18 issues, including two blockers on low-end phones, and fixed them before launch.
20
What is normalization and why should a tester understand it?
Normalization organises tables to reduce duplicate data, for example storing the customer address once in a customers table instead of repeating it in every order. Testers should understand it because it explains where data lives and which joins are needed to verify a screen. It also shows risk: in a denormalized report table, the same value is copied in many places, so updates must be tested to confirm every copy changes.
21
During a load test, some booking requests fail with a 'deadlock detected' error. What is happening and how do you report it?
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.
Test monitoring compares actual testing progress with the plan, using metrics like test cases executed, pass rate, open defects and effort spent. Test control is the action taken when monitoring shows a gap, such as re-prioritising tests, adding testers, changing the schedule or tightening entry criteria. For example, if half the time has passed but only a quarter of cases are executed, the lead must act and inform stakeholders.
23
The test environment is down for two days just before release. What do you do?
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.
24
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.
25
How do you design test cases for role-based access with admin, editor and viewer roles?
Build a permission matrix with roles as rows and actions as columns, such as create, edit, delete, publish and view, marking allowed or denied from the requirement. Write a positive test for each allowed cell and a negative test for each denied one. Test through the UI and also call the APIs directly, because hidden buttons are not security. Check role changes take effect immediately and that users cannot access other users' data by changing IDs.
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.
27
How do you test API error handling for invalid input?
Send requests with missing required fields, wrong data types, values beyond limits, invalid formats such as a bad email, unknown fields and an empty or malformed JSON body. The API should return a 4xx code such as 400 or 422, a clear error message that names the field, and no stack trace or database details. Also check that nothing was partly saved in the database after the failed request.
28
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.
XSS is a vulnerability where an attacker's script is injected into a page and runs in other users' browsers, which can steal session data or change the page. It occurs when user input is shown without proper encoding. Testers enter a harmless script tag or an image tag with an onerror alert in comments, profile names and search boxes, then check if it executes when the page is displayed. Output encoding prevents it.
30
A security reviewer asks you to confirm that passwords and personal data are stored safely. What do you check in the database?
Query the users table after signup and confirm the password is not stored in plain text or reversible encoding, but as a salted hash from a slow algorithm such as bcrypt or Argon2. Two users with the same password should have different hashes. Check that card numbers are not stored at all or are tokenised, that personal data like Aadhaar numbers is masked or encrypted, and that logs and audit tables do not copy the raw values.
31
Why should we hire you as a manual tester over someone with more automation experience?
Answer with strengths and honesty. For example: I am strong at understanding requirements, designing test cases with techniques like boundary values and finding bugs through exploratory testing, which automation depends on to be useful. I also write SQL and test APIs in Postman. I am learning Playwright and have automated a few smoke tests, so I can grow into automation while adding value from the first week.
32
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.
33
How do you handle a bug found late in a release cycle?
List conditions and actions in a table and cover every combination of conditions (rules) — ideal for business rules like loan approval: salary > X AND credit score > Y → approve.
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.
Install a fresh build and verify first-launch screens and permissions. Test install with low storage. Update from the previous production version and check that login, settings, saved data and offline content are kept and migrations work. Test a forced update prompt if the app has one. Uninstall and reinstall, and confirm local data is cleared while server data returns after login. Check the app size is reasonable.
39
What is colour contrast ratio and what values does WCAG require?
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.
40
SQL: check that no user has more than one active subscription.
-- Business rule: at most one ACTIVE subscription per user
SELECT user_id, COUNT(*) AS active_count
FROM subscriptions
WHERE status = 'ACTIVE'
GROUP BY user_id
HAVING COUNT(*) > 1;
-- Expected result: no rows
Tips to crack the Pine Labs Software Testing interview
Learn how card payments work at a store terminal, including authorisation, settlement and EMI conversion at checkout.
Practise DSA and backend design, focusing on reliability and security for systems handling financial transactions.
Read about Pine Labs products like EMI offers and gift cards to show interest in merchant commerce.
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; Pine Labs interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Pine Labs Software Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (design or domain); Hiring manager and 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 Pine Labs Software Testing interview?
This practice set leans on STLC and Test Planning (5), Agile, SQL and API Testing (5), Bug Life Cycle and Jira (5), Database Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Pine Labs interviewers ask you to walk through real work.
Are these the exact questions asked at Pine Labs?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like Pine Labs's. They are not a leaked or verified list of past questions.
Where does Pine Labs hire Software Testing professionals in India?
Pine Labs has large teams in Noida, Bengaluru. Openings and locations change often, so check the Pine Labs careers page and filter by city and experience.