Software Testing

1. TESTING

2. TEST PYRAMID
More unit tests, less high level end-to-end tests running through a GUI
Layers:
UI
Service
Unit

3. SOFTWARE TESTING ICE CREAM CONE
Reverse of Testing Pyramid
Manual Testing
UI
Service
Unit

4. TESTING ICE CREAM CONE DISADVANTAGES
- Slow - usually not headless
- Brittle - simple changes could easily break UI tests
- Developers have less ownership of quality

5. TEST SOURCES
- Business Tests
- QA Tests
- Developer Tests

6. BUSINESS TESTS
- Behavior-Driven Development is relevant
- acceptance criteria describe what the application is supposed to do, and how
it does so, in high-level business terms
- acceptance criteria become high-level executable specifications
- living documentation
- speed up the feedback cycle and reduce risk

7. QA TESTS
- help discover and clarify the acceptance criteria
- identify other scenarios beyond the acceptance criteria
- ensure business rules are respected
- ensure support for required number of users or transactions
- demonstrate that application is fit for purpose

8. DEVELOPER TESTS
- Test-Driven Development related
- build confidence in the code base
- illustrate how components are intended to work, making it easier to
understand
- safer to make changes without introducing new bugs

9. TEST ROLES
- Tests that Discover
- Tests that Describe
- Tests that Demonstrate

10. DISCOVER
- Story Mapping
- Impact Mapping
- Example Mapping

11. DESCRIBE
- explain business rules or features, in high-level terms
- Illustrate how the system works
- BDD
- executable specifications
- Example Tools: Cucumber, SpecFlow, Spock

12. DEMONSTRATE
- demonstrate that the feature works in more detail
- check boundary conditions, edge cases or error handling

13. AUTOMATED TESTING QUADRANT

14. ROLES AND NATURE
- Quadrant 1 - high level business outcomes
- Quadrant 2 - still business-focused but more detailed and comprehensive
- Quadrant 3 - written by and for developers, for easier & cheaper maintenance
- Quadrant 4 - technical equivalent of Quadrant 2 tests

15. JUST ENOUGH AUTOMATED TESTS
TOO FEW
- reduce confidence
- more manual testing
- slower deployment cycles
TOO MANY
- take a lot of time to write
- increase maintenance costs

16. BE PRAGMATIC
- Write the simplest and fastest test that you can get away with
- Illustrate the point you are trying to demonstrate
- Make it easy to identify the cause of the problem

17. WELL BALANCED TEST PORTFOLIO
- Don’t use a web test where a service or unit test could do the same job
- Just the right amount of tests at the right levels to have confidence

18. REFERENCES
Test Pyramid Heresy - https://dzone.com/articles/a-test-pyramid-heresy
Test Pyramid - https://martinfowler.com/bliki/TestPyramid.html
Google Testing Blog - https://testing.googleblog.com/2015/04/just-say-no-to-
more-end-to-end-tests.html