<< Testing in the Software Development Life Cycle | Regression vs. Retesting >>

Concepts of Teesting

<< Testing in the Software Development Life Cycle | Regression vs. Retesting >>

C o n c e p t s o f T e s t i n g

The Testing Mindset

There is particular philosophy that accompanies "good testing".

A professional tester approaches a product with the attitude that the product is already broken - it
has defects and it is their job to discover them. They assume the product or system is inherently
flawed and it is their job to `illuminate' the flaws.

This approach is necessary in testing.

Designers and developers approach software with an optimism based on the assumption that the
changes they make are the correct solution to a particular problem. But they are just that
assumptions.

Without being proved they are no more correct than guesses. Developers often overlook
fundamental ambiguities in requirements in order to complete the project; or they fail to recognise
them when they see them. Those ambiguities are then built into the code and represent a defect
when compared to the end-user's needs.

By taking a sceptical approach, the tester offers a balance.

The tester takes nothing at face value. The tester always asks the question "why?" They seek to
drive out certainty where there is none. They seek to illuminate the darker part of the projects
with the light of inquiry.

Sometimes this attitude can bring conflict with developers and designers. But developers and
designers can be testers too! If they can adopt this mindset for a certain portion of the project,
they can offer that critical appraisal that is so vital to a balanced project. Recognising the need for
this mindset is the first step towards a successful test approach.

Test Early, Test Often

There is an oft-quoted truism of software engineering that states - "a bug found at design time
costs ten times less to fix than one in coding and a hundred times less than one found after
launch". Barry Boehm, the originator of this idea, actually quotes ratios of 1:6:10:1000 for the costs
of fixing bugs in requirements,design, coding and implementation phases.

If you want to find bugs, start as early as is possible.

That means unit testing (qqv) for developers, integration testing during assembly and system
testing - in that order of priority! This is a well understood tenant of software development that is
simply ignored by the majority of software development efforts.

Nor is a single pass of testing enough.

Your first past at testing simply identifies where the defects are. At the very least, a second pass of
(post-fix) testing is required to verify that defects have been resolved. The more passes of testing
you conduct the more confident you become and the more you should see your project converge
on its delivery date. As a rule of thumb, anything less than three passes of testing in any phase is
inadequate.