Are you embracing test-driven development (TDD)? The worst thing that could happen to an organization is releasing a poor-quality product. Adding insult to injury is knowing that it could’ve been avoided with better testing. Implementing an early and often testing framework—otherwise known as shifting left— now can help you avoid pain later.
Raise your hand if you’ve ever been stuck in a game of deployment ping-pong. Maybe it went a little something like this: The development team passed a feature up the chain, QA found an issue and passed it back, a dev fixed the feature and sent it back, QA found something else—on and on. Keep your hand up if you’ve missed a release target because of poor test cases or if you spend just as much time on feature updates as you do on updating your test suite.
If your shoulder is starting to hurt, you need to change the way you approach testing. Enter a better paradigm: Early and often testing. It’s exactly what it sounds like, testing as early and frequently as possible. Instead of the traditional build now, test later, we consider testing as a scalable, long-term strategy, ever-present alongside development.
What is Test-Driven Development?
Early and often testing are tenants of Test-Driven Development. TDD is a development process that relies on requirements being converted to test cases before development. It is a paradigm shift from feature-based development, which starts with—as you’d expect—feature development, and then figures out how to test it later.
With TDD, the test is developed first, followed by the simplest implementation to pass the test, then both the test and software are refactored and developed in tandem. The main point here is that development is constrained to only include the code necessary to pass the test. Want more features? Write more test classes.
By the numbers: TDD, step-by-step
Here’s a step-by-step breakdown of TDD:
- Write a test: First, write a test. Developers are now constrained to features necessary to pass the test.
- Run tests: Run your test cases. The tests will fail. Why? Because there is no feature code yet!
- Write simple code that passes the test: The code will be refined later. The point is to keep feature development constrained to the test class.
- Run tests again: The tests should pass now. If any test fails, the feature code is revised until it passes.
- Refactor and repeat: Expand test cases before changing feature code and repeat.
Considerations
Most criticism surrounding TDD revolves around the time commitment and increase in cost that it involves. While it’s true that test-driven development takes careful planning and incurs more upfront cost, early and often testing can save time later in the deployment phase and reduce overall cost.
A 2011 cost analysis published by the Journal of Information Technology Management (“Engaging Testers Early and throughout the Software Development Process: Six Models and a Simulation”, Mark Gilleson, et al., 2007) identified that errors found in later stages of the development lifecycle were exponentially more expensive than had they been discovered earlier – in fact, about 10 times more expensive.
For example, an issue that takes about $10 to fix if found in the development phase will take:
- $100 to fix after it’s been deployed to QA
- $1,000 to fix if it’s discovered during integration testing
- $10,000 to fix if discovered during the production
For most organizations, the move to test-driven development would be a massive shift. Luckily, you don’t have to adopt TDD entirely to benefit from its principles.
Processes
Testing early and often involves:
Testing as changes are made
The usual way is developing, sending up the chain to QA, QA finds bugs, sends it back to Development, who fixes them and passes it back to QA who finds bugs, etc. We can continue this endless ping-pong game of bug finding or include testing during development. There are great Continuous Integration tools (CI) that can be configured to run automated test cases as changes are identified. Tests can be scheduled to run before deployments, after deployments, or daily. By testing continuously, developers can fix issues before they’re moved up the chain.If you are developing mobile applications, tools like Sofy, a no-code testing platform, integrate with CI tools to run the entire mobile test suite. Sofy also uses machine learning to recommend test cases where gaps are found and suggests changes to existing test automation when it senses conflicts due to new code releases.
Testing on multiple devices
Your users expect a great experience on whatever device they use. A good test strategy considers those devices. The earlier you think about testing, the sooner test cases with multiple devices will be introduced. Considering how much time can be spent optimizing test cases to run across different devices, it makes sense to approach with a consistent framework or set of tools. With Sofy, you can grab a real device, perform a manual test and create elegant test automation. Then you can run it across all devices.
Running tests at more stages of the deployment lifecycle
You don’t have to wait for a specific environment before testing. Start with the test in mind and build a resilient environment from the beginning. This is much easier to do when testing and development teams are aligned. Test-Driven Development is a methodology that builds tests from requirements, sometimes concurrently, or even before development is finished. The methodology encourages design simplicity, facilitates an early collaboration between test and development teams, and most importantly, results in a better product.
Thinking long-term
Testing early and often forces long-term thinking around test strategy. How do I test this and how do I continue testing as our stack grows are important questions that should be asked with every development. Long-term thinking also implores us to consider the tooling needed to support our testing goals. Without long-term thinking, organizations end up with a collection of poorly adopted and implemented tools that patch, rather than address real testing gaps.
Testing is easier than ever
Today, the no-code revolution is empowering organizations to do much more with much less. More features, fewer developers, more releases, less bureaucracy, and more impact in less time.
It can be tempting to let testing take a back seat as development accelerates but we know how that ends. By thinking strategically about your test strategy, implementing an early and often framework, and choosing the right tools, testing can be your biggest ally in releasing great features.
Disclaimer: The views and opinions expressed above are those of the contributor and do not necessarily represent or reflect the official beliefs or positions of Sofy.
