Software Testing & QA MCQ

Explanation

Testing aims to find defects and build confidence that the software works correctly, not to guarantee a complete absence of bugs.

Explanation

A test case describes the steps, inputs, and expected outcomes needed to check whether a specific functionality works correctly.

Explanation

Verification asks "are we building it right?" (conformance to specs), while validation asks "are we building the right thing?" (meets actual needs).

Explanation

Unit tests verify the smallest testable parts of code (functions, methods, classes) independently, usually with dependencies mocked or stubbed out.

Explanation

Integration tests check that combined modules interact correctly, catching issues that arise only when components work together.

Explanation

System testing evaluates the fully integrated application as a whole against the overall functional and non-functional requirements.

Explanation

Acceptance testing (often UAT — User Acceptance Testing) confirms the software meets business requirements and is acceptable for release.

Explanation

Regression testing guards against new changes unintentionally breaking previously functioning features.

Explanation

Smoke testing ("build verification testing") quickly confirms the core functionality works before investing time in deeper testing.

Explanation

Black-box testing focuses on inputs and outputs, evaluating behavior against requirements without examining the internal implementation.

Explanation

White-box testing (also called clear-box or structural testing) requires knowledge of the code's internals, such as branches and paths, to design test cases.

Explanation

Manual testing relies on a person performing test steps and observing results, useful for exploratory or usability-focused testing.

Explanation

Automated testing uses code or tools to run tests repeatedly and consistently, ideal for regression suites and frequent execution.

Explanation

A test plan defines what will be tested, how, by whom, with what resources, and on what timeline.

Explanation

A defect is a deviation between the expected and actual behavior of the software, often caused by a coding mistake.

Explanation

Test data is the input fed into a test case; well-chosen test data exercises both normal and edge-case scenarios.

Explanation

Coverage metrics (e.g. line, branch, or requirement coverage) indicate how much of the code or requirements are exercised by tests.

Explanation

Exploratory testing relies on tester creativity and experience to discover defects without predefined scripts, often complementing scripted testing.

Explanation

A test environment mirrors (to varying degrees) the production setup so tests run under realistic conditions.

Explanation

Common stages include New, Assigned, Open, Fixed, Retest, Verified, and Closed (or Reopened if the fix fails).

Explanation

A defect can be high severity (crashes the app) but low priority (rarely occurs), or low severity (a typo) but high priority (visible on the homepage).

Explanation

UAT is the final validation step where actual users verify the software supports their real-world tasks and requirements.

Explanation

Tools like TestRail or Zephyr help teams plan, organize, execute, and report on testing activities.

Explanation

Boundary value analysis tests the minimum, maximum, and just-inside/outside values of a range, since off-by-one errors commonly occur there.

Explanation

Equivalence partitioning reduces the number of test cases needed by grouping inputs that should produce similar results and testing one from each group.

Explanation

Static testing finds issues early through reviews, walkthroughs, and static analysis, without running the code.

Explanation

Dynamic testing runs the actual software to verify its behavior, as opposed to static testing which reviews artifacts without execution.

Explanation

Checklists are lightweight aids that help testers remember important checks, especially for repetitive or common scenarios.

Explanation

Usability testing evaluates the user experience, looking at ease of use, learnability, and user satisfaction.

Explanation

Compatibility testing ensures consistent behavior across various platforms, browsers, screen sizes, and configurations.

Explanation

Performance testing measures responsiveness, throughput, and stability under expected or peak loads.

Explanation

Load testing validates performance at expected/normal loads, while stress testing intentionally overloads the system to observe failure behavior and recovery.

Explanation

Test scripts encode the steps and assertions of a test case so it can be run automatically by a testing tool or framework.

Explanation

The test pyramid encourages a larger base of fast, cheap unit tests, with progressively fewer slower, more expensive integration and UI/end-to-end tests.

Explanation

Ad-hoc testing is unstructured and relies on tester intuition to find defects that scripted tests might miss.

Explanation

Alpha testing occurs internally, typically before beta testing, to catch major issues before the product reaches outside users.

Explanation

Beta testing gathers feedback from real users in real-world conditions, helping uncover issues not found in internal testing.

Explanation

Without a clearly defined expected result, it is impossible to objectively judge whether a test passed or failed.

Explanation

Quality Assurance refers to the processes and activities aimed at ensuring the quality of software throughout development, not just testing at the end.

