Explanation of software testing approaches
2 likes308 views
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.
Explanation of software testing approaches
- 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!