Persistent Systems Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Persistent Systems hiring for Software Testing roles
Persistent Systems is an Indian technology services company focused on software product engineering, digital transformation, cloud and data services. It serves clients in banking, healthcare, life sciences and software. In India it hires for software engineers, quality engineers, data engineers and analysts, often through campus drives with coding-focused assessments.
For Software Testing roles, this Persistent Systems practice set focuses most on Test Case Design (8), Manual Testing Basics (6), Agile, SQL and API Testing (6), Performance and Security Basics (4). It has 17 easy, 21 medium, 2 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Pune, India
Main India offices
Pune, Nagpur, Bengaluru, Hyderabad, Goa
Persistent Systems Software Testing interview process
Online assessment (aptitude + coding)
Technical round 1
Technical round 2
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Persistent SystemsStart 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 write test cases when only wireframes are available and the UI is not ready?
Use the wireframes and the user story as the test basis. Write test scenarios and high-level cases for the flows, field validations, navigation and error states shown in the design. Note open questions, such as missing empty states or error messages, and clarify them with the designer. Keep exact UI text and steps light so they are easy to update. Once the build arrives, refine the cases and add any missing details.
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.
Defect removal efficiency shows how many defects the team found before release. DRE = defects found before release divided by (defects found before release plus defects found after release), multiplied by 100. If QA found 90 bugs and users reported 10, DRE is 90 percent. A falling DRE means testing is missing more defects, and the escaped bugs should be analysed to improve test coverage.
04
Why must input validation be tested on the server and not only in the browser?
Client-side validation improves user experience by giving quick feedback, but anyone can bypass it by disabling JavaScript or sending requests directly with tools like Postman. The server must validate every input again for type, length, format and business rules. Testers check this by sending invalid data straight to the API, such as a negative quantity or a very long name, and confirming the server rejects it.
A latent defect exists in the software but has not caused a failure yet because the needed conditions have not occurred, such as a leap-year bug that appears only on 29 February. A masked defect is hidden by another defect, for example a broken discount calculation you cannot reach because the cart page crashes first. After the first bug is fixed, the masked one appears, which is one reason regression and retesting matter.
06
What sensitive data checks do you do in API responses and logs?
Check that responses return only needed fields, with no passwords, password hashes, full card numbers, full ID numbers or internal keys. Verify personal data is masked where required, for example only the last four digits of a phone number. Look at application and browser console logs for tokens or personal data. Check error responses do not expose stack traces, SQL or server versions. Raise any leak as a high-severity bug.
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
Managers say the automation test report is hard to understand. What should a useful report include?
A useful report shows total tests run, passed, failed and skipped, the run time, the environment, build number and browser. For each failure it should show the test name, the failing step, the error message, and a screenshot, video or trace, plus logs. Trends across runs help spot flaky tests. Linking failures to Jira bugs or manual case IDs helps managers see real product risk, not just numbers.
Verify a valid date is accepted and saved in the right format. Check the minimum age rule, such as 18 years, using boundary dates of exactly 18 today and one day short. Reject future dates and impossible dates like 30 February. Test leap year dates like 29 February 2004. Check manual typing and the picker give the same result, the field is mandatory if required, and the date displays correctly after saving.
10
How do you test app permissions such as camera, location and contacts?
Check that the app asks for permission only when the feature is used, with a clear reason. Test allow, deny, and deny with do not ask again. When denied, the app must not crash and should explain how to enable it in settings. Revoke permission from settings while the app is in background and return. Test allow only once or only while using the app options on newer OS versions.
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.
1. Open and close by click and keyboard. 2. Select one, then several options; all show as chips or a count. 3. Deselect an option. 4. Select all and clear all, if available. 5. Search inside the list filters options. 6. Maximum selection limit is enforced with a message. 7. Required field shows an error if none selected. 8. Saved selection persists after refresh. 9. Long option names do not break layout. 10. Screen reader announces selected state.
15
What is the role of a manual tester in a software team?
A manual tester understands requirements, writes test scenarios and test cases, prepares test data, executes tests on each build, logs clear bug reports and retests fixes. They also do exploratory testing, join stand-ups and reviews, and give a quality status before release. Beyond finding bugs, a good manual tester represents the end user and raises usability or requirement gaps early, when they are cheap to fix.
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.
17
Write test cases for live order tracking in a food delivery app.
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.
18
Write a basic Selenium test in Python that opens a page and checks its title.
WCAG, the Web Content Accessibility Guidelines from the W3C, is the main standard for making web content usable by people with disabilities. The current version is WCAG 2.2. It has three conformance levels: A is the minimum, AA is the usual legal and contract target, and AAA is the highest and rarely required for a whole site. Each level adds success criteria, such as colour contrast at AA.
21
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.
22
Tell me about a time exploratory testing helped you find a critical bug.
Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.
23
SQL: verify that soft-deleted users do not appear in the active users list.
-- the active list query used by the app should return 0 rows here
SELECT u.user_id, u.email
FROM users u
WHERE u.is_deleted = 1
AND u.user_id IN (
SELECT user_id FROM active_users_view
);
24
What is the difference between a build and a release?
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.
Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).
A keyboard trap is when focus moves into a component and the user cannot move out using the keyboard, for example an embedded video player or date picker that captures Tab forever. Mouse users never notice, but keyboard and screen reader users are stuck and must reload the page. It fails WCAG criterion 2.1.2. Test every widget by tabbing in and out, and check that Escape closes popups and returns focus.
29
A bug fix was made in the payment module. How do you decide the regression scope?
Ask the developer which code, services and database tables changed. Map them to impacted flows: all payment methods, refunds, partial payments, failed payment retries, invoices and order status updates. Add high-risk areas from past defects and anything that calls the same service. Run full payment regression because the business risk is high, plus a smoke test of the rest of the application before release.
30
SQL: find orders whose total does not match the sum of their order items.
SELECT o.order_id, o.total_amount,
SUM(i.quantity * i.unit_price) AS items_total
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
GROUP BY o.order_id, o.total_amount
HAVING o.total_amount <> SUM(i.quantity * i.unit_price);
31
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.
Check every page and API uses HTTPS, and plain HTTP redirects to HTTPS. Verify the certificate is valid, not expired, and matches the domain, with no browser warnings. Look for mixed content, where an HTTPS page loads scripts or images over HTTP. Check login and payment forms submit only over HTTPS and that cookies holding session data have the Secure flag.
34
The developer says "it's not a bug". What do you do?
Compliance testing checks that software meets external laws, standards or internal policies, not just functional requirements. Examples include payment security standards for card data, data protection rules for personal data, accessibility guidelines and RBI rules for banking apps. Testers verify items such as consent capture, data retention, audit logs and masking. Findings are usually documented as evidence for auditors, so traceability and clear records matter as much as the tests.
36
What is a locator and what types of locators exist?
A locator tells the automation tool how to find an element on the page so it can click, type or check it. Common types are ID, name, CSS selector, XPath, link text, and in modern tools role-based locators such as a button with name Login, plus label, placeholder and test ID locators. A good locator is unique, readable and unlikely to change when the page design changes.
A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.
System testing tests the complete, integrated application against the requirements in an environment close to production. It is done by the testing team after integration testing and before UAT. It covers functional testing of all features plus non-functional aspects such as performance, security, usability and compatibility. It is black box testing, so the tester checks behaviour from the user's point of view without looking at the code.
39
What is the OWASP Top 10 and why should testers know it?
The OWASP Top 10 is a widely used list of the most critical web application security risks, published by an open community project. It includes broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components and authentication failures. Testers use it as a checklist to include basic security checks in their testing and to speak the same language as security teams.
40
SQL: find customers who placed more than three orders in the last 30 days.
SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY c.id, c.name
HAVING COUNT(o.id) > 3
ORDER BY order_count DESC;
Tips to crack the Persistent Systems Software Testing interview
Practise coding problems of easy to medium difficulty, as Persistent assessments usually focus more on programming than service peers.
Revise data structures, OOP, DBMS and operating system basics for the technical rounds.
Read about Persistent's product engineering background and its partnerships with major cloud providers.
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; Persistent Systems interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Persistent Systems Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + coding); Technical round 1; Technical round 2; 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 Persistent Systems Software Testing interview?
This practice set leans on Test Case Design (8), Manual Testing Basics (6), Agile, SQL and API Testing (6), Performance and Security Basics (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Persistent Systems interviewers ask you to walk through real work.
Are these the exact questions asked at Persistent Systems?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Persistent Systems's. They are not a leaked or verified list of past questions.
Where does Persistent Systems hire Software Testing professionals in India?
Persistent Systems has large teams in Pune, Nagpur, Bengaluru, Hyderabad, Goa. Openings and locations change often, so check the Persistent Systems careers page and filter by city and experience.