Nmedia - Fotolia


Everything you need to know -- and love -- about testing microservices

Like it or not, DevOps and, thus, containers and microservices are here to stay. Expert Gerie Owen explains what you need to understand about this new world.`

Just when testers thought it was safe to emerge as agile practitioners, the development world has tossed out a raft of new ways of looking at and developing software that testers must understand and integrate into their testing cornucopia. If you've heard terms like DevOps, containers, continuous deployment and microservices for the first time in the last year, you're probably not alone.

It turns out that they all relate to one another and, together, represent the next step beyond agile in developing and delivering software. Yes, you'll be testing microservices soon. But let's start with containers, since you probably already have at least a high-level understanding of DevOps.

Like most software architecture structures, the concept of containers is not new. Vendors such as Symantec and LANDesk developed products that let different versions of applications, such as Microsoft Word, run on a single system so that the underlying Windows operating system wouldn't detect and prevent both running at the same time.

It turned out that these products were of interest primarily to software testers who had to test their applications in conjunction with different versions of commonly installed applications and never moved into general use.

Today's containers, such as Docker, take that one step further. Docker, in effect, lets you virtualize any piece of code, no matter what programming language was used, and let it run on common operating systems without modification. If your code makes calls to other applications and other parts of the same application, Docker handles that interface.

Testing microservices

The container has enabled the idea of microservices. A microservice is a software component that performs a single task, such as authentication, data validation or database writes. That makes each component fairly simple to design and develop. Many microservices working together form the application.

If you're not at least conversant in these technologies, you have to be so soon.

If this sounds suspiciously like the old web services concept, you're right. The primary difference is that the old web services tended to be larger and more formally developed. They are still used, primarily by commercial data providers such as weather or sports services. Individual organizations may also have custom-developed web services to provide business logic to multiple applications.

Those web services also had a defined programming interface, documented in a Web Services Description Language (WSDL) file. They typically interacted using the Simple Object Access Protocol (SOAP) over HTTP.

Microservices can use different calling conventions and don't have a formally defined way of interacting. Many use JSON or REST. They tend to be more flexible than WSDL and SOAP.

Microservices mean new organizational structures

So, how is testing microservices going to come about, and what is it all going to mean? At DevOps Days Stockholm, Veracode engineer and speaker Peter Chestna presented an argument for the concept of the full-spectrum engineer, a reincarnation of the current full-stack engineer. The full-stack engineer has the programming knowledge and experience to work on all aspects of an application -- from user interface to database.

The full-spectrum engineer takes that one step further, making a single engineer responsible for not only coding the application, but also for application security, quality, configuration management, deployment and all of the other tasks associated with successfully putting an application into production. The rub is that the full-spectrum engineer is responsible for all facets of only a single microservice, rather than an entire application. The scope of the engineer's responsibilities is expanded, but the amount of code he or she is responsible for is limited.

So, where does this leave the quality assurance pro facing a future of testing microservices? Not surprisingly, first, it means that you have to keep learning and developing your skills. If you're not at least conversant in these technologies, you have to be so soon. Don't count on your employer to help you; you have to take charge of your own skills development.

Second, in an era that will increasingly introduce microservices into applications, with the prospect of a full-spectrum engineer taking over testing and quality responsibilities, it means that you are likely to be more of a consultant and maybe not doing hands-on testing microservices. Certainly, you need to retain the skills to be able to jump in and help, but it's likely that individual testers will be matrixed across multiple microservices, serving several full-spectrum engineers, understanding each service and providing plans and test cases for each.

Third, integrating these microservices into a coherent application or set of applications will increasingly become a challenge. Integration testing and system testing will gain in importance.

Your testing knowledge and experience remains valuable. But accepting the testing microservices trend, getting the necessary background and understanding your new roles will determine your success.

Next Steps

A primer on containers and microservices

What role can and should microservices play in deployment?

Using microservices to get you to the cloud

Dig Deeper on Testing APIs, microservices and distributed systems