Checklist for Testing

An approach to capturing issues

Tricode Professional Services

www.tricode.nl

Date: 09-10-2009

Author: Chris van Zeventer

Contents

• Intro

• Basics

• The importance of defining requirements

• Dimensions in testing

Intro

What this is about• Awareness• Accessible• Website related

What it’s not about• Revolutionary

concepts• Standards• Complex theories• Automated testing

Basics

• Expected behaviour (specification)

• Determine strategy in testing

• Determine current behaviour (testing)

• Process test results

The importance of defining requirements

• Expectation vs implementation(1): spotting a problem (FD & TD)

• Expectation vs implementation(2): Example

• The price of failure

Expectation vs impelementation(1): spotting a problem (FD & TD)

• Misunderstandings can lead to delays• Spot (and prevent) problems as early as

possible or else..

0

20

40

60

80

100

Start FD TD Dev Test Imp

Time planned

Time spent

Time left

Development time higher than expected due to misunderstanding about functional reqs.

Time needs to be gained somewhere to meet the implementation deadline.

At this point only test phase remains adjustable (and thus will suffer)

Failing to pick up issues earlier on will lead to headaches after implementation.

At this point the

planning was still adjustable

Expectation vs impelementation(2): Example

Assignment:

Describe a tricycle

The price of failure

Dimensions in testing

• Why dimensions in testing?• Scope / coverage area• Superficial / environmental• Object interaction• Functional behavior• Operational• Implicit testing

Note: An item may cover multiple dimensions

Why dimensions in testing?

Scope / coverage area

• Narrow area• Immediate area• Broad area

A

B

C D

E

Scope / coverage area

• Narrow area• Immediate area• Broad area

A

B

C D

E

Scope / coverage area

• Narrow area• Immediate area• Broad area

A

B

C D

E

Scope / coverage area

• Narrow area• Immediate area• Broad area

A

B

C D

E

Superficial / environmental

• Text contents– Spelling– Text that doesn’t make sense

• Styling– Green text on green background– Overlapping pieces content

• Cross browser compatibility

• Cross resolution compatibility

Object interaction

• Input validation – Postalcodes– Phone numbers– Date format

• Character encoding• Impact of client

settings– JavaScript– Flash

Functional behavior

• Behavior should be consistent with functional design

• Object behavior looks at a single object. functional behavior looks at the bigger picture.

Operational

• Performance– Load times

• Stress testing• What is considered ‘slow’?

– Memory & disk space– Will it break if interrupted (corruption of data)?

Implicit testing

• Gather information about other properties of the system for which you didn't design specific test cases (while testing you notice that the performance is poor, the user interface is bad, ect..)

Conclusions

• Try to capture all requirements early on (preferably long before testing)

• There is more than one way/perspective to look at a test object

• Don’t underestimate regression

• If you didn’t define something as test object it doesn’t mean you can’t test it