Beating the clock
Time for testing: can we stretch it?
Wouldn't it be great if we could put Einstein to work with us, and somehow create ways to stretch time? And if not Einstein, then perhaps we could ask Super Man to travel the globe and bring back the time needed to build right the first time around and avoid rework...
Time has always been a controversial theme in every industry – Will there ever be enough time? Time to develop? Time to test?
Time for testing was never a consensus thing, at least not for Quality Assurance teams. For the past century, the Telecommunications Industry has been recognized as one of the most challenging business segments when it comes to affording time to test.
This challenge has drastically increased since the beginning of the Digital Transformation Era. It has in fact led us to believe that we don’t even have the time to develop!
However, truth be told, the industry has managed to “make magic”. This can be seen in recent IT Engineering evolutions like Agile, Devops, Bi-modal IT, lean IT and others that promise to deliver more value in less time.
As always, a lot of these will go wrong before they deliver on their promise. However, there are some that have successfully began delivering results.
From a Quality Assurance perspective, some of the traditional technics that help us “stretch time” are:
- The ability to foresee from the beginning where things might go wrong and as early as possible design the appropriate testing strategies that cover these scenarios. This is the case for Risk Based Testing (RBT).
- Test Case design technics aiming to optimize the testing sets that promise to identify as many bugs as possible. This is the case for technics like Boundary Value Analysis (BVA), Equivalence Partitioning (EP), Use Case Testing among others.
- Detect errors as earlier as possible by combining verification and validation technics throughout all project phases from the high-level requirements to the coding and different testing phases.
- Test Automation allowing us not to expand the calendars for execution of repetitive tasks such as regression testing.
More recently, techniques like shift left testing [1], analytics driven testing [2], test-first approaches such as test-driven design (TDD) or behavioural driven design (BDD) emerged and helped combat the “stretch time” challenge.
But to stretch time, we need to go beyond “QA”.
First of all, we must ensure that Quality is the result of everyone’s action, every single day since day 1. It must be ideated, it must be high level required (know what to do, but also what not to do), it must be estimated (what a great time expansion technique), it must be designed, managed (another great technique to expand time: dependencies management), built and validated. Quality is not only the responsibility of Quality Assurance teams.
As one company put it when deciding to launch a quality program, “You are looking to the Quality responsible”. This motto was screened into mirror panels that were spread throughout the company’s facilities.
As a corollary of all this, it is obvious that it is a journey… a continuous one. As paradoxical as it may seem, with all the time this concept encompasses and still with that frantic idea that we don’t have the time to do it. We do, we just need to stretch it with these and other concepts. It’s a matter of one and everyone’s choice.
And before trying to stretch time, let’s spend some time on it. One of the principles of Toyota is exactly to “Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time” [3]
References:
[1] Firesmith, Donald. Four Types of Shift Left Testing. https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html.
[2] Jibaoui, Hussein. Analytics Driven Software Testing. https://www.linkedin.com/pulse/analytics-driven-so...
[3] Liker, Jeffrey. The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill Education.