- Test early. The later you wait, the more expensive it gets. The initial testing start at the initial meeting of the companys founders, keep on having small tests as early as possible.
- Testing show precense of defects, not absence.
- Exhausive testing is not possible within reasonable economical terms.
- Defects lump together. Find a defect: Look around it as well.
- Pesticide paradox: Bugs become imune against repeated tests.
- Testing is context dependant.
- Absence-of-errors-fallacy. No errors found during testing, proves only that none of the errors were found during testing.
Posts Tagged ‘definitions’
7 most important principles of software testing
04.08
Exercise from the book “Software testing foundations”
01.25
Here are Ketils personal notes from a walkthrough of the book “software testing foundations”, combined with notes on agile testing and parts from the wikipedia. Look if you wish, it’s as imperfect and unusable as such notes always should be.
2.1 Define the terms failure, fault and error
Failure := Desribes the event when a user experiencne a problem, a non-fulfillment of a given requirenment. Examples of failures are products that .
Fault := the cause of a failure
Error := A failure to complete a task, usually involving a premature termination (http://en.wiktionary.org/wiki/error)
2.2 What is defect masking
Basic strategies for integration testing
01.24
Here are a small listing of the basic integration strategies a test manager can use when he’s designing a test strategy:
Top-down integration:
The test starts with the top level component of the system that calls the components but is not called itself (the top component).
Stubs must substitute all non-finished lower-level components, integration proseede with the lower-leel components as soon as they are produced.
Advantage: Test drivers are not needed, the highere-level components are the test-drivers.
Disadvantage: This is a very costly method, because of the amount of stubs to be produced.
Test tools
01.23
Tools are available for every phase of the test process, helping the tester to automate test activities or improve the quality of the activities.
Use of a test tool is only benefical wen the test process is defined and controlled.
The introduction of a test tool must bee supported by information, training, coaching. You dont have any use of a plier if you dont know how it is used..
Different testing methods
01.23
- Model-based testing
Testing the models describing the test object: Use cases, work-flows and so on - Statistical or stochastic testing
Allocate the test effort by using statistical models about fault distribution in the test object, failure rates during use of the software (realiability growth models and others), and statistical distribution of use cases - Risk-based testing
Test the items with highest risk / consequence first, and then keep on down almost until the consequence of failed test meets the economical consequences of testing - Process- or standard-compliant approach
Use rules, recommendations and standards (as the V-model or IEEE 829) - Reuse-oriented approach
Set up testing quickly for maximum reuse and minimal cost - Checklist-based approach
Use the old failure- and detection lists from earlier tests - Expert-oriented approach
Use the gut-feeling and expertise of involved experts
Definitions regarding test strategies
01.23
Preventative versus Reactive
A preventative approach is when the testers are involved from the beginning. Test planning and test design will start as early as possible. The test manager can really optimize and reduce testing costs.
A reactive approach is when the testers are involved late, and a preventative approach cannot be chosen.
One very successful strategy, when the reactive approach is chosen, is called exploratory testing. This is a heuristic approach in which the tester explores the test object and design, with concurrent execution and evaluation.
Analytical versus Heuristic
Analytical: Test planning is founded on data and mathematical analysis of these data.
Heuristic: Test planning is founded on experience of experts, and rules of thumb.
White box testing
01.23
This picture define what white-box-testing is about:
Testing of all individual bits and pieces, both alone and put together
Test techniques, part II
01.23
Issues about static testing
01.10
Several pairs of eyes see more than a single pair, this is true in manysettings – and an (almost) absolute truth in software development. It is the main principle for the reviews performed for checking and improving quality.
The lifecycle of testing software
01.10
Some definitions, testing in the software lifecycle
The general V-model defines basic test leverls: Component test, integration test, system test and acceptance test. It distinguishes between verification and validation. Here are some definitions.





