Software Testing without Requirements: Survival Guide

SOFTWARE TESTING without requirements without

NO TIME TO

EXPLAIN!

TEST!

The situation:

NO TIME TO

EXPLAIN!

TEST!

The situation: No

documentation

No testing process

No time to test

everything

HAVE

YOU BEEN IN THIS SITUATION?

No resources to create docs.

Legacy product support.

No knowledge to create docs.

You are limited to testing only obvious things.

Obvious things you can test.

Things you can only guess.

Techniques.

High risk / No time Low risk / more time

Exploratory testing Experience-based testing Error guessing

Own experience

Documentation

No documentation

High risk / No time Low risk / more time

Exploratory testing Experience-based testing Error guessing

Structure-based testing

Use-case based testing

Equivalence partitioning Boundary testing State-transition Decision tables

Specification

Use-cases

Code

Own experience

Documentation

No documentation

High risk / No time Low risk / more time

Documentation

No documentation

Exploratory testing Experience-based testing Error guessing

Use-case based testing

Equivalence partitioning Boundary testing State-transition Decision tables

Specification

Use-cases

Own experience

Structure-based testing Code

SO, WHAT’S

THE

PLAN?

The Plan.

Exploratory testing 1

Learn the product 2

Create documentation 3

Exploratory testing

Learn the product

Create documentation

Find the person responsible for the results of testing.

It can be:

Who is interested in testing?

The Project Manager?

The Customer?

This person will help you to understand

what is

TRUE

about

Test Scenarios

Pass/Fail

Expected Results

Start with risk-based testing.

Most critical and high-use features

Features you will release soon

Log test scenarios.

For regression testing.

To learn system behavior.

To confirm the tests.

Confirm the test results.

Until it is confirmed, this is only your assumption.

Running the same tests over and

over again would not show any new defects.

Watch out the Pesticide Paradox!

Notice defect

clusters.

80% of bugs are

caused by

20% of modules.

Exploratory testing

Learn the product

Create documentation

Learn: Users. Objects. Workflows. Product properties.

Emails

Notes

Recorded issues

Marketing materials

What can be used?

The product itself

Competitors’ products

Interviews with Stakeholders

The Interview: Focus on Results

1: What should you get?

Outputs

2: What will you use?

Inputs Process

3: How is it done?

Exploratory testing

Learn the product

Create documentation

Visualize system

requirements

To build a “map” of the workflows

To fit new tests in a whole picture

Use-case diagrams

Flowcharts

“Screenflow” charts

Tools:

Screenflow chart example

Document on a high level first.

Just enough for testing

Details will be added “as you go”

Use-cases

Checklists Tools:

Add more details while you test.

Connect high-level requirements and detailed test scenarios

Use both bottom-up and top-down

Exploratory testing

Learn the product

Create documentation

Risk-based testing.

Log the scenarios.

Confirm the results.

Users, Objects, Flows.

Use legacy docs.

Interview people.

Visualize.

Start with a high level.

Top-down/bottom-up.

Exploratory testing

Learn the product

Create documentation

Exploratory testing

Learn the product

Create documentation

Exploratory testing

Learn the product

Create documentation

Repeat the pattern to obtain more and more knowledge on

each step.

HINTS AND

HACKS

Always inform people about the risks.

You cannot test everything – test by priority.

Aware of some developers, saying “it’s not a bug – it’s a feature!”

Still the bug can be not the bug – discuss doubtful issues.

Always follow up discussion with a written notes.

KEEP CALM

AND

TEST, TEST AGAIN, THEN TEST SOME MORE

Found it useful? Tweet about it!

Oleksandr Lutsaievskyi, Agile Coach