Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About EPAM Systems hiring for ISTQB roles
EPAM Systems is a global digital platform engineering and software development services company. It works on product development, quality engineering, cloud and data projects for clients in finance, life sciences, retail and software. Its India delivery centres hire for software engineers, test automation engineers, data engineers and data scientists.
For ISTQB roles, this EPAM Systems practice set focuses most on Static Testing (6), Testing Throughout the SDLC (5), Fundamentals of Testing (4), Managing the Test Activities (4). It has 16 easy, 13 medium, 1 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Newtown, Pennsylvania, USA
Main India offices
Hyderabad, Bengaluru, Pune, Chennai, Gurugram
EPAM Systems ISTQB interview process
Online coding assessment
Technical interview
Technical or design round
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for EPAM 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
Testing found 80 defects and users found 20 more after release. What is the defect detection percentage?
DDP = defects found in testing / (defects found in testing + defects found after release) x 100
= 80 / (80 + 20) x 100
= 80 / 100 x 100
= 80 percent
So testing caught 80 percent of known defects. Tracking DDP across releases shows whether test effectiveness is improving.
02
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.
03
Which good testing practices apply regardless of the SDLC model?
CTFL v4.0 lists these: for every software development activity there is a corresponding test activity; each test level has its own specific objectives; test analysis and design for a level begin during the corresponding development phase; and testers are involved in reviewing work products as soon as drafts are available. Together these practices support early testing and quality control in waterfall, V-model and Agile projects alike.
04
A defect you closed last week appears again in a new build. What could be the cause and what do you do?
Possible causes include a code merge that overwrote the fix, a fix made only in one branch, or a deployment of an older artefact. I would re-open the defect with evidence and the build numbers, ask the team to check version control history, and add an automated regression test for the defect so it is caught immediately if it returns again.
05
What are the typical objectives of testing according to the ISTQB CTFL v4.0 syllabus?
Testing objectives include evaluating work products such as requirements and code, triggering failures and finding defects, ensuring required coverage of the test object, reducing the risk of poor quality, verifying that specified requirements are met, checking compliance with contracts or regulations, giving stakeholders information for decisions, building confidence in quality, and validating that the test object works as users expect. Objectives vary with context, test level and the SDLC model.
06
What is the difference between verification and validation?
Verification checks whether the system meets its specified requirements: 'Are we building the product right?' Validation checks whether the system meets user and stakeholder needs in its operational environment: 'Are we building the right product?' Both are testing objectives. Example: verification confirms the eight-character password rule is implemented, while validation checks that real users can actually register easily on a mobile phone.
07
Historically, development and test effort are in the ratio 3:2. Development is estimated at 600 person-days. Estimate the test effort.
This is estimation based on ratios. Test effort = development effort x 2 / 3 = 600 x 2 / 3 = 400 person-days. The ratio must come from similar past projects in the same organisation, because it changes with domain, risk and process maturity. I would also cross-check with another technique, such as Wideband Delphi, before committing to the number.
08
Give a checklist you would use to review a user story.
Is it written as 'As a [role], I want [goal], so that [benefit]'? Does it follow INVEST: independent, negotiable, valuable, estimable, small and testable? Are acceptance criteria clear, measurable and testable? Are error flows and edge cases covered? Are terms consistent with the glossary? Are dependencies and non-functional needs stated? Are vague words like 'quickly' or 'etc.' present? Log each anomaly with location, description and a suggestion.
The manager decides what is reviewed and provides resources. The author creates and fixes the work product. The moderator, or facilitator, ensures meetings run effectively, mediating and managing time. The scribe, or recorder, collects anomalies and records decisions. Reviewers perform the review and may be team members, experts or stakeholders. The review leader takes overall responsibility, deciding who is involved and organising the review. One person can hold several roles.
10
How does configuration management support testing?
Configuration management identifies, controls and tracks work products such as test plans, test cases, scripts, test results, test data, environments and the test object itself. It ensures all configuration items are uniquely identified, version controlled, tracked for changes and related to each other so traceability is kept. Baselines can only be changed through formal change control. This lets testers know exactly which build and testware versions were tested.
The test pyramid shows that tests have different granularity and that a healthy suite has many small, fast, isolated tests at the bottom, such as unit or component tests, and fewer large, slow, complex end-to-end tests at the top, such as UI tests. Middle layers often cover API or integration tests. The pyramid helps teams plan automation so the suite is fast, stable and cheap to maintain.
12
Explain error, defect, failure and root cause with an example.
A human makes an error (mistake), for example misreading a requirement. The error produces a defect (fault or bug) in a work product such as code or a document. When defective code is executed it may cause a failure, meaning the system does something wrong or fails to do something. The root cause is the fundamental reason for the error, such as time pressure or unclear requirements. Failures can also come from environmental conditions like radiation.
13
Tell me about an exploratory testing session that found a critical defect.
Situation: a ticket booking app had passed all scripted tests. Task: run a one-hour exploratory session on seat selection. Action: I tried quick double taps, switching networks and booking the same seat from two devices. Result: two users could book the same seat. I logged a detailed report with videos, it was fixed before release, and concurrency tests were added to the regression suite.
14
Which black-box test techniques are covered in CTFL v4.0?
CTFL v4.0 covers four black-box techniques: equivalence partitioning, boundary value analysis (2-value and 3-value), decision table testing and state transition testing. They derive tests from the specification without looking at the internal structure, so tests stay valid even when the implementation changes. Use case testing, which was in older syllabi, is no longer part of the v4.0 Foundation syllabus.
In the whole team approach, any team member with the right knowledge can perform any task, and everyone is responsible for quality. The team shares a physical or virtual workspace, and testers work closely with business representatives to create acceptance tests and with developers to agree the test strategy and automation. It improves communication and uses combined skills, although safety-critical contexts may still need higher test independence.
Shift-left means performing testing earlier in the SDLC. Practices include reviewing specifications from a tester's perspective, writing test cases before code, using CI/CD for fast feedback, running static analysis before dynamic testing and starting non-functional testing at component level. It costs extra effort early, but saves much more later, because a defect found in requirements is far cheaper to fix than one found in production.
17
Describe the activities of the review process in CTFL v4.0.
Planning defines scope, purpose, quality characteristics, exit criteria, effort and timeframe. Review initiation ensures everyone has access and is ready. In individual review, each reviewer assesses the work product and logs anomalies, recommendations and questions. Communication and analysis discusses anomalies and decides their status and actions. Fixing and reporting creates defect reports, the author fixes them, and results are reported against exit criteria.
18
Your team says reviews are a waste of time. How do you change their minds?
I would bring data: track defects found in reviews and estimate what they would have cost if found in system testing or production. I would also make reviews lighter: smaller chunks, checklists, time-boxed sessions, asynchronous tool-based reviews and static analysis to automate routine checks. Matching the review type to each work product keeps the cost low, and sharing the savings usually wins support.
19
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.
Functional testing checks what the system should do, covering completeness, correctness and appropriateness. Non-functional testing checks how well it behaves, using ISO/IEC 25010 characteristics such as performance efficiency, usability, security, reliability, compatibility, maintainability and portability. Black-box testing is specification-based, and white-box testing is structure-based. Any test type can be applied at any test level, with a different focus at each.
21
Write a test charter for an exploratory session on a checkout page.
Charter: Explore the checkout page with different coupon and payment combinations to discover pricing and rounding errors. Time box: 60 minutes. Focus areas: coupon stacking, expired coupons, quantity changes after applying a coupon, currency rounding, and using the browser back button. Record test ideas, defects, questions and areas covered. Debrief with the test lead after the session to agree next charters.
22
Show two defects a static analysis tool can find without running the code.
def get_discount(amount):
if amount > 1000:
rate = 0.1
return amount * rate # rate undefined when amount <= 1000
def old_helper():
return 0
print('done') # unreachable code
The tool flags a possibly undefined variable, a data flow anomaly, and unreachable code. Both are found statically, before any test is executed.
Situation: our team wrote test cases with no clear technique, and suites kept growing. Task: improve efficiency. Action: I applied equivalence partitioning and boundary value analysis to the form validations and used decision tables for pricing rules, removing redundant tests. Result: we cut the regression suite by about 30 percent while finding more boundary defects, and my lead asked me to train two juniors.
24
What is the difference between a test progress report and a test completion report?
A test progress report is produced regularly during testing, for example daily or per sprint. It covers the period, progress against plan, impediments, metrics, new or changed risks and planned work. A test completion report is prepared at the end of a test level, iteration or project. It summarises testing, evaluates quality against the plan, lists deviations, unmitigated risks, open defects, metrics and lessons learned.
25
What is the difference between confirmation testing and regression testing?
Confirmation testing checks that an original defect has been fixed, by re-running the failed tests or new tests that cover the change. Regression testing checks that a change, including a fix, has not caused adverse effects elsewhere, in the same component, connected components or the environment. Regression suites grow and run often, so they are strong candidates for automation, typically inside a CI pipeline.
A retrospective is held at the end of an iteration, release or project to discuss what went well, what did not and how to improve. For testing, the benefits include more effective and efficient testing, better testware, team bonding, better quality of the test basis and stronger cooperation between developers and testers. Results should be recorded and the improvement actions tracked so that they are actually carried out.
27
What categories of test tools does CTFL v4.0 describe?
Test management tools, static testing tools, test design and implementation tools, test execution and coverage tools, non-functional testing tools, DevOps tools such as CI/CD pipelines and build tools, collaboration tools, and tools supporting scalability and deployment standardisation such as virtual machines and containers. Any tool that assists testing counts, even a spreadsheet. Tools improve efficiency, quality and repeatability.
Register through the ISTQB member board for India or an ISTQB-accredited exam provider. Create an account, choose CTFL v4.0, and pick either an online proctored exam or a test centre. For online exams, check your webcam, microphone and internet in advance, and keep a valid government photo ID ready. Results are usually shared soon after the exam, followed by the certificate.
29
Tell me about a time you delivered testing under a very tight deadline.
Situation: a regulatory change had to go live in five days. Task: test it without missing critical risks. Action: I ran a quick risk analysis with the product owner, focused on calculation rules and reports, automated repetitive data checks, and gave daily status updates. Result: we released on time with no production defects in high-risk areas, and lower-risk cosmetic issues were fixed in the next sprint.
30
Explain equivalence partitioning and its coverage.
Equivalence partitioning divides data into partitions whose values are expected to be processed the same way, so one value per partition is enough. Partitions can cover inputs, outputs, configuration items or time, and include valid and invalid partitions. They must be non-empty and must not overlap. Coverage is partitions exercised divided by partitions identified. With several inputs, Each Choice coverage requires every partition of every input to be used at least once.
Tips to crack the EPAM Systems ISTQB interview
Revise core concepts in Java, Python or JavaScript deeply, as EPAM interviews often test language fundamentals in detail.
Prepare test automation framework design questions if applying for QA roles, including page object model and CI integration.
Read about EPAM's engineering-first identity and its learning platforms, which it highlights for career growth.
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; EPAM Systems interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the EPAM Systems ISTQB interview?
Candidates usually go through 4 stages: Online coding assessment; Technical interview; Technical or design round; Hiring manager 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 EPAM Systems ISTQB interview?
This practice set leans on Static Testing (6), Testing Throughout the SDLC (5), Fundamentals of Testing (4), Managing the Test Activities (4). Revise those first, then practise explaining one or two of your own projects end to end, because most EPAM Systems interviewers ask you to walk through real work.
Are these the exact questions asked at EPAM Systems?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like EPAM Systems's. They are not a leaked or verified list of past questions.
Where does EPAM Systems hire ISTQB professionals in India?
EPAM Systems has large teams in Hyderabad, Bengaluru, Pune, Chennai, Gurugram. Openings and locations change often, so check the EPAM Systems careers page and filter by city and experience.