Testing Pit Stops In Three Seconds

Formula One has gotten us all used to amazing speed. In as little as three seconds, F1 pit teams replace all four wheels on a car and even load in dozens of liters of fuel. Pit stops are no longer an impediment to success in F1 — but they can be differentiating to the point where teams that are good at it win and those that aren’t lose.

It turns out that pit stops not only affect speed; they also maintain and improve quality. In fact, prestigious teams like Ferrari, Mercedes-Benz, and Red Bull use pit stops to (usually!) prevent bad things from happening to their cars. In other words, pit stops are now a strategic component of any F1 racing strategy; they enhance speed with quality. But F1 teams also continuously test the condition of their cars and external conditions that might influence the race.

Source: uae-f1-grand-prix-2011-race-preview-feature-mgp.

My question: Why can’t we do the same with software delivery? Can fast testing pit stops help? Today, in the age of the customer, delivery teams face a challenge like none before: a business need for unprecedented speed with quality — quality@speed. Release cycle times are plummeting from years to months, weeks, or even seconds — as companies like Amazon, Netflix, and Google prove.

The answer: Smart dev test teams do it — why can’t you? You can! Testing is radically changing with the advent of Agile and DevOps (I look at DevOps as the continuation of Agile or, better, as Agile all the way through). I’ve talked about DevTestOps on this blog and in my report on scaling Agile adoption and it turns out that I’ve never been so right! Testing can’t any longer be a weak link indelivery; everybody recognizes its crucial role for achieving quality at speed. Therecipe involves testing properly, quickly, and continuously. How? First, make “doing the right things” (functional quality) and “doing things right” (technical quality) your driving goals. Then adopt these five must-dos:

  1. Organize testing in a lean way. Eliminate waste; focus on value. Get developers and testers to work together in sync in the same team.
  2. Shift testing right and left. Build quality in from the very beginning, but also leverage testing in production and end user feedback.
  3. Build a practice for testing skills. Technical skills make the difference; your testers might need reskilling. Fewer business testers are needed. SDLC, design, and programming skills make superior testers.
  4. Reduce manual testing in favor of automation. You can’t deliver software frequently if you don’t automate testing from the very beginning.
  5. Automate test data and environment provisioning. Last but not least, test tools and environments need to be delivered as fast as F1 pit stops. To do that, automate your delivery pipeline.

Application delivery and testing teams must carry out these five activities to succeed in delivering quality@speed. Forrester clients will find more in the report 5 Must-Do's For Testing Quality At Speed as well as these two testing reports on Agile testing practices and tools. I’m sure there are more practices maturing out there, and I’d love to hear about them. Comment on this post or send me an email or a tweet (@dlogiudice).


Speed@Quality - How we do at Cigniti

Yes, Diego. As we see enterprises and independent software vendors moving towards being more agile, sped@quality matters.

A key ingredient to achieve this would be to use and invest in test automation. Test automation, automation accelerators and labs that can supplement the automation initiatives help customers.

At Cigniti we believe the future is IP led software testing that can ensure speed@quality and results in Agile, DevOps testing more effectively.

Yes Sairam, Automation is key

Yes Sairam, Automation is key and pervasive in the new way of testing. Couple of things in my research pipe: wave on functional automation testing tools, some nuggets on automation testing services.... stay tuned. Testing must become a quality enabler at speed just like pit stops !!

Zero time to detection and remediation

Software development has changed significantly, while other parts of the organization have not kept pace (testing, application security, compliance, audit,...).

It is not impossible for the areas surrounding and supporting development to catch up and better integrate, but it often means starting with a new perspective on how to approach the issue.

Diego, just as you point out in this blog, there is a lot to learn from other high-performance industries. We are now beginning the era of managing high-speed software supply chains, that require all teams across the organization to reconsider not only the speed and innovation within operations but also taking a holistic view of quality attributes.

Looking forward to your future blogs on this topic.

Hi Derek, thanks for your

Hi Derek, thanks for your comment. I could not agree more that for delivering software value to business faster and better requires that Quality becomes a shared goal of all stakeholders and team players. The days of independent quality teams and responsibilities are over. There is only one way to go forward which is building quality IN from the very beginning... or we will never be able to keep up with required quality@speed of the BT era !!...

Simple common sense!

Hi Diego,

As you explained if you start doing things correctly and planning correct most of testing problems are solved, The first 3 points will define roadmap and Automation will boost up the speed.
Even today there are lots of people think that Test starts only after development. Not easy to make them understand how starting early helps. One more worst affected area is the products, when products are getting configured or implemented differently, again consultants think that functional consultants need to test and no tester is required for the work. To Run a Test assembly unit there need to be maturity across the team!