The first session I attended was proposed as two sessions, each on slightly different aspects of software regression testing. Jane Hein, a conference attendee, agrees to combine her proposal, "Making regression agile," with mine, titled "Level up your regression testing." Jane is director of product engineering at a software organization in Oregon; she is at the far left of the picture.
We use the time to identify patterns to compress (and remove the pain from) the regression test process. The first idea is to do manual, human tests for system stability continuously as programmers create new builds. This allows the final regression test at the end to be much shorter.
John Saif, who is participating in our session, points out, "No time for regression is a sign of too many features in the sprint," while Dale Emery, a California-based consultant, suggests that "done" should include some confidence that the developers haven't broken something else; thus, developers should be automating checks to ensure correctness.
Other ideas we hear include stronger unit checks, continuous integration, triaging the manual regression tests, and looking for patterns in defects to catch bugs earlier and prevent a painful regression test process.
My lesson learned was that there is no one right way to minimize regression pain. Instead of a silver bullet, companies may be better off seeking a combination of bronze bullets -- small improvements that, when combined, result in radically reducing the length of the regression test process.