Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Accenture hiring for ISTQB roles
Accenture is a global professional services company offering strategy, consulting, technology, operations and digital services. India hosts a large share of its workforce, delivering software engineering, testing, cloud, data and AI projects for clients worldwide. It hires freshers and experienced professionals in India for associate software engineer, test engineer, data analyst and analytics consultant roles.
For ISTQB roles, this Accenture practice set focuses most on Testing Throughout the SDLC (7), White-Box, Experience and Collaboration-Based Testing (5), Static Testing (5), Defect and Configuration Management (3). It has 2 easy, 22 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
Dublin, Ireland
Main India offices
Bengaluru, Hyderabad, Pune, Mumbai, Gurugram
Accenture ISTQB interview process
Online assessment (cognitive + technical MCQs)
Coding assessment
Communication assessment
Technical and HR interview
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for AccentureStart 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.
White-box testing considers the whole implementation, so it can find defects even when the specification is vague, outdated or incomplete. Coverage gives an objective measure of thoroughness. It can also be used in static testing, for example dry runs of code or pseudocode. Its main weakness is that it cannot detect omissions: if a requirement was never implemented, no white-box test will notice it.
02
Explain collaborative user story writing, the 3 Cs and INVEST.
User stories are written collaboratively by business, development and testing. The 3 Cs are Card (the medium describing the story), Conversation (how the story will be used, documented or verbal) and Confirmation (the acceptance criteria). A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. If stakeholders cannot say how to test a story, it is probably unclear or does not reflect real value.
03
How does component integration testing differ from system integration testing?
Component integration testing focuses on interfaces between components of the same system and is usually done by developers or testers who know the architecture, often with stubs and drivers. System integration testing focuses on interfaces with other systems and external services, such as payment gateways or government APIs, and needs production-like environments. Incremental integration, top-down or bottom-up, is preferred over big-bang because it localises defects.
04
A production hotfix must go live in three hours. How do you decide what to test?
I would do a quick impact analysis to see what the change touches, run confirmation tests for the defect, then a risk-based regression subset covering the changed module, its integrations and critical business flows like login and payment. I would use the automated smoke suite in the pipeline, record what was not covered, and plan fuller regression in the next regular release.
All three are test-first approaches. In TDD, developers write a failing unit test, write code to pass it, then refactor. In ATDD, acceptance tests are derived from acceptance criteria with the team and business before development starts. In BDD, desired behaviour is written as Given/When/Then scenarios in natural language that stakeholders understand and that can be turned into executable tests. All three support shift-left.
06
Prepare a fault attack list for a file upload feature.
List likely failures and design tests for each: empty file; file just above the size limit; very large file; wrong extension; correct extension with wrong content; file names with spaces, Unicode or very long names; duplicate names; upload interrupted by network loss; many uploads at once; malicious files such as scripts; and uploads without login or with an expired session. Prioritise by risk.
07
Production defects increased over the last three releases. How do you analyse and act?
I would categorise escaped defects by module, root cause and the test level that should have found them, and calculate defect detection percentage per release. Typical findings are missing regression coverage, unclear requirements or environment differences. Actions might include requirement reviews, adding regression tests for each escaped defect, improving test data and environment parity, and tracking the trend to confirm improvement.
08
How does testing relate to quality assurance and quality control?
Testing is a form of quality control (QC): a product-oriented, corrective approach that checks work products. Quality assurance (QA) is process-oriented and preventive: it improves processes on the idea that a good process produces a good product. Test results are used by both. QC uses them to fix defects, and QA uses them as feedback on how well the development and test processes are performing.
09
Ten automated tests fail overnight, but the cause is an expired SSL certificate in the test environment. How should this be reported?
These failures are caused by the environment, not the test object, so they should not be logged as product defects. I would raise one environment issue with the infrastructure team, mark the test results as blocked or environment failure, and re-run after the certificate is renewed. I would also suggest monitoring certificate expiry so the same false positives do not recur.
10
Which work products can be examined by static testing?
Almost any work product that can be read and understood: requirements, user stories, acceptance criteria, architecture and design documents, source code, test plans, test cases, test charters, backlog items, contracts, project plans, schedules and budgets. Static analysis tools need work products with a formal structure, such as code or models with defined syntax. Products that are hard for humans to interpret, like third-party executable code, are not suitable for review.
The quadrants group test types by whether they are business-facing or technology-facing, and whether they support the team or critique the product. Q1 (technology, support): component and component integration tests, usually automated. Q2 (business, support): functional tests, examples, user story tests, prototypes. Q3 (business, critique): exploratory, usability and user acceptance testing. Q4 (technology, critique): smoke tests and non-functional tests except usability, such as performance and security.
12
Explain the levels of test independence with their benefits and drawbacks.
Independence ranges from none (authors test their own work), some (a peer in the same team), high (testers outside the team but in the organisation) to very high (testers from outside the organisation). Independent testers find different kinds of failures and challenge assumptions. Drawbacks include isolation from developers, communication delays, adversarial relationships and developers losing responsibility for quality. Most projects mix levels: developers test components, independent testers handle system and acceptance testing.
13
Tell me about a time a review you did prevented a serious problem.
Situation: reviewing a refund user story, I noticed it did not say how partial refunds work on discounted orders. Task: clarify it before development started. Action: I logged the gap, set up a 15-minute call with the product owner and developer, and we added three acceptance criteria with worked examples. Result: the feature shipped without the refund calculation errors that had hurt an earlier release.
14
How do you prioritise your work when several tasks are urgent?
Situation: in my internship I had regression tests, a defect retest and a test case review due the same day. Task: finish what mattered most. Action: I asked my lead which item blocked the release, did the defect retest first since a fix depended on it, then the high-risk regression tests, and moved the review to the next morning with agreement. Result: the release stayed on track.
15
What changed in CTFL v4.0 compared with the 2018 syllabus?
v4.0 added Agile and DevOps content: the whole team approach, test-first approaches like TDD, ATDD and BDD, shift-left, retrospectives, collaboration-based test approaches, the test pyramid and testing quadrants. It renamed the pesticide paradox to 'tests wear out', removed use case testing and decision coverage, focused white-box testing on statement and branch coverage, and described test roles instead of job titles.
16
Show the TDD red-green-refactor cycle with a small example.
# Red: write a failing test first
def test_discount():
assert discount(1000) == 100
# Green: simplest code that passes
def discount(amount):
return amount * 0.10
# Refactor: improve design, test stays green
RATE = 0.10
def discount(amount):
return round(amount * RATE, 2)
Repeat the cycle for each new behaviour, such as no discount below 500.
17
Give an example of a high-severity low-priority defect and a low-severity high-priority defect.
High severity, low priority: the app crashes when exporting a report in a legacy format that almost nobody uses; the impact is severe but rarely triggered, so it can wait. Low severity, high priority: the company logo is misspelled on the home page before a major launch; functionality is unaffected, but brand impact makes it urgent. Severity reflects impact, priority reflects business urgency.
18
How do you perform a simple root cause analysis on a production failure?
Collect the failure details and logs, reproduce the issue and identify the defect. Then ask 'why' repeatedly until you reach a process cause. Example: a wrong discount was shown; why? the code used an old rule; why? the requirement changed without notice; why? there was no change review step. Action: add change notifications and a review step. Fixing root causes prevents whole families of similar defects.
19
The requirements are incomplete and release is in two days. How do you test?
I would use session-based exploratory testing. I would write short charters for the riskiest areas, agree priorities with the product owner, run time-boxed sessions, note defects and questions, and debrief after each session. I would add error guessing for common failure types and a quick checklist for critical flows, and report clearly which areas were covered and which risks remain.
20
A static analysis tool reports 2,000 warnings on legacy code. What is your approach?
I would not try to fix everything at once. First, tune the rule set to remove irrelevant rules and false positives. Then classify warnings by severity and fix security issues and likely defects first. I would set a quality gate that blocks only new issues in changed code, so the codebase improves gradually. Trend reports each sprint show management steady progress.
21
A new tester has no domain knowledge and no detailed test cases. How can checklists help, and what is the risk?
A checklist of high-level conditions, such as validations, error messages, navigation and security basics, gives the new tester structure and consistency while learning the domain. Each run can vary slightly, which increases coverage. The risk is that checklists wear out as developers learn to avoid listed defects, so the team should update them with new defect patterns and pair the tester with an experienced colleague.
22
In a review, what is the difference between an anomaly and a defect?
Reviewers log anomalies: observations that differ from what they expected. Not every anomaly is a defect; some turn out to be misunderstandings, open questions or improvement suggestions. During communication and analysis the team decides each anomaly's status, owner and required action, and confirmed ones become defects for the author to fix. This keeps reviews constructive instead of treating every comment as the author's mistake.
23
What types of defects are typically found by static testing?
Requirements defects such as inconsistencies, ambiguities, contradictions, omissions and duplicates; design defects like inefficient database structures or poor modularisation; coding defects such as variables with undefined values, unreachable or duplicated code and excessive complexity; deviations from standards; incorrect interface specifications; security vulnerabilities like buffer overflows; and gaps in test coverage, such as missing tests for an acceptance criterion.
24
How are CTFL v4.0 exam questions distributed across chapters?
Approximately: Chapter 1, Fundamentals of Testing, 8 questions; Chapter 2, Testing Throughout the SDLC, 6; Chapter 3, Static Testing, 4; Chapter 4, Test Analysis and Design, 11; Chapter 5, Managing the Test Activities, 9; Chapter 6, Test Tools, 2. Chapters 4 and 5 carry half the marks and include most K3 questions, so practise techniques and estimation thoroughly.
25
What is the difference between 2-value and 3-value boundary value analysis?
BVA applies to ordered partitions. In 2-value BVA each boundary has two coverage items: the boundary value and its closest neighbour in the adjacent partition. In 3-value BVA there are three: the boundary and both neighbours. For a valid range 18 to 60, 2-value gives 17, 18, 60, 61, and 3-value gives 17, 18, 19, 59, 60, 61. 3-value is stricter and can catch defects like 'x == 18' written instead of 'x >= 18'.
26
How should you answer 'select TWO' questions in the CTFL exam?
Read the instruction carefully, because you must select exactly two options and usually get the point only if both are correct. Evaluate each option separately as true or false against the syllabus. Eliminate absolute statements and options that describe a different concept. If you are sure of one, compare the remaining options carefully. These questions appear in the exam, so practise them in sample papers.
27
Build a decision table for a loan rule: approve if salary is at least 30,000 and credit score is at least 700; refer if only one is met; otherwise reject.
Conditions R1 R2 R3 R4
Salary >= 30000 T T F F
Score >= 700 T F T F
Actions
Approve X - - -
Refer to officer - X X -
Reject - - - X
Two Boolean conditions give 2 x 2 = 4 rules, so 4 test cases give 100 percent decision table coverage.
28
Your company is migrating customer data from a legacy system to the cloud. What testing is needed?
This is maintenance testing triggered by migration. I would check data completeness with record counts and checksums, data accuracy through sampling and reconciliation reports, transformation rules, performance on the new platform and rollback procedures. Operational acceptance testing covers backup, restore and failover. Regression testing of key functions on migrated data is needed, and retiring the old system may need archiving tests.
29
Why does CTFL v4.0 recommend starting non-functional testing early?
Non-functional tests are often left to the end, but late discovery of performance or security problems can threaten the whole project. v4.0 recommends starting early, even at component level, for example measuring response time of a key service. Some tests need special environments such as a usability lab. Many non-functional tests reuse functional tests but measure a different quality, like checking login speed under 500 concurrent users.
30
Describe how you convinced a team to adopt shift-left testing.
Situation: our releases had many defects traced to unclear requirements. Task: reduce them without slowing delivery. Action: I showed data that about 40 percent of defects started in requirements, piloted requirement reviews and three-amigos sessions in one team, and tracked the results. Result: requirement-related defects dropped by roughly half over two releases, and other teams adopted the practice.
Tips to crack the Accenture ISTQB interview
Practise the communication assessment, which checks spoken English through reading, listening and repeating sentences in a recorded format.
Revise MS Office, cloud basics, networking and pseudocode, as Accenture technical MCQs often cover these general IT topics.
Read about Accenture's focus on cloud, data and AI and be ready to discuss how you would work in client-facing 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; Accenture interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Accenture ISTQB interview?
Candidates usually go through 4 stages: Online assessment (cognitive + technical MCQs); Coding assessment; Communication assessment; Technical and HR interview. 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 Accenture ISTQB interview?
This practice set leans on Testing Throughout the SDLC (7), White-Box, Experience and Collaboration-Based Testing (5), Static Testing (5), Defect and Configuration Management (3). Revise those first, then practise explaining one or two of your own projects end to end, because most Accenture interviewers ask you to walk through real work.
Are these the exact questions asked at Accenture?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like Accenture's. They are not a leaked or verified list of past questions.
Where does Accenture hire ISTQB professionals in India?
Accenture has large teams in Bengaluru, Hyderabad, Pune, Mumbai, Gurugram. Openings and locations change often, so check the Accenture careers page and filter by city and experience.