At the Agile Testing Days 2015 Jose Lima from Redgate software shared his experiences with developing and testing microservices. InfoQ interviewed him about advantages and disadvantages of developing products with microservices, how applying microservices has improved the quality of products, testing microservices and the skills that testers need, and the things he learned in developing and testing microservices.
InfoQ: Can you elaborate on the advantages and disadvantages that you have seen when developing products with microservices?
Lima: The first thing to point out is that my experience with a micro service architecture has mostly been exclusive to services that we develop for our internal customers. The only place where we reach out to "customers" (I work in an internal development team so our customers are mostly the staff at Redgate Software) is within our website through the shopping cart for example. Just like advantages there are loads of disadvantages, but in our context one of the things that we have had a fair amount of success with is the loose coupling that each service has. We have to integrate with a fair number of external services and applications so the ability to do that, having it as a design principle is really great.
I’d say that one of the disadvantages could be performance where systems are now talking through channels and its performance could be affected with communication taking longer. And the reason I say "could be" is because it doesn’t apply for us. I mentioned in my talk at Agile Testing Days that we don’t care if a message takes over a second to reach its destination, but if you are in a different environment (a bank for example) then you might care about it.
InfoQ: Do you have examples showing how applying microservices has improved the quality of products?
Lima: One of the best examples we have is our own shopping cart that at the end of checkout. It used to not only take money, but also deal with the invoice, contact the licensing system, record customer details, etc. We are still in the process of separating it all, but we have created a small service that is responsible for marking the payment as completed, and only then it goes off to do other stuff, after it has taken payment.
InfoQ: Can you describe how your teams are testing microservices?
Lima: Our approach to testing has certainly changed over the years, and I can only offer my view of what testing is compared to what it was before those changes, as I haven’t worked in a different team. We certainly spend a lot more time talking with developers, product owners, etc. than we did before and it almost becomes like an advisory role at times. In my team I am not the person writing unit and integration tests, although sometimes I will be chosen to review them (or review any other code change for that matters).
But we have also adapted some development principles that helped us to get to where we are at the moment, and I think instead of calling it testing changes I would call them development/engineering changes. One example is to have a master which is always deployable to production, so you better not push anything to the master that you don’t think is of production quality. In terms of actual technical work, I have found that I perform a lot more (exploratory) testing than before, because I am not (due to changes in attitude) finding the really silly bugs anymore and can spend more time learning and studying the system under test.
InfoQ: Which skills do testers need to be able to test microservices?
Lima: I have mentioned three different categories in my talk. The first is without a doubt technical skills such as automating environment creation or learning about good continuous deployment practices. Some people will say that test automation is also a required skill although I don’t agree. First of all I don’t believe in test automation, second of all check automation can also be performed by other members of the team, not exclusively testers. There’s no such thing as test automation, but there certainly is check automation – to me testing is a lot more than just checking, and the checking process can be automated, but only after you have studied and learned what something is doing and what is meant to be doing you can put a check in place (automated or not) to check that something is performing as it should.
My business analysis skills have also grown over the years, and I find myself talking to stakeholders and product owners a lot more often and finding out more information too (although we are generally lucky enough to have a BA that performs these tasks) so I can perform exploratory testing more efficiently. Lastly, social skills are something that you will most likely need and mine have also grown over time, as chances are I will always pair on a daily basis.
InfoQ: Can you share the things you learned in developing and testing microservices?
Lima: I think as much as there is a change in technical skills there is also a change in attitude as there’s a chance that you will end up with more services than members of the team. Everyone will have to own all the services as a collective rather than individuals owning bits. This will allow knowledge to be spread out evenly within the team, so maintenance will become less cumbersome, and new services will have input from people with a diversified experience.
InfoQ: Is there any advice that you want to give when people are considering to adopt microservices?
Lima: I would ask people to contemplate about the pros and cons of this architectural approach, seek for companies or people that have made the switch before and were not only successful but those that also failed. Of course you should focus on the positives about adopting this architectural approach, but there are also disadvantages, so you must consider your context and whether this approach would work better than your current one or if there is something else out there. If you do decide to implement it though, be careful and make sure you have both skilled people (as I said above) and people willing to put up with the change.