What is your organizational automation strategy?

Looking some ideas in terms of automation strategy in testing in order to help organization succeed.

Do you have one currently? Do you need one?

What do you include in your current strategy? Or what would you include?

1 Like

Our strategy so far has been to encourage teams to use a lot of unit tests. They are not “sexy” as many other frameworks but they are close to the code, fast and quite easy for developers to add. They make it easier to refactor later on.

We have had several teams beginning to use their own ideas of test frameworks and they get started but then stuck due to problems with:

  • test data
  • maintenance when the system changes
  • test environment for SUT
  • competence, key persons that drove things forward left
  • dependencies to surrounding systems

The above are all possible to solve, but most developers focus too much on just the test part.

Our next step was to use Docker to run automated tests as part of the build pipeline, instead of them running tests against regular test-environments where tests tend to fail when testdata changes of systems are up/down.
We’ve tried to make it easier to start an environment with the app they want to test, database and mocks. And then a testrunner with whatever framework they perfer.

This worked quite well, but now we still sit on several different test frameworks and I’d like to streamline, standardise and package it more. Making it easier to get started for teams not using it yet - taking test automation mainstream :slight_smile:

My experience is it’s better to wait with GUI-tests since they often turn in to nightmares of maintenance. Start with API/service-layer tests since APIs are designed to be stable.

1 Like