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
- 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