This document discusses different software testing approaches: - Manual testing is not suitable for long projects as it requires retesting the entire system with each iteration. It may be suitable for short prototyping projects. - Unit tests create a "skeleton" that helps ensure the software works as expected but do not cover all potential states. - Testing modules is easier than testing the entire application as a module has fewer possible states to test. - Finding and fixing bugs takes longer if testing is done after development rather than during development. Unit testing and test-driven development reduce the time needed to find and fix issues.

1. Explanation of software
testing approaches
Vadim Nareyko
Inspired by James W Greening

2. 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).

3. Manual Testing doesn’t work for long projects
If 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.

4. Unit tests as a skeleton
Unit 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.

5. Test modules
If 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

6. Testing after development phase increases costs
If 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.

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

8. 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)

9. BDD is TDD for Business
The same approach - start from
acceptance tests that support your
business value.
(BDD = Behaviour-Driven
Development)

10. Good Luck!