Foundation-level testing theory: interview questions

Testing theory questions show up in fresher interviews, service-company written rounds and as the first ten minutes of many experienced-hire interviews. Interviewers rarely want a definition recited. They want the definition and then a worked example: "Here are the boundary values for an age field of 18 to 60, and here is why 19 matters". This page gives both. The broader everyday questions (STLC, bug life cycle, severity and priority) are on the manual testing and freshers pages, so they are not repeated here.

Principles and process

1. What are the seven testing principles? Explain them with examples.

1. Testing shows defects are present, not that they are absent. Passing 500 tests on a UPI app does not prove it has no bugs.
2. Exhaustive testing is impossible. A ten-character password field has more combinations than any team could run; use techniques and risk to choose.
3. Early testing saves time and money. A wrong refund rule caught in a requirement review costs a conversation; caught in production it costs refunds and complaints.
4. Defects cluster together. A few modules (often payments, or the code everyone is afraid to touch) hold most of the defects, so test them harder.
5. Tests wear out. The same tests repeated stop finding new defects; refresh test data and add new tests. (Older material calls this the pesticide paradox.)
6. Testing is context dependent. A banking app and a college fest website need different rigour.
7. The absence-of-defects fallacy. A bug-free system that users cannot use or do not need is still a failure; validate as well as verify.

2. What are the main activities in a test process?

Planning (objectives, approach, schedule), monitoring and control (comparing progress with the plan and acting on it), analysis (what to test: test conditions from the test basis), design (how to test: test cases, data, environment needs), implementation (preparing test procedures, scripts, data and the environment), execution (running tests, comparing results, logging and reporting defects), and completion (closing reports, archiving testware, lessons learned). They overlap and repeat in iterative projects; they are not a strict waterfall.

3. What is the test basis, and what is a test condition?

The test basis is whatever you derive tests from: requirements, user stories, designs, the code, or how a previous version behaved. A test condition is a testable aspect of it, for example "a refund is rejected if the order is older than 30 days". Test cases then exercise test conditions with specific data and expected results.

4. What is testware, and why does traceability matter?

Testware is everything testing produces: plans, conditions, cases, scripts, data, logs, defect reports and reports. Traceability links them to the test basis and to each other (requirement to test case to result to defect). It lets you answer "which requirements are untested?", "what must we re-run if this story changes?" and "which features does this defect affect?". The usual tool is a traceability matrix.

5. What is the difference between testing and debugging?

Testing finds failures (dynamic testing) or defects directly (static testing, such as reviews). Debugging is what the developer does next: reproduce the failure, find the defect causing it, and fix it. After the fix, the tester runs confirmation testing (does the original failure no longer happen?) and regression testing (did the fix break anything else?). See regression testing vs retesting.

6. What is the difference between error, defect, failure and root cause?

A person makes an error (a mistake), which produces a defect in a work product (code, requirement, test script), which may cause a failure when executed. The root cause is why the error happened: a misunderstood requirement, time pressure, missing training. Fixing the defect removes one bug; fixing the root cause prevents a family of them. More detail in bug vs defect vs error vs failure.

7. What are the benefits and drawbacks of independent testing?

Independent testers notice different failures because they do not share the author's assumptions, and they can challenge assumptions in requirements. The drawbacks: isolation from the development team, slower feedback, and developers feeling less responsible for quality ("testers will catch it"). Most teams use a mix: developers test their components, testers within the team test the system, and business users do acceptance testing.

Levels, types and lifecycle

8. What are the test levels?

Component (unit) testing checks pieces in isolation, usually by developers. Component integration testing checks interfaces between components. System testing checks the whole system's behaviour and quality characteristics. System integration testing checks interfaces with other systems and external services (a payment gateway, an SMS provider). Acceptance testing checks whether the system meets user and business needs and is ready to deploy. Levels differ in their test object, objectives, test basis, typical defects and who does the testing.