Explanation

QA focuses on preventing defects by improving development processes, while QC focuses on detecting defects in deliverables, often through testing.

Explanation

TDD follows a cycle of writing a failing test (red), writing minimal code to pass it (green), then improving the code (refactor).

Explanation

BDD extends TDD by framing tests as readable behavior specifications (often with tools like Cucumber), bridging communication between business and technical teams.

Explanation

Mocks simulate the behavior of real objects (e.g. an API client) and let tests verify that certain interactions occurred, isolating the unit under test.

Explanation

Stubs return canned answers without caring how they are called; mocks go further by asserting that expected calls were made with expected arguments.

Explanation

Code can be "covered" by a test that executes it without verifying the result is correct, so coverage is a useful but incomplete quality signal.

Explanation

CI pipelines automatically build and test code on each change, providing fast feedback and catching integration problems before they accumulate.

Explanation

Shift-left testing emphasizes early involvement of testing (e.g. during requirements and design), since defects are cheaper to fix earlier.

Explanation

The two approaches complement each other: scripted tests provide repeatable baseline coverage, while exploratory testing uncovers issues scripts may miss.

Explanation

Fixtures (e.g. setup/teardown methods, seeded data) provide a consistent starting point so tests are repeatable and independent of execution order.

Explanation

Tests that depend on shared state or order can produce flaky results and make it hard to isolate the actual cause of a failure.

Explanation

Flaky tests undermine trust in the test suite because failures don't reliably indicate real problems, often caused by race conditions, shared state, or external dependencies.

Explanation

API testing verifies requests and responses (status codes, payloads, headers) at the interface level, often faster and more stable than UI tests.

Explanation

E2E tests validate that all integrated parts of a system (UI, backend, database, etc.) work together correctly for realistic user journeys.

Explanation

Session-based testing structures otherwise unstructured exploratory testing into trackable, time-boxed chunks with clear goals and reportable outcomes.

Explanation

Risk-based testing focuses limited testing resources on the highest-risk areas, balancing impact and probability of defects.

Explanation

Non-functional testing addresses "how well" the system performs (speed, scalability, security) rather than "what" it does.

Explanation

Security testing identifies weaknesses such as injection flaws, broken authentication, or data exposure before attackers can exploit them.

Explanation

Pairwise testing dramatically reduces test combinations compared to exhaustive testing while still covering interactions between pairs of parameters, where many defects occur.

Explanation

An oracle could be a specification, a previous version of the system, a formula, or domain expertise — anything that tells you what the "correct" output should be.

Explanation

Automation can support exploratory testing by handling repetitive setup tasks, freeing testers to focus on investigation and analysis.

Explanation

Smoke tests act as a fast gate — if they fail, the build is rejected immediately, saving time that would be spent on more thorough testing of a broken build.

Explanation

Data-driven testing externalizes test inputs and expected outputs (e.g. in a spreadsheet or file), enabling broad coverage with minimal script duplication.

Explanation

Keyword-driven testing abstracts test steps into reusable keywords, separating test design from implementation details, often used to involve non-technical testers.

Explanation

Contract tests (e.g. using Pact) validate that a consumer's expectations match a provider's actual API, catching integration issues early without full end-to-end environments.

Explanation

If a mutant survives (tests still pass despite the code change), it suggests the test suite has a gap in detecting that kind of fault, unlike code coverage which only shows whether code ran.

Explanation

Defect density helps identify which modules are riskier or lower quality, guiding where to focus additional testing or refactoring.

Explanation

Differences between test and production environments (configuration, data volume, infrastructure) can hide bugs that only appear in production, so closer parity reduces "it worked in testing" surprises.

Explanation

Smoke suites are intentionally small and fast, covering critical paths so a broken build is detected quickly before running the full test suite.

Explanation

Parallel execution shortens feedback loops, especially valuable for large test suites in CI pipelines, but requires tests to be independent of each other.

Explanation

Functional tests check correctness of behaviors against requirements, while non-functional tests assess qualities like speed, scalability, and security.

Explanation

A charter provides direction (e.g. "explore the checkout flow for edge cases with discounts") while leaving room for the tester to investigate freely within that scope.

Explanation

As regression suites grow, selecting or prioritizing the most relevant tests (e.g. based on changed files) helps balance speed with risk coverage.

Explanation

