If you work with distributed version control systems like Git, concept of pull requests should be clearly obvious to you. In simple words: if you want to have some code implemented in project maintained by others, you make yourself a branch, write code and create a pull request that will be merge to this project after code review. In big picture: it’s you who should make changes and the project owners are only doing code reviews.
Distributed architecture means distributed organization
Idea of external pull request works well also when it comes to single company and distributed architecture. Quoting Conway’s law on software architecture:
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”.
I’m not going to argue whether architecture or organization structure comes first, but the fact is that most companies that implemented distributed architecture are organized into teams. Teams are independent up to some point, and each team develop and maintain one or few services. That’s most common organization structure for most modern software development companies.
Following pull requests model – If you want to have some change implemented in application maintained by others, let’s say you run authorization services and you want to have changes in user-store services (all those applications work for one system, eg. web chat app), you’d have to implement it yourself and create pull request, which would be reviewed and accepted (or not) by the ones that owns this application.
Software testing in distributed organizations
While it’s clear when it comes to code implementation, software testing is a part that could confuse here. If you’re making changes (as a team) in project which is not yours – who should test them? You or the owners? Remember that we’re talking about separate services, but under one system. The problem is that while code speaks for it’s own and all the edge cases would be reviewed further, software testing requires another level of expertise. To test this application you should know the business domain, integrated applications, known issues, regression suite, …and the list goes on.
The most obvious solution is that implementation is done by team which made changes, but testing is on our part of the fence – team that owns the application and know all the issues and dependencies the most. Here it starts to be complex: If you’re Product Owner, how can you estimate your tester’s work in sprint, If some other teams changes can always require unexpected testing? One would say: “Put them in backlog, I have other things to do” – well, that’s neither so agile nor big-picture goal oriented approach.
Test Lead
There’s a debate whether role of test lead is still necessary in world of agile, where we have self-organized, independent teams, with one tester per team and no room for separate test team with their own phase. All development efforts – planning, implementation, testing, deployment – should be done in one sprint. Test Lead role responsibilities in this environment are very fuzzy, though I strongly belief in its necessity. Besides mentoring and personal development of peers, Test Lead is the one who should plan testing efforts through the teams, provide requirements and help to estimate work. He should also be the figure that rather works with the teams than in the teams, thus he can help deciding who should test changes and how it should be done.
Test Guilds and Chapters
Having the role of Test Lead in your organization means that some decisiveness in testing area is centralised. Lately there’s another interesting concept, originally introduced by Spotify – guilds and tribes. We can learn from it not only how to organize software testing, but also whole company structure.
Going back to our example of web chat application: we’d have some areas of services/application in the same domain. We’ve already mentioned example of authorization and user-store, which would be in one domain. payments or cloud infrastructure maintenance are examples of two another domains. What’s important here is that teams working in same domain would naturally cooperate more with each other than teams in different ones. This domain refers to what Spotify’s called tribes. In one tribe we can form Chapters – cross team, informal structure of peers in the same role, like testers chapter. Now let’s say one team made pull request to other team codebase, both in one tribe. The responsibility of the Testers Chapter is to exchange domain knowledge which is necessary to test new functionality and to plan test activities.
Having all the testers of one tribe during – let’s say weekly tribe’s test planning could be highly beneficial also in creating test automation plans. In big organizations they tend to grow big, therefore unstable and hard to maintain. Test automation projects can be limited to tribe, what makes them easier to handle and implement.
Summary
Agile movement and distributed architecture made a lot of new challenges in area of software testing. Above concepts are just ideas to seek further – I think there’s still a lot of to improve. How you or your company solve above problems? Let me know in comments!
