“Trust Takes Years To Build, Seconds To Break And Forever To Repair.”
Product delivery teams these days often rely on feedback from automated tests to determine the quality of the product they are working on. Running automated tests every night or after every commit, depending on the type of test and the adopted development process, gives teams information about the impact that changes made to the code have had on its overall workings.
However, with great power comes great responsibility. The more you rely on the feedback from your automated tests to decide whether to let a build pass to the next step in your build pipeline (and this next step might just be a deploy into production!), the more you need to be able to rely on the quality and defect-detection power of these very automated tests.
In other words, trust in the quality of an application is required, so if the application is tested in an automated fashion at any point, you must also trust in the quality of these automated tests.
Unfortunately, this is where test automation all too often fails to live up to its promise. Instead of being the stable and reliable guardians of application quality they should be, automated tests regularly are a source of deceit, frustration, and confusion. They end up undermining the very trust they are meant to provide in the first place.
In this session, we will focus on understanding How can we start trusting our automated tests again? Let’s explore what you can do to repair the situation-or, even better, prevent it from happening in the first place.
Session Takeaways:
