There is no business value in partially ‘done’ products. Regression and E2E need to be checked.
‘Done’ includes regression testing
Agile development has a high focus on delivering business value to customers. For this purpose, every sprint delivers new functions that expand the functionality of the existing product. While customers might like the newly added functions, they will not like if existing functions from previous releases stop working. There is an unwritten rule that the customer expects that while new functions are added, the existing functions keep working as is. The only way to ensure this is by running a regression test on the existing functions. This means that agile teams must reserve team capacity for developing and maintaining a test set. Only then, testing is ‘done’.
‘Done’ includes E2E testing
Agile testing has an increased focus on (automated) low level testing. Although this is perfectly justifiable, end users will operate the system in all kind of E2E scenarios. Working units in low level testing do not guarantee working E2E processes. This means that E2E tests must be put on top of the unit tests. E2E testing has its own dynamics. It requires E2E process knowledge to define good tests. This knowledge could go beyond the domain knowledge of the agile team. In that case special measures must be taken to acquire this knowledge or outsource parts of the tests to other agile teams.
Coordination of team activities
E2E testing in big systems is complex and is difficult to setup. It requires broad system knowledge that often spans multiple physical products. When agile teams have a product orientation, it is likely that E2E processes span multiple teams. In such situations, team activities must be coordinated upfront and throughout the sprints to ensure that at the end of the sprint E2E testing is completed. When lead times of E2E testing are longer then the sprint period, special measures must be taken to ensure that E2E testing gets the proper attention as completion is not guaranteed by the scrum mechanism.
The levels for Regression & E2E testing are typified as follows:
Please find the checkpoints below.
| Forming | |||||||||||
| 1. There is a basic strategy for regression testing 2. There is a basic strategy for E2E testing 3. E2E and regression test sets are maintained and updated 4. Responsibilities for E2E and regression testing are clear |
|||||||||||
| Norming | |||||||||||
| 1. Regression testing is part of every iteration 2. Regression and E2E testing is applied over multiple iterations and when needed over multiple teams and multiple projects 3. The user stories contain information on relevant E2E functionality |
|||||||||||
| Performing | |||||||||||
| 1. The team is aware of the value of and need for E2E and regression testing 2. All testing is used to address current business value 3. Regression test sets can be easily scoped to address specific areas of functionality 4. E2E test possibilities are utilized continuously |
|||||||||||
Terug naar Context Driven Testverbetering | Terug naar TI4Agile
