Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Virtusa hiring for ISTQB roles
Virtusa is a digital engineering and IT services company providing application development, testing, cloud and data services. It has a strong client base in banking, financial services, healthcare and telecom. Its India centres in Hyderabad, Chennai and Bengaluru hire for software engineers, test engineers and data professionals.
For ISTQB roles, this Virtusa practice set focuses most on White-Box, Experience and Collaboration-Based Testing (6), Fundamentals of Testing (6), Testing Throughout the SDLC (5), Defect and Configuration Management (4). It has 12 easy, 18 medium questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Southborough, Massachusetts, USA
Main India offices
Hyderabad, Chennai, Bengaluru
Virtusa ISTQB interview process
Online assessment (aptitude + reasoning)
Coding test
Technical interview
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for VirtusaStart 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
Find the minimum tests for statement and branch coverage when there are two independent if statements in sequence.
if a > 0:
s1
if b > 0:
s2
Statement coverage: one test with a = 1 and b = 1 runs s1 and s2, so 1 test.
Branch coverage: each if needs a true and a false outcome. Tests (a = 1, b = 1) and (a = 0, b = 0) cover all four branches, so 2 tests.
02
Walk through the steps of running a technical review of a design document.
Plan: define scope, objective and exit criteria and choose reviewers with the right expertise. Initiate: share the document, checklist and timeline. Individual review: each reviewer logs anomalies in a shared tool. Communication and analysis: the moderator runs the meeting, the team discusses anomalies and agrees actions. Fixing and reporting: the author updates the document, defects are tracked, and results are checked against exit criteria.
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.
Error guessing anticipates errors, defects and failures based on the tester's knowledge: how the application worked before, the types of mistakes developers tend to make, and failures seen in similar applications. A methodical form is the fault attack: list possible errors, defects and failures, then design tests to expose them. Examples include division by zero, empty inputs, very long strings, special characters and wrong date formats.
05
Tell me about a time testing was squeezed at the end of a sprint. What did you do?
Situation: stories reached me only in the last two days of each sprint. Task: stop testing from being a bottleneck. Action: I proposed writing acceptance criteria and test cases during refinement, asked developers to merge smaller stories earlier, and automated API checks in the CI pipeline. Result: within three sprints, carried-over stories fell from five to one, and the team added early testing to its definition of done.
06
Why do you want to start your career in software testing?
Model answer: I enjoy finding how things break and thinking from the user's side. During my degree I tested our team project and found issues others missed, which built my interest. I studied the ISTQB Foundation syllabus to learn standard terms and techniques. I want to grow from manual testing into automation and domain expertise, and testing lets me understand the whole product and the full SDLC.
07
Name the main test activities in the ISTQB test process.
The test process has seven activity groups: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion. They are often iterative or done in parallel rather than strictly sequential. How they are carried out depends on context, such as the SDLC, product risks, budget, time, team skills and regulations, so an Agile team performs them in small loops in every iteration.
08
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.
09
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.
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.
11
Discount depends on customer type (regular, gold, platinum) and whether the order exceeds 1,000 rupees. How many rules does the full decision table have?
When conditions are not Boolean, multiply the number of values of each condition. Customer type has 3 values and the order condition has 2, so the full table has 3 x 2 = 6 rules. Each rule becomes one test case for 100 percent decision table coverage. If, for example, platinum always gets the same discount regardless of amount, those two columns can be merged, giving 5.
A defect is logged as new or open, then triaged: it may be rejected, marked duplicate or deferred, or assigned for fixing. After the developer fixes it, it moves to awaiting confirmation testing. The tester re-tests; if it passes, the defect is closed, and if it fails, it is re-opened. Teams customise the workflow, but each status should have clear rules about who can move it and when.
13
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.
14
A tester uses past experience to test division by zero, empty fields and invalid dates. Which technique is this?
This is error guessing, an experience-based technique. The tester anticipates mistakes based on knowledge of similar applications, typical developer errors and past failures. When done methodically by listing possible errors and designing tests for each, it is called a fault attack. It is not checklist-based testing unless the tester works from a prepared checklist of conditions.
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.
16
Describe a situation where a developer rejected your defect. How did you handle it?
Situation: a developer marked my defect 'works as designed'. Task: resolve it without conflict. Action: I re-read the user story, attached the acceptance criteria that contradicted the behaviour, and discussed it calmly with the developer and product owner, focusing on user impact rather than blame. Result: the product owner confirmed it was a defect, and we clarified the story wording so similar confusion did not happen again.
17
Derive test conditions for the requirement 'Users can transfer up to 50,000 rupees per day.'
Read the test basis and list testable aspects. Conditions: a transfer within the limit succeeds; a transfer of exactly 50,000 succeeds; a transfer above 50,000 is rejected with a clear message; several transfers in one day are added together against the limit; the limit resets the next day; zero or negative amounts are rejected. Prioritise them by risk, then design test cases with exact amounts using boundary value analysis.
18
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.
19
The product owner writes vague acceptance criteria such as 'search should work well'. What do you do?
I would suggest a short three-amigos session with the product owner and a developer. Together we would turn the vague criterion into testable ones, for example 'searching by product name returns matching items sorted by relevance', 'no results shows a helpful message' and 'results load in under 2 seconds'. Writing them as Given/When/Then scenarios makes them clear and ready for ATDD.
20
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.
21
How do you prioritise risks using a likelihood and impact matrix?
Score each risk for likelihood and impact on a scale such as 1 to 5, and multiply to get the risk level. Example: wrong interest calculation, likelihood 3 and impact 5, level 15; slow report export, likelihood 4 and impact 2, level 8; spelling errors, 4 and 1, level 4. Test the highest levels first and most deeply, using more rigorous techniques and earlier test execution.
A defect report gives the people responsible for handling and resolving the defect enough information to fix it. It also provides a way to track the quality of the work product, and it offers ideas for improving the development and test processes. A good report is clear, reproducible and neutral in tone, so that developers can act on it quickly and managers can analyse trends.
23
Why does 100 percent branch coverage guarantee 100 percent statement coverage, but not the other way round?
Every statement lies on at least one branch, so exercising all branches executes all statements. The reverse fails when a decision has an empty outcome. Example: 'if x > 10: print(big)' followed by 'print(done)'. One test with x = 15 runs every statement, giving 100 percent statement coverage, but the false branch is never taken, so branch coverage is only 50 percent. This is called subsumption.
24
Why is traceability between the test basis and testware important?
Traceability links test basis items such as requirements, risks and user stories to test conditions, test cases, results and defects. It lets teams measure coverage, assess the impact of changes, support audits in regulated domains and report progress in business terms, for example 'requirement R12 has three passed tests and one open defect'. When a requirement changes, traceability shows exactly which tests must be updated or re-run.
25
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.
26
A developer says your defect cannot be reproduced. What do you do?
I would re-check that I can reproduce it, then add missing details: exact build version, environment, browser or device, user role, test data, timestamps, logs and a screen recording. I would check whether it is intermittent and note the frequency. If needed, I would reproduce it live with the developer. If it truly cannot be reproduced, we can keep it open with monitoring rather than close it.
27
Suggest a four-week study plan for a fresher preparing for CTFL v4.0.
Week 1: chapters 1 and 2, the seven principles, test activities, test levels and test types; make notes of key terms. Week 2: chapter 3 and black-box techniques, solving at least 30 EP, BVA, decision table and state transition problems. Week 3: white-box and experience-based techniques, chapters 5 and 6, with estimation and risk exercises. Week 4: three or more timed sample exams and revision of mistakes.
The exam has 40 multiple-choice questions, each worth one point. The duration is 60 minutes, and candidates taking it in a non-native language usually get 25 percent extra time, making 75 minutes. The pass mark is 65 percent, which means 26 correct answers. There is no negative marking. Questions are mapped to learning objectives at K1, K2 and K3 levels.
29
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.
30
Which test estimation techniques are described in CTFL v4.0?
Estimation based on ratios uses historical figures, such as a development-to-test effort ratio. Extrapolation uses measurements from the current project, for example averaging the last three iterations. Wideband Delphi is an expert-based technique where experts estimate separately and iterate until consensus; Planning Poker is an Agile variant. Three-point estimation uses optimistic, most likely and pessimistic values to calculate a weighted estimate and its standard deviation.
Tips to crack the Virtusa ISTQB interview
Revise banking and healthcare domain basics, which are important industries in Virtusa's client portfolio.
Practise coding questions and SQL queries for both the online test and technical interview.
Learn about its engineering-first positioning and be ready to describe how you approach learning new tools.
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; Virtusa interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Virtusa ISTQB interview?
Candidates usually go through 4 stages: Online assessment (aptitude + reasoning); Coding test; Technical interview; 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 Virtusa ISTQB interview?
This practice set leans on White-Box, Experience and Collaboration-Based Testing (6), Fundamentals of Testing (6), Testing Throughout the SDLC (5), Defect and Configuration Management (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Virtusa interviewers ask you to walk through real work.
Are these the exact questions asked at Virtusa?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Virtusa's. They are not a leaked or verified list of past questions.
Where does Virtusa hire ISTQB professionals in India?
Virtusa has large teams in Hyderabad, Chennai, Bengaluru. Openings and locations change often, so check the Virtusa careers page and filter by city and experience.