BCS-O flashcards

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Testing definition

The process of evaluating a software product to detect differences between expected and actual behavior and to assess product quality, providing information to stakeholders for decision-making.

Exhaustive testing principle

Testing every possible input and precondition combination is infeasible except in trivial cases, so risk-based prioritization and coverage criteria must guide what is tested.

Pesticide paradox

Repeating the same tests stops finding new defects; test cases and data must be periodically reviewed and updated to remain effective at revealing failures.

Absence-of-errors fallacy

Finding and fixing many defects does not guarantee a usable system; a defect-free product that fails to meet user needs still fails.

Defect clustering

A small number of modules typically contain most defects; risk analysis and metrics direct test effort toward those high-density areas.

Verification versus validation

Verification confirms the product meets its specified requirements (built right); validation confirms it satisfies intended user needs in its actual context (right product).

Error, defect, failure

An error is a human mistake; a defect is a flaw in a work product caused by an error; a failure is observable incorrect behavior when the defect is executed.

Test analysis activity

Analyzing the test basis to identify testable features and define test conditions, without yet specifying detailed test cases or data.

Test design activity

Transforming test conditions into concrete test cases and test data using techniques such as equivalence partitioning, boundary value analysis, and decision tables.

Entry and exit criteria

Entry criteria state preconditions for starting a test activity; exit criteria state conditions for declaring it complete, such as coverage thresholds and defect-resolution rates.

Static testing

Examination of work products such as requirements and code without executing them, via reviews and static analysis, to find defects early and cheaply.

Component testing

Testing individual units in isolation, often by developers, using the code and detailed design as the test basis and stubs or drivers as needed.

Integration testing

Testing interfaces and interactions between components or systems to detect defects in data flow, communication, and combined behavior across boundaries.

System testing

End-to-end testing of a complete integrated system against specified requirements, typically by an independent test team in an environment resembling production.

Acceptance testing

Testing to establish confidence that the system meets business needs and is fit for release, including user acceptance, operational, contractual, and regulatory forms.

Regression testing

Re-executing selected tests after changes to confirm that modifications have not introduced new defects or broken previously working functionality.

Confirmation testing

Re-testing the specific defect that was reported, using the original steps plus variants, to verify the fix actually resolves the failure.

Functional testing

Testing what the system does: its functions, business rules, and behavior against requirements, independent of internal implementation structure.

Non-functional testing

Testing how well the system behaves: performance, load, security, usability, reliability, portability, and maintainability characteristics against quality criteria.

White-box testing

Structural testing that derives test cases from internal code or architecture, such as statement, branch, and path coverage, rather than from specifications alone.

Equivalence partitioning

Dividing input data into classes where all members are expected to be handled identically, then testing one representative value per class to reduce cases.

Boundary value analysis

Testing values at and just inside or outside the edges of equivalence classes, where defects concentrate, using minimum, minimum+1, maximum-1, and maximum.

Decision table testing

A technique that tabulates combinations of conditions and their expected actions, ensuring each business-rule combination is covered by at least one test case.

State transition testing

Modeling a system as states, events, and transitions, then designing tests to cover valid transitions, invalid transitions, and sequences that reach all states.

Use case testing

Deriving tests from actor-goal use cases, covering basic flows plus alternative and exception flows to exercise realistic end-to-end interactions.

Statement coverage

The percentage of executable statements exercised by a test suite; a weak criterion because it does not require decisions to take both outcomes.

Branch coverage

The percentage of decision outcomes (true and false) exercised; it subsumes statement coverage and is a common minimum structural criterion.

Experience-based techniques

Techniques relying on tester knowledge, such as error guessing, exploratory testing, and checklist-based testing, used to complement systematic specification-based methods.

Exploratory testing

Simultaneous learning, test design, and execution where the tester designs and adapts tests while exploring the product, guided by charters and session time-boxes.

Defect report content

A defect report records identifier, summary, environment, steps to reproduce, expected and actual results, severity, priority, status, and references to the test case.

Severity versus priority

Severity measures the impact of a defect on the system; priority measures how urgently it should be fixed, and the two can differ independently.

Risk-based testing

Allocating test effort in proportion to product and project risk, where risk is likelihood of a problem multiplied by its impact.

Test pyramid concept

A guideline favoring many fast low-level automated tests, fewer service-level tests, and few slow UI tests to balance feedback speed and confidence.