Explanation of software testing approaches

Vadim NareykoInspired by James W Greening

I’ve participated in Agile Estonia Saturday where I had possibility to meet James W Grenning (one of the original authors of the Agile Manifesto, inventor of

Planning Poker and author of book “Test-Driven Development for Embedded C”).

There are some interesting explanations of testing approaches value (both from his lecture and my insights).

Manual Testing doesn’t work for long projectsIf you use Manual Testing, you have to retest everything for each iteration (version), including whole previous functionality.

Manual testing may be ok for a short-term project where you don’t need future support (prototyping).

In other case it’s time and budget wasting activity.

Unit tests as a skeletonUnit tests don’t cover all potential states of your software.

They create a skeleton that helps you be sure you software works the same way as before.

Test modulesIf you test the whole application - an amount of states is really big

Example: 10*20*30 = 6000

If you test modules - it’s much easier

Example: 10+20+30 = 60

Testing after development phase increases costsIf you spend more time on a discovery of mistake (Td) then you spend more time on finding the cause (Tfind) and fixing (Tfix).

Basically, you don’t remember the cause since it was a long time ago.

Unit testing improves fixing timeIf you start developing unit test just after coding it decreases time of finding the root cause (Tfind) and fixing time (Tfix)

TDD saves fixing time (much better that unit testing)If tests were written before coding, developer finds mistake just after finishing task and fixing time is really small.

(TDD = Test-Driven Development)

BDD is TDD for BusinessThe same approach - start from acceptance tests that support your business value.

(BDD = Behaviour-Driven Development)

Good Luck!