How to Increase Software Quality, Reduce Cost and Get The Most Out of Your Testers
Effective shift-left using collaborative Test-Driven Development
Is your budget finite, timelines impossible, and quality an unmeasurable thing in your delivery projects? 95% of people reading this will agree with those statements — and yet everyone has heard of Shift-left within the software industry — why is it so hard to implement? This blog takes you through a brief history of why it is important, and some lessons I have learned over 20 years as a tester.
Why is this important?
Let’s take a step back — two decades ago when I took my first test management course it was already an established principle of software test methodology that the earlier you find a bug in the development life cycle, the cheaper it is to fix it, with bugs found post-release being most expensive — both in terms of monetary and reputational damage. Some of the most infamous events witnessed include:
- Pentium FDIV Bug, 1994
- NASA’s Mars Climate Orbiter, 1998
- EDS Child Support System, 2004
- Heathrow Terminal 5 Opening, 2008
- Bitcoin Hack, Mt. Gox, 2011
Yet, the Industry was following the waterfall model for software development where the Testing Phase is to the extreme right of the lifecycle:
Requirements => Design => Coding => Testing
This means that when issues are found they already have elevated material impact on budget and timeline — either through release delays, or for serious design flaws, scrapping the software and starting again.
This realization gave birth to a new concept in 2001 called ‘Shift Left’ for testing; in other words, adding Quality into every stage of the lifecycle by finding issues as close to the point of injection as possible or avoiding them altogether.
2001? But that’s over 20 years ago!
A Secret Recipe for Software Success?
The move left has been surprisingly slow and traditional working practices seem responsible for much of the drag because they keep architects, developers and testers siloed away from each other.
It was not until agile working practices appeared that a new approach to development really began, but even then, after the initial discussions, developers and testers still worked in silos; their ways of working had become ingrained and difficult to change.
Collaborative practices were needed to break down the silos: Pair programming and mobbing alters team dynamics allowing more voices to be heard; testers can view code as it’s written and pose questions about how a scenario will be satisfied.
But that’s only part of the solution, keep reading to find out what else you need…
Test-Driven Development and why you should love it
TDD is slowly establishing itself as a best working practice for professionals: it is shown to produce leaner, focused code; create fast feedback loops; avoid pesky ‘rabbit holes’; write less bugs; provide living documentation and allow safe, effective refactoring.
It naturally drives a code base that meets the definition of the Software Testing Pyramid, with a strong bedrock of unit tests exercising logic, a layer of integration tests for where interfaces meet and a small, targeted, set of end-to-end UI-based tests that drive ‘happy path’ scenarios.
There is plenty more that could be said about the application of TDD; How many tests is enough? What level should tests be written at? How do you avoid coupling tests and code too closely? What about legacy code? But we will save that for another blog.
Here the key point is that by writing tests first you get software testers where they need to be — at the heart of the development team — enabling the team to Fail Fast. With TDD added to the mix you now have a team that is fully engaged and able to consider all aspects of producing enterprise-ready software out of the box.
Transformative — how?
Collaborative Test-Driven Development stops the waste of producing bug reports for issues that should have been found, or avoided, during development; instead, focus is on adding value to the project. After all, anyone can click buttons and tell you when software crashes, but experienced testers will find the subtle edge cases, consider user journeys, measure performance and add value that drives quality.
A typical day has the team discussing a story, defining scenarios, spotting pit falls and writing the code — tests first; this drives a testable architecture from the get-go and gets testers involved from the ground up. Once the developers are in full swing the testers can step away from the mob to consider other factors like release planning and specialist test scenarios, but always keeping one eye on how the code is progressing, watching out for missed scenarios and incorrect business logic. When the code is ready, the team test it together before passing onto a test environment where regression packs run and the testers can move straight on to other types of testing, because you have confidence that it works already.
Not sure if this is the right move for your organization? Let me share my own experience…
The proof is in the pudding
In recent years I’ve had the pleasure of working in a team that transitioned to collaborative working incorporating TDD within an Agile CI/CD framework, and in over 20 years this has made the biggest difference to how I perform my everyday job.
Switching to collaborative working requires adjustment, generally testers, scrum masters and architects are keen, but developers resistant: mobbing, with its driver/navigator setup and timed changeovers is intense and they have a real fear of being judged by their peers. You need to work to establish a safe space where everyone can contribute without fear of judgement; it will become a favoured working practice. Our unit test coverage on a new frontend ran at ~92% and coverage on legacy components increased significantly; releases became less risky and routine.
When the pandemic struck our team’s ability to work collaboratively turned out to be a godsend — every morning we started a virtual meeting and worked together throughout the day, adopting a looser structure to the mob with no timers or drivers. The collaboration maintained strong working relationships, stopped members from feeling isolated and increased productivity. An unexpected side-effect was that it improved communications with the client who previously felt distant from the main team since they alone joined meetings remotely.
Another way of assessing success was the reaction of the team themselves: everyone became a fan of working in this way, remarking how satisfying and supportive an environment it created. When the project came to an end the number one concern voiced was, would the next project be run the same way? People went into interviews asking questions about the adoption of practices like pairing, mobbing, scrum and Kanban, TDD and BDD. Do you write tests first? If not, why not?
Therefore, by effective application of Collaborative Test-Driven working practices, we finally have a means to action the Shift-Left for testing and access a big leap forward in software development methodology, to produce enterprise-ready products, with faster time to market, by driving Quality throughout the whole process.
What do you think? Still not on-board with Collaborative Test-Driven Development or convinced by the need to Shift-Left? Would you be open to having an initial consultation about introducing these practices at your workplace, as embraced by other customers?
Feel free to explore more at: version1.com/it-service/digital-services/test-as-a-service
About the Author:
Richard Dickinson has worked in software testing since the ’90s, just when the tester role was introduced into the industry. During his career, he has done a lot of TMMI assessments and Test Industrialization work in addition to handling test deliveries and implementing DevOps practices for complex engagement. But according to him, learning never stops …
