Our automation experience I

Pablo Grela
Divide and Conquer
Published in
2 min readMar 6, 2020

Do you have tests in your project? You should.

That feeling… every time you need to change anything or implement a new feature and have the security that you are not breaking anything. Safety.

But.

There is always a but.

Implementing tests requires an extra effort, and also your client needs to be aware of the advantages of tests. We did it! We show our client that tests are our friends. So we need to have a 60% of coverage with Unit tests and try to automate as much test cases as we can to avoid long regressions. We have a huge app so our regressions were one week long.
Six QAs working only in regression during two weeks means no new features during two weeks.

Now we have three days regressions. 🥳🥳🥳

OMG UI tests, everything was new. We had no experience at all with UI tests, and it was really hard at the beginning. Some tests were failing randomly, others were passing in local.

It works in my machine

We were not mocking all dependencies, so if tests devices went offline, some tests failed. We fixed it, but some tests kept failing.

The main problem was that we implemented more that 1000 UI tests, so we ran the whole suite every night, but when we arrived next mornig at the office and some tests were failing… who did it? No one.

One day of work means lots of pull request and thousands of lines of new code, no one realised if they broke something.

Solution? We needed to run the test suite more times during the day.

We started with annotated tests, we created a custom annotation and we added it to some "important" tests, then we ran them twice a day.

It was not enough.

What about adding another test device and run all the test in parallel? Let's see how we can do it!

Part two.

--

--