Testing As The First Activity Of A Release...

The French have a good way of putting it “Plus ca çhange, plus c’est la même” (The more it changes, the more it remains the same!) – and that seems to be the constant battle that I hear being played out w.r.t testing. At conferences one hears the constant moans about testing (and testers) being given the short shrift; the groans over the focus on development (and thereby developers) over testing… And collectively a sigh, that if there is an activity that is compromised in the lifecycle, it is testing.

I believe we should stop associating testing being the "LAST" activity that traditional software development models like Requirements-Design-Code-Test impose on us, and instead associate it as the FIRST activity to a release.

To me it was an a-ha moment, when I made this realization. The change in perspective, about how we not only view our craft and ourselves, but how we approach testing and the interactions with the different stakeholders.

As the first activity of the release, it is now our job to ensure that we dictate what everyone else needs to do to derisk the release from a technical and business standpoint. This essentially gets us to drive the focus towards features that are important to the business should they fail, and also towards those that most likely to fail, given what the release is about.

We as testers, should think not just about the process of release itself (deployment testing), but also assess the readiness of teams to support the release (operational readiness testing). We should, based on the release, focus on functions critical to the business, and / or the technical aspects of performance, security, or any other ‘ity’ to ensuring a defined level of customer experience (customer experience testing). Working back from the release objectives, we as testers can now define how the behavior of the other stakeholders should be.

Welcome your feedback.. and experiences.