Familiar story: A few devs commit some lovely code, one dev commits some lovely bugs. Testers deploy the latest code compiled from all devs that evening. Testers begin running some tests the next morning. A bug is located. Who made it requires a little bit of chasing. What was the change that made it requires a bit of thinking. Dropping current tasks to pick up bug fixing requires a little bit of context-switch-time. That's inefficient. Finding bugs early is cheap. Any delay and costs start ramping (illustration of a graph with a curve available here)
What's pretty cool/sleek/shiny is the far-from-new-or-novel idea that we perform a bunch of tests against everything a developer creates. Immediately. For every change. Just run stuff.
Amazon are typically the prime example of having the sleekest of processes, as they are able to go from a developer making a change to actually seeing this change in production within 1/2 an hour[0], having completed a full regression in this time.
[0]this is from a conversation I had with some random person at some random pub, credibility is definitely lacking. But the idea is there, captured in this (possibly fictitious) scenario, that with the right testing in place we can provide however much feedback is needed.
So, what do we want? We want a range of tests which are easy to create, easy to maintain, that cover off a fairly vast portion of the application, and detect defects quickly. This just requires having a healthy build process within a team, and plugging in a test automation framework that meets the requirements. It'll all need to be easy, largely (100%?) automated, and have valuable feedback to the team.
There's nothing profound with any of this; it's a simple idea: test early and often. It's cheaper, and will allow everyone to spend their energies on making the best darn product they can.
No comments:
Post a Comment