While scripted tests are documented in detail before execution, exploratory testing is often documented afterward via notes, bug reports, or session logs.

Explanation

Snapshot tests flag any difference from the stored snapshot, prompting a review to confirm whether the change is intentional or a regression.

Explanation

Accessibility testing checks compliance with standards (e.g. WCAG) and usability for users relying on screen readers, keyboard navigation, and similar tools.

Explanation

Automation investment makes sense for stable, frequently-run tests (e.g. regression), while exploratory or rapidly-changing areas may not yet justify automation cost.

Explanation

A traceability matrix helps verify completeness of test coverage relative to requirements and supports impact analysis when requirements change.

Explanation

Quality gates automatically block builds that don't meet defined standards, helping enforce consistent quality without manual gatekeeping.

Explanation

Cross-browser testing catches rendering and behavioral differences caused by varying browser engines, versions, and feature support.

Explanation

Sanity testing is a quick, targeted check (often after a minor fix) to confirm a specific area works, whereas smoke testing is a broader check of core functionality across the whole build.

Explanation

E2E tests exercise the full stack and are sensitive to environment issues, making them slower and flakier; the pyramid favors many fast unit tests with fewer, targeted E2E tests for critical flows.

Explanation

Techniques like transactional rollbacks, dedicated test schemas, or containerized databases help integration tests avoid leaking state between runs.

Explanation

Mutation testing's "mutation score" (killed mutants / total mutants) is a stronger signal of test effectiveness than line coverage, but the combinatorial cost of running the suite against many mutants can be significant for large codebases.

Explanation

Realistic, compliant (e.g. anonymized) test data that covers edge cases while respecting privacy laws like GDPR is a significant ongoing engineering challenge in many organizations.

Explanation

Techniques like canary releases combine gradual rollout with close monitoring, catching issues real users encounter that synthetic test environments might miss, while limiting blast radius.

Explanation

To counter the pesticide paradox, test cases need to be regularly reviewed, revised, and supplemented with new tests to find different categories of defects.

Explanation

Tests that assert trivial things (e.g. "function exists") can pass while providing little confidence; reviewing test intent and using techniques like mutation testing helps surface such gaps.

Explanation

Experienced testers often "sense" risky areas based on patterns they've seen before; this intuition is valuable but resists being fully captured as deterministic rules in automated tests.

Explanation

Chaos engineering (e.g. Netflix's Chaos Monkey) proactively tests system resilience against infrastructure failures, an area traditional functional testing often does not cover.

Explanation

Tests against eventually consistent systems must account for propagation delay, often using polling with timeouts or test-specific synchronization hooks to avoid flaky failures.

Explanation

Tools like QuickCheck or Hypothesis generate many random inputs and check that defined invariants (properties) hold, often finding edge cases (e.g. empty lists, extreme values) missed by hand-written examples.

Explanation

Tests tightly coupled to internal structure (e.g. asserting exact private method calls) break whenever the implementation changes, even if the externally observable behavior is unchanged — a maintenance burden without proportional value.

Explanation

While easy to start with, record-and-playback scripts often hardcode UI selectors and timing assumptions, making them costly to maintain as the UI evolves — hence their recommended limited role at the top of the pyramid.

Explanation

Recognizing test smells (like overly complex setup, duplicated logic, or testing multiple concerns in one test) helps teams refactor both tests and the production code they exercise for better design.

Explanation

A system can be tuned to process many requests efficiently in aggregate (high throughput) at the cost of each individual request taking longer (higher latency), e.g. via request batching or queuing.

Explanation

While negative tests check how code handles bad inputs, fault injection examines how the broader system reacts to environmental failures like timeouts, crashes, or corrupted data, often revealing gaps in error handling and recovery.

Explanation

Consumer-driven contracts (e.g. Pact) let consumer teams define expectations that provider teams verify against, decoupling test execution from needing all services running simultaneously.

Explanation

In distributed systems, network failures can cause clients to retry requests; idempotency testing ensures repeated identical requests (e.g. using an idempotency key) don't cause duplicate effects.

Explanation

By systematically exploring states and transitions defined in a model, model-based testing can generate comprehensive test suites and adapt them automatically when the model changes.

Explanation

Shifting testing responsibility to developers speeds delivery and improves quality awareness, but organizations often still benefit from QA specialists who coach, build tooling, and handle complex cross-cutting testing concerns.