How To Increase Software Quality, Reduce Cost and Get The Most Out of Your Testers
By: Richard Dickinson for Version 1
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 a well-established principle of software test methodology that the earlier you found a bug in the development life cycle, the cheaper it was 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
The IT Industry was following the waterfall model for software development where the Testing Phase is to the extreme right of the software development lifecycle:
Requirements => Design => Coding => Testing
This means that by the time issues are found they already have elevated material impact on budget and timeline — either through release delays, or for serious design flaws, having to scrap the software and start again.
This realization and the big lessons learned gave birth to a new concept 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.
Shift-Left Testing: A Secret Recipe for Software Success
However, this move left has been surprisingly slow with traditional working practices being 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 more collaborative approach to development really began, but even then, after the initial discussions, developers still developed, and the testers still tested in silos — as the ways of working had become ingrained and were difficult to change.
Collaborative practices were needed to break down these silos and bring developers and testers together: Pair programming and mobbing, including testers, alters the team dynamic allowing more voices to be heard (product owners are essential in mobs too); testers can view code as it’s written and pose questions about how a scenario will be met by the logic being written.
Here, the principle of ‘Shift left’ supports the Testing team to collaborate with all stakeholders as early in the development phase as possible. This approach works based on the agile manifesto which has several advantages:
· Individuals and interactions over processes and tools.
· Working software over comprehensive documentation.
· Customer collaboration over contract negotiation.
· Responding to change over following a plan.
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
How often have teams you worked with been confronted with legacy code where you want to make changes but don’t dare? Or do dare, but then introduce production bugs?
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 fewer bugs; provide living documentation and allow safe effective refactoring.
Once TDD is added to the mix you have a team of people fully engaged and able to consider all aspects of producing enterprise-ready software out of the box.
There is plenty more that could be said about the application of TDD; How many tests are 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 day.
Transformative — how?
Collaborative Test-Driven Development gets software testers where they need to be — at the heart of the development team — where they can clearly understand the requirements and design the test cases to ‘Fail Fast’ enabling fixes at the earliest opportunity.
It stops time from being consumed by producing endless bug reports for issues that should have been found and fixed, or avoided altogether, during development and then re-testing the fixes; instead, the focus is on adding value to the project. After all, anyone can click buttons and tell you where software crashes, but experienced testers will find the subtle edge cases, consider improving user journeys and add value that drives quality.
A typical working day involves the team discussing a story, defining scenarios, spotting pitfalls and writing the code — tests first. This drives the architecture to be testable from the get-go and gets testers involved from the ground up because the test scenarios are considered first. Once the developers are in full swing the testers can step away from the mob and 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 it onto a UAT environment where automated regression packs run and the testers can move straight on to other types of testing, because they know it works already.
It naturally drives the creation of a code base that meets the ideal 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 finally, a small, targeted, set of end-to-end UI-based tests that drive ‘happy path’ scenarios.
Not sure if it is the right move for your organization? Let me share my own experience around this paradigm shift in quality….
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 and BDD within an Agile CI/CD framework and in over 20 years this has made the biggest difference to how I perform my everyday job.
When the team first switched to collaborative working it was quite hard to make the adjustment, generally the testers, scrum masters and architects were quite keen, and the developers were quite resistant. Full mobbing with the whole driver/navigator setup and timed changeovers was intense and the developers had a real fear of being judged by their peers. In fact, the team dropped it, and then returned to it a few months later after building up to it with more pairing practice. Over time they relaxed, and a safe space was established in which everyone could contribute, ask questions and for explanations without fear of judgement and it became a favoured working practice.
Then the pandemic struck, and we all started working remotely full-time. Here our ability to work collaboratively as a team turned out to be a godsend — every morning we started a Virtual meeting and worked together throughout the day. We adopted a looser structure to the mob with no timers or drivers and took it in turns as we felt like it. The collaboration maintained strong working relationships, stopped members from feeling isolated and increased productivity. Another unexpected side-effect was that it improved communications with the client who had previously felt left out to an extent as they were remote from the main scrum team and had to join meetings remotely.
One way of assessing the success of this in our teams is the reaction of the members themselves: everyone over time became a fan of working in this way and remarked on how satisfying and supportive an environment it created. When the project came to an end and the team broke up the number one concern voiced was would the next project be run the same way — people were going into interviews and discussions with prospective employers and managers and asking questions about their adoption of practices like pairing, mobbing, scrum and Kanban, TDD and BDD, do you write tests first? And asking, if not, why not?
Hence, we finally have a means to action Shift Left for testing and so, 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? Would you be open to having an initial consultation about introducing these practices at your workplace, as embraced by other prestigious customers?
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 in 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 …
