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

Test Automation: Good, Bad and Ugly

The modern approach to software quality and software development life cycle requires that business guys, developers and testers understand that the long manual test phase, although often still necessary, must be reduced to a minimum and replaced by test automation. Working in continuous delivery and continuous integration environment requires us to create automated tests that run on demand, checking our application integration and it’s core functionality correctness. However, there are still many problems with designing and writing automated tests, resulting in their costly maintenance or abandonment in favour of a return to manual processes.
In this article I will focus on describing common good practices of test automation. This post is more than an overview than complete reference guide. Broader aspects, such as the Page Object pattern or Page Factory will be described in detail in a separate article on this blog. Although most practices apply for every types of automated tests, thi…

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…

REST-Assured: going deeper

In my previous post I described the basic REST-Assured usage – the lightweight framework for testing RESTful services. Despite the fact that described range of functionalities would be enough in most cases,REST-Assured has a lot more to offer. In this post I would like to bring some more advanced examples of the framework usage.



I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks:

REST-Assured – framework overviewBuilding microservices testing framework
Object Mapping Sending request’s body as string is easy and straightforward, but it can be inconvenient in the case of more complex operations on request / response properties. Proven solution for this is a good-known serialization of request/response body to objects. REST-Assured supports object mapping to (and from) JSON and XML. For JSON you need either to have Jackson or Gson in your classpath and for XML you need JAXB. Here is an example of request object serialization using J…