What is the relationship between these two objects?
How about these two?
This, I’m afraid, is how testers (myself included) often see software modules…like black boxes. Their relationships are hidden from us. We know the programmer just changed something related to the seeds inside the orange, so we ask ourselves, “How could changing the seeds inside the orange affect the toaster?”. Hmmmm. “Well, it sure seems like it couldn’t”. Then, after a deployment, we’re shocked to discover the toaster starts burning all the toast.
Why didn’t the programmer warn us? Well, just because the programmer understands the innards of the orange, doesn’t mean they understand the innards of the toaster. In fact, based on my experiences, if there is enough work to do on the orange, the orange programmer will happily take it over learning to code for the toaster.
So here we are, left with nothing better to do than regression test the toaster, the jointer, and the flash light, every time the orange changes. No wonder we spend so much time regression testing.
In conclusion, maybe the more we learn about the architecture behind our software system, the fewer regression tests we’ll need to execute. Instead, we’ll better focus our testing and make the invisible relationships visible for the rest of the team…before development even begins.