Skip to main content

Software testing vs modern architecture

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!

Popular posts from this blog

Notes after TestingCup 2018

On May 28-29th I attended TestingCup conference in Łódź. Having quite unique perspective: this was my second year in row as a Speaker at this conference I want to share some thoughts on the event. Dust has settled, lets go! 



Championship Originally TestingCup is a software testing championship. Wait, what? Yes, the formula is unique: teams and individuals from all around Poland are competing in finding the most bugs and defects in specially prepared application - Mr. Buggy. I don’t have specific data, but since this year’s conference was all english I guess competitors were not only from Poland. As a spectator, I must say that the whole competition looked very professional. There were team shirts and names, podium and trophies (gold cup and cash). 
Some cons? Testing championship is held at the first day of the conference. So this is already a conference, but if you’re not taking part in the championship… there’s not much to do, since all the talks are in the next day. Organizers are aw…

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

Building microservices testing framework

RESTful services and microservice architecture in general are big trends in the industry right now. I’ve noticed it also from this blog’s traffic analytics, where topics related with REST testing get the highest interest. Therefore I’ve decided to create some kind of example framework for RESTful APIs functional testing. Project is based on REST-Assured as a services client, Spock as a testing framework, Groovy and Gradle. You can clone full repository from my github. Tests are run against Wiremock API described in this post. Please consider this project as a kind of bootstrap, since it’s an example, not full-blown test framework. Ok, so as Linus said – talk is cheap, show me the code!
Dependencies Usually, first thing for me after importing new project is opening build.gradle (or pom.xml, in case of maven). In our example, the most important dependencies are REST-Assured and Spock. We’ve also Jackson, for serializing objects, Logback for our logs and snakeyaml for reading .yaml files,…