Bloggo back to the blog
G(r)ood testing 23: End-to-End integration in Scaled Agile projects-->
Working with multiple development teams within a single project introduces integration problems. This is independent of how the teams are organized. If you work with feature teams, the teams work simultaneously in the same codebase. Is the organization working with component teams that have their own system to maintain, it soon becomes apparent that business processes run through the various systems. End-to-End (e2e) tests are needed to determine whether or not the integrated systems work as a whole and the business processes are truly supported. How do you organize the e2e testing with and among the various Scrum teams?
E2e test challenges
Ideally, when all the integrations carried out in the sprint, there emerges continuous integration. In practice many organizations don’t find it feasible. The e2e tests are often manually executed and too complex to organize. The teams often skip the e2e test because it is just too hard and takes too much time. Therefore, many organizations chose to let a separate team set-up and execute the e2e tests. Scrum Teams deliver to integration team. This has two disadvantages: integration problems are discovered late in the cycle and integration does not really become a development team responsibility.
Solution 1: Let the teams test the e2e integration
Our first solution to tackle this is: Make the teams responsible for e2e integration. Teams must then collaborate and make team exceeding arrangements in order to complete backlog items with a team-transcending impact. A Scrum-of-Scrum meeting can be used to make work agreements on the actual content and organization of the integration tests. Road Mapping and story mapping enable prioritization and ordering of the items based upon their business value and dependencies. For example, team-transcending integrations can be implemented as early as possible in order to mitigate risks. In a project that we did, we took this so far that using the statement: “it ain’t has value unless its successfully integrated”, we used completed and tested integrations as our primary progress indicator.
Knowledge about e2e testing is a prerequisite
A prerequisite for the above scenario is that knowledge about e2e testing is available within the teams. Regularly our options are limited here, because many Scrum teams are traditionally development teams. They have good knowledge of unit testing, but lack sufficient experience in functional testing. These teams have a lot of knowledge about the system landscape, but there are often only a few developers that have a thorough understanding and overview of the business processes. Depending on the situation, the teams should be coached and mentored in order to increase their knowledge in these areas. You can also opt for a gradual transfer. This latter option works especially well if there already is a separate e2e test.
Solution 2: A guided and gradual transfer
One of our customers made his test coordinator responsible for the transition of the separate integration test towards the teams. In a weekly meeting, attended by a representative of each Scrum team, the coordinator discusses the backlog items that have a team-transcending impact. He also discusses the tests that he thinks are required to test the e2e integration.
During this meeting user stories are defined for each of the identified tests. Teams put these on their sprint-backlog of the upcoming sprint. Of course, this is done in consultation with the Product Owner. This ensures that the integration items get the right priority during the sprint planning. Prior to the project the test coordinator asked explicitly for the POs commitment. This to prevent that daily troubles and pressure win and locally optimized improvements are favored above the vital system integration.
The teams agreed that the team that worked on the original user story (the one that impacted the adjacent systems) bears the responsibility for the coordination and execution of the e2e test story. During the scrum-of-Scrum meeting the progress of each e2e test user stories is monitored. This creates transparency about the quality of the business processes that form the total solution and enables the team to address collaboration issues. With each sprint we see the teams improve. Defining the e2e test items is done faster with less discussion and the teams are becoming more and more proactive. Therefore, we have good confidence that we will achieve our goal:” Scrum teams that perform end-to-end testing without using a separate integration test team.”
Chain integration in Scaled Agile projects
What challenges do you encounter while organizing the e2e tests in your organization? Do you have a separate team or do the scrum teams collaborate to make the business process really work? We like to hear from you. Please comment below.
Cho-Author – Kelvin Geerlings
Kelvin Geerlings is Senior Agile tester for Valori. He is expert in introducing Agile elements and improving end-to-end testing. He also is a trainer and regularly contributes to the Valori Blog.