Where would you start with automation in a micro services environment?

[stardust]

I have been working in automation testing for many years now, and I have previous experience doing automation and load testing mostly for web and mobile apps.

I started working recently for the first time in a project with micro services architecture, we are trying to introduce automation to our testing process but I find it difficult since it’s very dynamic in the upper levels and it’s really expensive to maintain any kind of automation there.

I have been reading and hearing about contract driven testing for a while, but I am new on this world and I don’t know where to start. Any ideas?

[russell.craxford]

Where I am we’re on a journey to introduce service architecture, we’ve struggled a little with the same question what ended up happening for us was be built contract tests into our CI for each service- I’d recommend reading https://martinfowler.com/articles/microservice-testing/

[joaofarias]

I thought in suggesting this same document Russel.
As Martin Fowler himself says, architecture is the shared understanding of how things work.

Communication is necessary for good architecture understanding.
If we are in a well-known context, we can even move further with bad communication. However, when in enter in uncharted/complex territory, this understanding is necessary.

Therefore, before thinking in tool X or strategy Y, I would think if the communication is effective:

• “Do I understand the wording used by developers? Do they understand the terminology of testing?”
• “Do I understand why they take certain decisions?”
• “Do others know the necessary conditions to evaluate quality in our project?”
• “Are ways of reflecting upon how we work, so we can brainstorm and experiment ways to improve?”

In summary, I think it would a great risk and a bold assumptions to think one can sit in a cubicle (physical or mental), receive a bunch of changes and expect to be able to evaluate and communicate the necessary stuff in a reasonable time.

The “technical” can be sorted out afterwards.