How do you handle your work if you are employed at a fast-growing company where every sprint holds a ton of new features? The code base is growing every day and product coverage becomes a considerable challenge. Even if you solve it by writing autotests on a daily basis to handle the load, there may come a point where you have so many automated tests that maintaining them in their thousands becomes a whole extra headache. How can you keep track of what tests are actually important, and what can you do if they are gradually failing?
At Playtech, we have thought about those questions for many years and tried out different techniques. In this talk, I will give an overview of how we define self-contained automated tests – tests that are running continuously, proving their relevance – and how they can find the exact component version where they got broken. Additionally, I will touch upon how to use remote debug to find the issue so that others can use the same tests in same environment at the same time. In conclusion, we are aiming to design automated tests that can keep up with a fast-growing product.
* The idea of self-contained automated tests
* Why it is good to query the production database every night
* Why use a binary search algorithm to find bugs
* How to remotely debug problems so that others can use the same environment meanwhile