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.
Tester at heart. One could say, born to test. Keeping hands dirty with test automation and scripting since started professional career. Designing strategies, architecting, delivering frameworks and test environments for web and mobile applications. Actively involved in local testing communities. Presenting on most popular testing and development conferences in Poland and Europe. Since joined Spartez, helping developers at Atlassian become better testers. Teaching them how to explore. In love with big data, scientific method, and statistical analysis. In pursuit of quantifying quality in Software Development with a single formula.