Test impact analysis for faster pipeline sake

Test impact analysis for faster pipeline sake

Did you see my previous presentation on test coverage? This one is continuation of my story. This time instead of sharing my research, and theoretical outcomes, I will discuss practical use case of test coverage analysis – test impact analysis.
Don’t you struggle with large suite of automated tests? Perhaps you run, as in my case, all tests against every single change. Doesn’t matter whether you push directly to master or employ feature branching. Your developers will spend a lot of time waiting for test results. To reduce the pain we parallelise test runs, push tests down to the pyramid, focusing more on isolated tests of components or units.
Parallelisation has its limits and it’s not like you’re saving money, just time. Pushing tests down the pyramid sounds nice, but takes time, and a lot of commitment that may be hard to build. What if there was an easy way to reduce test execution time and keep coverage? What if there was a way one can analyse impact of a test on production code? Fortunately there is, and I will discuss it in practice. How with open source tools and a bit of investment you can run only those tests that make sense for particular change.