Likely follow-up: What forms of acceptance testing are there? User acceptance testing, operational acceptance testing (backups, recovery, monitoring), contractual and regulatory acceptance testing, and alpha and beta testing. See alpha vs beta testing.

9. What are the test types?

Functional testing (what the system does), non-functional testing (how well: performance, security, usability, compatibility, reliability and so on), black-box testing (based on the specification) and white-box testing (based on the internal structure). Any type can be done at any level: performance testing of one component is as valid as performance testing of the whole system. Confirmation and regression testing are change-related testing, also done at every level.

10. What is maintenance testing, and what triggers it?

Testing a system that is already in use after something changes. Triggers: modifications (enhancements, bug fixes, hot fixes), changes to the environment (an upgrade or migration to new infrastructure, data migration from an old system), and retirement (archiving data and checking it can be restored). The scope depends on the risk and size of the change and the size of the system.

11. What is shift-left, and how does the development lifecycle affect testing?

Shift-left means testing earlier: reviewing requirements, writing tests before or with the code, running them in CI. In sequential models such as the V-model, each development phase has a matching test level and planning starts early, but execution comes late. In iterative and Agile models, every iteration includes testing, automation becomes essential for regression, and testers work in the team. The principles are the same; timing and documentation change.

12. What are the testing quadrants?

A model for Agile teams that sorts tests along two axes: business-facing or technology-facing, and supporting the team (guiding development) or critiquing the product. Q1 (technology, support): unit and component integration tests, automated. Q2 (business, support): functional and story tests, examples, API tests. Q3 (business, critique): exploratory, usability and user acceptance testing, often manual. Q4 (technology, critique): non-functional tests such as performance and security, often tool-driven. It helps a team check it is not doing only one kind of testing.

Static testing

13. What is static testing, and what can it find that dynamic testing cannot?

Examining work products without executing them: reviews of requirements, stories, designs, code and test cases, and static analysis by tools. It finds defects early and directly, including ones dynamic testing struggles with: ambiguous or contradictory requirements, missing requirements, unreachable code, coding-standard violations and security patterns in code. It works on things that cannot be executed at all, like a requirements document.

14. What review types are there, from least to most formal?

An informal review (no defined process, for example a colleague reading your test cases), a walkthrough (led by the author, used to share understanding or gather feedback), a technical review (technically qualified reviewers led by a moderator, aimed at reaching decisions on a technical problem), and an inspection (the most formal: a defined process, roles, metrics; the author may not lead it). Teams pick the type to match the risk of the work product.

15. What roles are there in a formal review?

The author (wrote the work product), the manager (decides what to review and provides resources), the moderator or facilitator (runs the review meetings), the scribe or recorder (collects anomalies and decisions), the reviewers (examine the work product) and the review leader (overall responsibility for organising the review). In small teams one person can hold more than one role.

Test techniques

16. What is equivalence partitioning? Give an example.

Dividing inputs (or outputs) into groups the system should treat the same way, then testing one value from each group. For an age field that accepts 18 to 60: valid partition 18 to 60; invalid partitions below 18 and above 60; and, depending on the field, non-numeric input and empty input. Test values: 35, 10, 75, "abc", empty. Each invalid partition gets its own test so that one rejection does not hide another.

17. What is boundary value analysis, and what is the difference between 2-value and 3-value BVA?

Defects gather at the edges of partitions (a developer writes > instead of >=), so you test the boundaries. In 2-value BVA you test each boundary value and its closest neighbour in the adjacent partition. In 3-value BVA you test each boundary and both its neighbours.

def boundary_values(low, high, three_value=False):
    """Boundary values for a valid integer range low..high."""
    if three_value:
        return sorted({low - 1, low, low + 1, high - 1, high, high + 1})
    return [low - 1, low, high, high + 1]


print(boundary_values(18, 60))                    # [17, 18, 60, 61]
print(boundary_values(18, 60, three_value=True))  # [17, 18, 19, 59, 60, 61]

