ISTQB CTAL-TA flashcards
ISTQB CTAL-TA · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Product risk
- The risk that a product or component may fail to meet stakeholder needs. Its level is derived from likelihood of occurrence and potential impact, and it drives test prioritisation.
- Risk-based testing
- An approach in which test effort, test coverage and execution order are allocated in proportion to the level of product risk, so that the highest-risk areas receive the most thorough testing.
- Risk assessment
- The combination of risk identification, risk analysis (estimating likelihood and impact) and risk evaluation (deciding whether the risk is acceptable); performed early and repeated whenever new information appears.
- Risk mitigation through testing
- Activities that reduce risk; testing mitigates by providing information about quality. Higher risk levels demand more rigorous techniques, stronger coverage targets and greater test independence.
- Risk matrix
- A table that crosses likelihood categories with impact categories to produce a risk level such as very high, high, medium or low, used to rank requirements and test conditions.
- Risk tracking
- Ongoing monitoring that re-evaluates each risk after changes, new defects or new information, so the test analyst can reallocate effort and coverage during the project.
- Risk poker
- A consensus workshop technique in which participants independently estimate the likelihood and impact of identified risks and then discuss the differences to agree a shared rating.
- Test condition
- A testable aspect or attribute of a component or system identified from the test basis during test analysis, forming the input from which test cases are designed.
- Equivalence partitioning
- A black-box technique that divides input values or outputs into partitions expected to be processed identically; one test case per partition, with invalid partitions tested separately.
- Boundary value analysis
- A black-box technique testing values at the edges of ordered equivalence partitions; for a range a to b, two-value BVA uses a-1, a, b and b+1.
- Decision table testing
- A technique that models combinations of conditions and their resulting actions. With n binary conditions a full table has 2^n rules, each rule yielding at least one test case.
- State transition testing
- A technique modelling states, events and transitions of state-dependent behaviour; coverage criteria are all states, all valid transitions, and N-switch sequence coverage.
- Pairwise testing
- A combinatorial technique in which every combination of two parameter values appears in at least one test case, cutting combinations substantially while maintaining good defect detection.
- Use case testing
- A technique based on use cases where test cases cover the basic flow plus alternative and exception flows; coverage is the percentage of flows exercised.
- Functional suitability
- The ISO 25010 characteristic combining functional completeness, functional correctness and functional appropriateness, describing whether the system provides the required functions with the required accuracy.
- Usability subcharacteristics
- Learnability, operability, user error protection, user interface aesthetics and accessibility; the test analyst verifies these with checklists and user-centred scenarios.
- Interoperability testing
- A compatibility subcharacteristic verifying that the system exchanges and uses information correctly with other systems, checking data formats, interface protocols and error handling.
- Accessibility testing
- Testing whether people with disabilities can use the product, usually against standards such as WCAG, whose principles are perceivable, operable, understandable and robust.
- Portability testing
- Checking adaptability, installability and replaceability, that is, that the product works correctly across the specified hardware, software and organisational environments.
- Data conversion testing
- Verifying that data migrated from a legacy or source system retains the required completeness, correctness and integrity, using record counts, checksums and key field comparisons.
- Inspection
- The most formal review type: defined roles and entry and exit criteria, moderator-led individual preparation with checklists, documented findings and a formal follow-up of defect resolution.
- Technical review
- A formal review performed by technically qualified peers who examine a work product for technical correctness and adherence to standards; it may proceed without a fully defined process.
- Walkthrough
- A review in which the author leads reviewers through the work product, seeking feedback and establishing a shared understanding; it can also serve to train new team members.
- Review roles
- Manager, moderator, author, reviewers, review leader and scribe. The test analyst typically acts as a reviewer, judging testability, completeness and verifiability of the work product.
- Perspective-based reading
- A review technique where each reviewer examines the work product from a specific stakeholder viewpoint, such as tester, designer or user, guided by viewpoint-specific checklists.
- Entry criteria for reviews
- Conditions that must be met before a formal review starts, such as the document being complete and available; failure to meet them normally leads to postponement.
- Severity versus priority
- Severity is the impact of a defect on the system and is assigned by testers; priority is the urgency of correction, agreed with business stakeholders, and the two are independent.
- Defect report content
- At minimum: unique identifier, title, author and date, environment, steps to reproduce, expected and actual results, severity, priority, status and references to the test basis.
- Defect removal efficiency
- The percentage of defects found before release out of all defects found before and after release; a measure of how effective testing was at removing defects.
- Defect density
- The number of defects identified in a work product divided by a size measure such as function points, lines of code or test cases; used to compare modules and estimate remaining defects.
- Requirements traceability matrix
- A table linking test basis items to test conditions, test cases and results; it supports coverage measurement and impact analysis when requirements change.
- Defect triage meeting
- A regular meeting where testers, developers and business stakeholders review reported defects to agree status, severity, priority and whether each is fixed, deferred or rejected.