Few slides show how it looks before and after implementation “Collaborative Test Pyramid”

1. Approach
TEST AUTOMATION

2. BEFORE TEST PYRAMID
 Delays due to WIP in testing or WIP in development
 Testers and developers are separated in their responsibilities
 Testers and developers can’t help each other

3. TEST AUTOMATION PROCESS

4. TEST AUTOMATION PROCESS

5. AFTER TEST PYRAMID
 All test are whole team responsibility, but there must be owner.
UNIT
INTEGRATION
UI
PERFORMANCE

6. WRITING UNIT TESTS
 Owned by developers
 Highest priority
 Designed for each User Story
 Covers most cases, using boundary value analysis and equivalence
partitioning
 Backend (e.g. code) and Frontend (e.g. java scripts)
 Working on code level

7. WRITING INTEGRATION TESTS
 Owned by developers or quality engineers
 When not possible to cover as unit test
 Designed for each User Story
 Focused on verify if components work together
 Test should be able to run on different environments
 Works on common minimum set of data and test specific data

8. WRITING UI TESTS
 Owned by quality engineers
 When not possible to cover as unit or integration tests
 Long business scenarios based on User Journeys
 Should cover multiple User Stories
 Test should be able to run on different environments
 Works on minimum set of data and Test Specific Data
 Use CRUD scenarios