Why the extra values help: take a rule "parcels of 10 kg or less ship free" (whole kilograms) that a developer codes as weight == 10 instead of weight <= 10. The only boundary is between 10 and 11. 2-value BVA tests 10 (free, correct) and 11 (charged, correct) and misses the bug. 3-value BVA also tests 9, which the code wrongly charges. For non-integer data (amounts in rupees and paise), the neighbour is the smallest step, such as one paisa.

Likely follow-up: What are the boundaries for a password of 8 to 16 characters? Lengths 7, 8, 16 and 17 for 2-value; add 9 and 15 for 3-value.

18. What is decision table testing? Show one.

A technique for business rules that combine conditions. List the conditions, the actions, and one column (rule) per combination. Example: free delivery if the customer is a member or the order is ₹500 or more.

With n yes/no conditions there are 2 to the power n rules (here 4). Rules with the same outcome can sometimes be merged, and impossible combinations are removed. The table often exposes gaps in the requirement: what about exactly ₹500, or a member whose membership expired today?

19. What is state transition testing?

Testing a system whose behaviour depends on its current state and the event that occurs. Model the states, events and transitions, then design tests to cover them. Example: OTP login. States: waiting for OTP, logged in, locked. Events: correct OTP, wrong OTP (third attempt locks), OTP expired, resend. Tests cover each valid transition (valid transitions coverage, also called 0-switch coverage) and attempt invalid ones, such as entering an OTP while locked. Full valid-transitions coverage also visits every state, so it is stronger than covering all states alone. See the OTP verification test cases.

20. What is the difference between statement coverage and branch coverage?

Statement coverage measures the percentage of executable statements your tests ran. Branch coverage measures the percentage of decision outcomes (each if true and false, each case) they took. 100% branch coverage gives 100% statement coverage, but not the other way round. Example:

def delivery_fee(total_paise, is_member):
    fee = 4000
    if total_paise >= 50000:
        fee = 0
    if is_member:
        fee = 0
    return fee


def test_member_with_big_order_pays_nothing():
    assert delivery_fee(60000, True) == 0

This one test runs every statement, so statement coverage is 100%. But both if statements only ever went the "true" way, so branch coverage is 2 of 4 outcomes, 50%. Coverage.py 7.17.3 with --branch reported 0 missed statements and listed the two untaken branches (3->5 and 5->7). Adding assert delivery_fee(49999, False) == 4000 takes both false outcomes and brings branch coverage to 100%, and it is the test that would catch a wrong fee for ordinary customers.

21. What are experience-based techniques?

Error guessing (anticipating likely mistakes from experience: empty input, zero, duplicate submission, the 31st of a month), exploratory testing (designing and running tests at the same time, often in time-boxed sessions with a charter, and learning as you go), and checklist-based testing (working through a list of conditions built from experience, such as a checklist for every new form). They complement specification-based techniques, especially when requirements are thin.

22. What are collaboration-based approaches such as ATDD?

Testers, developers and business people define tests together before or during development. Collaborative user story writing uses the card, the conversation and the confirmation (acceptance criteria), and good stories are often checked with the INVEST mnemonic (independent, negotiable, valuable, estimable, small, testable). In acceptance test-driven development (ATDD), examples and acceptance tests are written first, often in a Given/When/Then format, then automated, and the code is written to pass them. See the Cucumber and BDD questions.

Management

23. What are entry and exit criteria, and how do they relate to Definition of Ready and Done?

Entry criteria are conditions to start an activity (requirements reviewed, test environment ready, build smoke-tested). Exit criteria are conditions to finish it (planned tests run, no open critical defects, agreed coverage reached, reports done). In Agile teams the Definition of Ready plays the role of entry criteria for a story and the Definition of Done the role of exit criteria. Criteria should be measurable, or they turn into arguments at release time.

