ISTQB Practice

Failure

occurs when software does not meet the user’s needs or expectations. can result from bugs, errors, defects, or faults.

Fault

a defect or an error in the software that, when executed, causes a failure.

Bug

The actual result does not align with the expected result

Reason for Errors

time pressure, human fallibility, inexperienced staff, miscommunication, complexity, complex interfaces, new technologies.

Dynamic Testing

Shows failures caused by defects. Aims to find and fix as many defects as possible before the software release

Validation

Checks whether the system will meet user and other stakeholder needs in its operational environments (doing the right thing)

Verification

Checks whether the system meets specified requirements (doing the thing right)

Static Testing

Does not involve executing the component or system being tested, but includes reviews and static analysis. Takes place early in the SDLC.

Evaluating work products (requirements, user stories, designs, and code)

useful for finding problems early on in the development process before wasting time and money.

Trigger Failures and finding defects

running test cases testers hope to accidentally break the system and reveal bugs so that defects in the software are identified.

Ensure required coverage of a test object

goal is to make sure no untested areas could cause problems in the production environment such as critical functionalities or code paths

Reducing the risk of inadequate software quality

finding bugs early in development and ensuring software meets expectations.

Verifying whether specified requirements have been fulfilled

testers can verify if the software accomplishes its goal by comparing its actual behavior to the expected behavior specified in the requirements

Providing information to stakeholders

allows to make better decisions about release readiness, project timelines, resource allocation, and risk management when they have access to reports on the quality and status of the software

Building confidence in the quality of the test object

users and stakeholders are more likely to have faith in the reliability of the software when it has undergone thorough testing and had been shown to behave consistently

Validating the test object

testing endured the system performs as expected and satisfies the needs of its users

Testing shows the presence of defects, not their absence

Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, testing is not a proof of correctness.

Exhaustive testing is impossible

Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Rather than attempting to test exhaustively, risk analysis, test techniques, and priorities should be used to focus test efforts.

Early testing saves time and money

Testing early in the software development lifecycle helps reduce or eliminate costly changes. Sometimes referred to as shift left

Defects cluster together

A small number of modules usually contains most of the defects discovered during pre-release testing or is responsible for most of the operational failures.

Beware of the pesticide paradox

If the same tests are repeated over and over again, eventually these tests no longer find any new defects. To detect new defects, existing tests and test data may need changing, and new tests may need to be written.

Testing is context-dependent

example: safety-critical industrial control software is tested differently from an e-commerce mobile app. As another example, testing in an Agile project is done differently than testing in a sequential software development lifecycle project

Absence-of-errors is a fallacy

thoroughly testing all specified requirements and fixing all defects found could still produce a system that is difficult to use, that does not fulfill the users’ needs and expectations, or that is inferior compared to other competing systems.

Debugging

finds, analyzes, and removes the causes of failures in the software

Reviews, Static Analysis, and Dynamic Testing all have the same objective of

Identifying defects

Flow of the phases of a Formal Review

Planning, Review Initiation, Individual review, Communication & Analysis, Fixing & Reporting.

A Walkthrough is led by the

Author

An Inspection is led by the

Trained Moderator

Scribe

A Person who documents all the issues, problems and open points that were identified during a formal review.

Static Testing prevents defects in design and coding by

uncovering omissions, inaccuracies, inconsistencies, ambiguities, and redundancies in requirements.

Early and Frequent Stakeholder helps in identifying and correcting

misunderstandings about requirements before significant work has been done which prevents costly rework and ensures the final product meets stakeholder’s needs.

Typically examined using static testing techniques like reviews or static analysis.

Source code documentation, such as comments, design specifications, and coding standards

Traceability

ability to track business requirements across the development lifecycle, including testing.