The document discusses test automation before and after implementing the test pyramid approach. It recommends that all tests become a team responsibility with an owner. It describes the different types of tests in the pyramid from unit to integration to UI tests. Unit tests should be written by developers to cover code and are highest priority. Integration tests verify component interactions and can be written by developers or quality engineers. UI tests cover long scenarios and business flows and are written by quality engineers.

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