24. How do you estimate test effort? Give a worked example.

Common techniques: ratios from past projects (if testing took 40 person-days for every 100 of development on similar work, use that ratio), extrapolation from measurements so far in this project (the average of the last three sprints), Wideband Delphi (experts estimate separately, discuss outliers and re-estimate; Planning Poker is a variant), and three-point estimation. For three-point, with optimistic a = 4 days, most likely m = 7 and pessimistic b = 16: estimate E = (a + 4m + b) / 6 = (4 + 28 + 16) / 6 = 8 days, and the spread SD = (b − a) / 6 = 2 days, so roughly 6 to 10 days. Always state the assumptions behind an estimate.

25. What is risk-based testing? What are product and project risks?

Using risk to decide what to test, how deeply, and in what order. Risk level comes from likelihood and impact. Product risks are about the quality of the product (wrong interest calculation, data leak, slow checkout on sale day). Project risks are about the project (late builds, an unavailable test environment, a key tester leaving). Product risks drive test design and priority; project risks go to whoever manages the plan, with mitigations.

26. What is the test pyramid?

A model that says to have many fast, cheap, low-level tests (unit), fewer service or API tests in the middle, and few slow end-to-end UI tests at the top. The higher a test is, the slower, more fragile and more expensive to maintain it tends to be. It is a guide, not a law: some systems justify more integration tests. The usual mistake it warns against is the "ice-cream cone": mostly manual and UI tests with few unit tests.

27. What do test monitoring, control and reporting involve?

Monitoring gathers information: tests planned versus run, pass and fail counts, defects found and fixed, coverage of requirements and risks. Control acts on it: re-prioritise tests, add resources, change the scope or the dates, raise risks. Progress reports go out regularly during testing; a completion report summarises the result at the end, with what was not tested and why. The audience decides the level of detail: a developer wants the failing test, a manager wants the risk.

28. What is configuration management, and why does a tester care?

Keeping track of versions of everything involved: code, builds, requirements, test cases, scripts, test data and environments, and which versions belong together. It lets you say exactly which build and test version produced a result, reproduce a failure, and avoid testing the wrong build. Version control (Git) for test code is the everyday form of it.

29. What should a defect report contain?

An identifier, a short descriptive title, the date and author, the test object and environment (build, browser, device), the context (test case, test data), steps to reproduce, expected and actual results, severity and priority, attachments (screenshots, logs), the status, and references to the related requirement or test. A good report lets a developer reproduce the issue without asking a single question. The bug report template has a filled-in example.

30. What are the benefits and risks of test automation tools?

Benefits: repetitive work done faster and more consistently (regression, data setup), objective measures such as coverage, earlier and more frequent feedback in CI, and checks that are impractical by hand (large data, performance). Risks: unrealistic expectations, underestimating the cost of building and maintaining scripts, relying on a tool or vendor that is later dropped, using automation where human judgement is needed (usability), and treating a green dashboard as proof of quality. A pilot on a small, real scope before rolling out a tool reduces most of these risks.

Check yourself

1. A discount field accepts 1 to 50 percent. List the 3-value boundary values.
2. Three yes/no conditions: how many rules does a full decision table have?
3. One test gives 100% statement coverage. Is branch coverage necessarily 100%?
4. Which review type is led by the author?
5. Optimistic 2, most likely 5, pessimistic 14 days: what is the three-point estimate?

Answers. (1) 0, 1, 2, 49, 50, 51. (2) Eight (2 × 2 × 2). (3) No; see question 20. (4) A walkthrough. (5) (2 + 20 + 14) / 6 = 6 days, with a spread of 2 days.

Practise it

Pick one form in the free ShopLite app, such as registration or checkout. Write the equivalence partitions and boundary values for each field, a decision table for the delivery and payment rules you can observe, and then run your tests to see which of them find planted bugs. The manual testing quiz is a quick self-check on the vocabulary.