Date: 05 October 2021
I’ve worked in software testing for well over ten years. During this time I’ve worked on a number of projects for large-scale companies from various retail verticals to government agencies.
These are large, well-funded projects with resources readily available, however, I still see the same issues crop up time and time again when organisations continue to follow traditional software development models, such as the Waterfall, V-model, or even hybrid approaches such as Agile – Waterfall models, which are all heavily structured around business silos.
So what’s the problem with Traditional Methodologies?
Typically, projects are scoped, and BA’s write requirements, which are then handed over to development and then lastly, thrown over the fence to testers. Testers raise defects and then the cycle is repeated. The problem with each of these models is that they do not have testing as an integral part of the cycle, so projects often fail to deliver on time for resolving defects and handling scope creep. Consequently, budgets are blown, the end product is of poor quality and the software does not do what is expected.
In fact, according to Mckinsey “On average, large IT projects run 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted”1. There are plenty of well-publicised examples, not least the $1.2 billion blow-out by Auckland Council which they attributed to “the complexities of moving from computer systems inherited from Auckland’s eight former councils to a single environment.”2. While I may not know the exact cause of this overrun, I do know that a big bang approach to large-scale IT projects is never a recipe for success.
Furthermore, in my experience, many IT organisations that go through transformations to adopt Agile fail to properly implement Agile practices correctly; so, when testing activities are done, they continue to be done last or late in the cycle meaning critical defects or flaws in the solution can still be detected. At these later stages, it is often quicker to patch the code rather than apply a permanent fix, making refactoring necessary later.
I’ve seen issues arise when the vendor is working in Agile, but the client is not. In practice, this means a delay to user acceptance testing and production, the backlog of work increases, technical debt ensues, budgets overrun, sprints are rescheduled or are delivered late. These problems are encountered as a direct result of delaying test activities or if testers are not actively engaged from the early stages of design and development.
So what is shifting left and will it help?
Basically, shifting left means bringing forward test activities to much earlier in the project (literally shifting test activities left on the project plan). Fundamentally, it’s about understanding the project and then planning, estimating, and resolving issues quickly. It means test early and test often. It means review the estimates, review the requirements before development starts, it means start automation. It means having testers integrated in the delivery cycle: requirements > design > coding > testing.
In my opinion, adopting Agile and Shift Left testing is the way to go and even better if you have cross-functional teams that are co-located. Having a unified test strategy, to define all elements of testing, including documentation reviews, unit testing through to user acceptance and pre-production is also a great starting point. Once you’re set up this means testing can start early and test often and be integrated with the whole delivery process. With the right framework, testers can:
- Have clear visibility of the solution
- Focus on customer requirements
- Write test cases in advance
- Automate tests and run them early and often.
- Identify defects early
So what are the benefits to Shifting Left?
First and foremost, shifting left means a better quality product is delivered with fewer production defects and delighted customers and also:
- Opportunity to design tests early
- Defects are identified early
- Reduces the risk to project delivery dates
- Reduces costs associated with rework \ code refactoring
- Teams working together, all being on the “same page”
- Overall continuous approach
Finally, we know that Shift Left testing is not a new concept, but a mindset that fosters collaboration across the delivery team. It allows you to deliver quality solutions on time and within budget and enables you to delight your customers.
References
