...regression testing is optional. What? The horror!!!
Back in the dark ages, with Scrum, we were spending about 4 days of each iteration regression testing. This product has lots of business logic in the UI, lots of drag-and-drop-type functionality, and very dynamic data, so it has never been a good candidate for automation. Our regression test approach was to throw a bunch of humans at it (see my Group Regression Testing and Chocolate post). With Scrum, each prod deployment was a full build, including about 14 modules, because lots of stuff got touched. Thus, we always did a full regression test, touching all the modules. Even after an exhaustive regression test, we generally had one or two “escapes” (i.e., bugs that escaped into production).
Now, ask me how often regression tests failed? …not very often. And, IMO, that is a lot of waste.
With Kanban, each prod release only touches one small part of the product. So we are no longer doing full builds. Think of it like doing a production patch. We’ve gotten away from full regression tests because, with each release, we are only changing one tiny part of the product. It is far less risky. Why test the hell out of bits that didn’t change?
So now we regression test based on one risk: the feature going to prod. Sometimes it means an hour of regression tests. Sometimes it means no regression tests. So far, it’s a net loss of time spent on regression tests. And this is a good thing.
We switched to Kanban in February. So far, not a single escape has made it to prod (yes, I’m knocking on wood).
This success may just be a coincidence. Or…maybe it’s easier for teams to prevent escaped bugs when those teams can focus on one Feature at a time. Hmmmmmm…