Go slow to go well
Writing Selenium automated tests in Java is a lot of fun.
It provides one with a sense of
doing good work
being capable
contributing
achievement
And it is very tempting to go through each test as fast as possible because the more we do, the better, right?
Usually, coding fast means that as soon as the test works, we mark it as done and we move on. We may organize the test as per page object model and we may run it a few more times.
“It passed 5 of 5, let’s go! What’s next?”
Another automated test, and another, and another, soon we will have a lot of them.
All our tests run well locally when executed sequentially.
But they take such a long time.
And no one appreciates waiting 2 hours to get any feedback from them.
Also, there is not much that you can do on the local machine while the tests run there.
So, you create a pipeline in CI/CD and start executing them there to reduce the total execution time drastically.
There are a few differences though. The tests will be executed:
in headless mode
in parallel
in a grid, in docker containers
What comes out of the headless, parallel execution is usually that the tests are not stable at all.
They fail a lot and in many places.
And this is something that needs to be addressed ASAP since the dev team needs the automated smoke test for their deployments.
Why do the tests fail?
There are a few possible reasons:
the code quality is not too good as there were no code reviews done during development
code maintenance is difficult
the tests were not executed in headless mode so far
the synchronization between the tests and site is not good enough when the site has lots of concurrent users
the tests were not executed in parallel mode
the tests were executed only locally, using local browsers and not in a grid and in docker containers
It looks like there is a lot of work to be done now and on a short time.
But this time, there is a slight problem.
If before the development team was appreciative of your automated tests, now they start having doubts.
Same for your team lead.
It is not great to realize that your automation code needs more changes, more fixes, tuning, much more testing, etc. at a moment when the dev team just needs results.
The questions that may be asked are
“why did you not write the code correctly from the beginning?”
“why did we not do code reviews?”
“why did we not do code refactoring before?”
“why was the code not tested properly before pushing it in CI/CD?”
The answer to all these questions is “because we created the tests fast”.
All these issues are the consequences of rushing and not paying attention to a lot of important factors.
So, maybe from now on, resist a bit the temptation of coding fast.
Between
tests created fast that fail a lot, are unstable and need a lot of maintenance and
tests created slowly that work all the time, are stable and need minimal maintenance
everyone prefers the fast option 2.
Which is not possible.
So option 2 is the only one left.
Helpful.. thank you