New Testing and Regression Checking: Opposites that Attract with James Bach

When I talk about the creativity, critical thinking, and exploratory learning that comprises testing, there is a good chance someone will ask "what about regression testing?" One simple answer is that regression testing is just like new testing, except it has a specific risk focus: the risk of bugs introduced to the product due to changes. But that is too simple, because when the question is asked it is not about testing at all-- it's usually about the value of formalized automated output checks. Many people confuse the algorithmic process of output checking with the social and intellectual process of testing.

I have observed the testing industry for 32 years now, and I think this is mostly why testing as a field never earned respect. It's why every testing conference these days is basically an automation conference. (Programmers don't have this problem, because when programmers automate keystrokes it's called "the build process" and not "automated programming.")

Automated regression checking is useful and in many cases absolutely indispensable. While I don't confuse it with testing, good automation is created through good testing and it supports good testing. New testing and regression checking are, in a sense, opposites, but they are in no way enemies. In this talk I will help you sort these things out so that you can approach your work with clarity.

James will also be teaching the full 3 day Rapid Software Testing Course from 9th - 11th October. Meetup members can take advantage of 15% off using the code RST15 when booking online or book 4 for the price of 3, use code: 4FOR3.
https://www.learningconnexions.com/all-courses/56-rapid-software-testing/region-UK/

About the speaker:
I started in this business as a programmer. I like programming. But I find the problems of software quality analysis and improvement more interesting than those of software production. For me, there's something very compelling about the question "How do I know my work is good?" Indeed, how do I know anything is good? What does good mean? That's why I got into SQA, in 1987.

Today, I work with project teams and individual engineers to help them plan SQA, change control, and testing processes that allow them to understand and control the risks of product failure. I also assist in product risk analysis, test design, and in the design and implementation of computer-supported testing. Most of my experience is with market-driven Silicon Valley software companies like Apple Computer and Borland, so the techniques I've gathered and developed are designed for use under conditions of compressed schedules, high rates of change, component-based technology and poor specification.