Grant Thornton Bharat Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Grant Thornton Bharat hiring for Software Testing roles
Grant Thornton Bharat is the Indian member firm of the Grant Thornton global network of audit, tax and advisory firms. It provides assurance, tax, risk advisory, deals, forensic and digital consulting services to businesses and government organisations. In India it hires for audit, risk consulting, cybersecurity, data analytics and technology roles, with offices in metros and several tier-2 cities.
For Software Testing roles, this Grant Thornton Bharat practice set focuses most on Bug Life Cycle and Jira (7), Agile, SQL and API Testing (6), Test Case Design (5), Automation Basics for Manual Testers (4). It has 6 easy, 28 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Grant Thornton Bharat Software Testing interview process
Resume screening or online assessment
Technical interview
Managerial round
Partner or HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Grant Thornton BharatStart 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.
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.
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;
04
A report shows duplicate rows after a new release. How do you investigate in the database?
Run the report query with GROUP BY on the business key and HAVING COUNT(*) > 1 to find which records repeat. Then check whether the duplicates exist in the base table or are created by the query, usually a new join to a one-to-many table such as addresses. Compare the query before and after the release. Include the duplicate keys, the count and the suspected join in the bug report.
05
How do you convert existing manual test cases into automated scripts?
Pick a small set of stable, high-value regression cases first. Review each one: make steps precise, remove judgement-based checks and define clear expected results. Prepare test data that the script can create and clean up. Build reusable page objects and helpers for common steps like login. Automate, run several times to confirm stability, then link each script to its manual case ID and mark the manual case as automated.
Agree on scope: key user journeys and page templates, not every page. Day one, run automated scans on all templates to fix easy issues fast. Then do manual checks of each journey with keyboard, NVDA, VoiceOver on mobile, zoom and contrast. Log issues with WCAG references and severity, and get blockers fixed first. Retest fixes and deliver a conformance summary with known issues. Be honest if full compliance is not realistic.
First query the main users table to see whether the update was saved. If it was, check where the report reads from: a view, a reporting copy, a cache or a nightly ETL table. The report may simply be stale until the next refresh, which may be by design. If the main table still has the old value, check the API request, the update query and any errors in logs, then log a bug with both query results.
11
Why are stable locators like data-testid or roles preferred over position-based XPath?
A position-based XPath such as /html/body/div[3]/div[2]/button breaks whenever a developer adds a wrapper div or reorders the layout, even though the feature still works. That creates false failures and maintenance work. Locators based on a dedicated data-testid attribute or the accessible role and name, like a button named Submit, stay valid through design changes and describe intent clearly. Testers should ask developers to add test IDs.
12
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.
INVEST is a checklist for good user stories: Independent, Negotiable, Valuable, Estimable, Small and Testable. For testers, testable is the most important: a story must have clear acceptance criteria so you can say pass or fail. Small stories are easier to test within a sprint. If a story fails INVEST, raise it in refinement rather than discovering the gaps during testing.
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.
15
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.
16
How do you link stories, test cases and bugs in Jira for traceability?
Create test cases as linked issues or in a test management add-on and link each one to its story with a tests relationship. When a test fails, create the bug from the test execution or link it to both the test and the story with is blocked by or relates to. Use the same fix version for all. A story then shows its tests and open bugs, which makes sign-off and the traceability report easy.
17
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.
18
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.
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.
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.
Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request to a site, such as changing their email, because the browser automatically includes cookies. Prevention includes anti-CSRF tokens in forms, SameSite cookie settings and re-authentication for sensitive actions. Testers check that state-changing requests fail when the token is missing or reused, and that such actions are not done through GET requests.
22
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.
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.
25
Your automated tests pass one by one but fail randomly when run in parallel. How do you fix the test data so tests are independent?
Each test should create the data it needs, usually through an API or database helper, use unique values such as an email with a timestamp, and clean up afterwards. Avoid tests that depend on data made by another test or on a shared account other tests change. For fixed reference data, seed it before the suite runs. Independent data allows tests to run in parallel and in any order without random failures.
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).
Collect details from reviews and support: devices, OS versions and app version when it started. Compare battery usage of the current and previous versions on the same devices over a typical session and while idle in background. Use profiling tools to look for background location, wake locks, frequent sync or network polling. Share measurements with developers, verify the fix with the same method, and add a battery check to release testing.
30
What are the boundary values for an age field that accepts 18–60?
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.
Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.
A deep link opens a specific screen inside the app from a URL, email, SMS, QR code or notification. Test that each link opens the correct screen with the right data when the app is installed, closed or running in background. If the app is not installed, it should open the store page or a web fallback. Test links that need login, expired or invalid links, and that parameters cannot be tampered with to access other users' data.
36
How do you plan regression testing for a monthly release?
Keep a tiered regression suite: a smoke set for every build, a core set of critical flows for every release and a full set run on a rotation or before major releases. Each month, add impact-based tests from the release changes and cases for recent production bugs. Automate stable, repeated cases and keep manual effort for new or changing areas. Schedule regression early enough to fix and retest found issues.
Save filters for common views such as my open bugs, bugs ready for retest, blockers in the current sprint and bugs by fix version. Add them to a dashboard with gadgets like pie charts by priority, created versus resolved trend and a sprint bug list. Share the dashboard with the team so status is visible without manual reports. Testers start their day from the ready-for-retest filter.
38
Describe how you led a QA team through a very tight release.
Model answer: Situation: a regulatory change had to go live in ten days. Task: lead four testers. Action: I split work by risk, put our strongest tester on the calculation engine, ran daily 15-minute bug triage with developers and shared a single status dashboard. I also automated the repeated tax checks. Result: we released on the deadline with zero critical defects, and the client used our test evidence for their audit.
An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.
40
A developer asks you to test a feature that has no acceptance criteria. How do you proceed?
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.
Tips to crack the Grant Thornton Bharat Software Testing interview
Revise accounting and audit basics or IT risk concepts, depending on the service line you are applying to.
For technology and risk roles, learn basics of internal controls, IT general controls, cybersecurity frameworks and data analysis in Excel.
Prepare to explain why you prefer advisory or audit work and how you handle detail-oriented tasks under tight deadlines.
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; Grant Thornton Bharat interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Grant Thornton Bharat Software Testing interview?
Candidates usually go through 4 stages: Resume screening or online assessment; Technical interview; Managerial round; Partner 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 Grant Thornton Bharat Software Testing interview?
This practice set leans on Bug Life Cycle and Jira (7), Agile, SQL and API Testing (6), Test Case Design (5), Automation Basics for Manual Testers (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Grant Thornton Bharat interviewers ask you to walk through real work.
Are these the exact questions asked at Grant Thornton Bharat?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like Grant Thornton Bharat's. They are not a leaked or verified list of past questions.
Where does Grant Thornton Bharat hire Software Testing professionals in India?
Grant Thornton Bharat has large teams in Gurugram, Mumbai, Bengaluru, Kolkata, Chandigarh, Kochi. Openings and locations change often, so check the Grant Thornton Bharat careers page and filter by city and experience.