The Importance of Testing
The importance of software testing is about the direct effect on customer experience, meeting high customer expectations on products and services.
Today’s customers are a demanding lot: always on, accessing content from a variety of devices, and yet expecting the highest in user experience. Anything less than exceptional response is grounds for unhappiness, perhaps even lost business. And, as competitors put a premium on user experience and selling to their installed base, pressure to deliver innovative technology with a great user experience will become a business constant. The importance of testing can't be overstated because of its direct impact on business outcomes. A poor user experience will ultimately lead to lost revenue.
Customers will continue to maintain high expectations in all of these areas:
- Service levels and reliability
- Correct, dependable function
- Ease of use
- Innovative features
Both developers and testers need to keep these standards in mind as they create or upgrade their products and services. Software product and service companies that fail to clearly and readily meet customer needs will be trampled by their competition.
This pursuit can be daunting since development teams must strive to match reality with customer expectations. For software development companies, this entails managing many constraints: competition, budget, schedule, human capital, continuous change, and quality goals. It’s no longer sufficient to merely deliver software, the delivery must fully match your customer expectations.
Test-driven product development and high customer expectations
Many software development groups are somewhat familiar with the concepts of test-driven development (TDD). In some regions, TDD is enjoying a recent boost in popularity, but the concept became viable over 15 years ago. Perhaps a major reason for the resurgence of TDD is that a number of larger companies embrace it as they also adopt DevOps and Agile practices. Another major factor is that most modern software teams are developing mobile apps, web apps, and microservices—all of which fit nicely with TDD. However, while there are many benefits, the most important reason companies adopt test-first/ test-driven development is that this is the only way to remain competitive in an intensively customer-centric world.
Fail early, by design
In test-driven development, tests are used as a method for designing software code. The test is built first, and then code is written and refined until it passes the test. Commonly, this is a 5-step, red-green-refactor procedure, in which red indicates a test failure and green a test pass. These are the 5 steps:
- Specify the test.
- Run the test and demonstrate that it fails (red).
- Write the smallest possible amount of code that satisfies the test specification.
- Run the test and evaluate to see if it passes (green).
- Refactor the code, if necessary.
Those who are entirely new to this concept may ask: Why seek a failure at the start?
The primary advantage of beginning with a failing first test is that it forces developers to be entirely transparent about where any defects might be. In many cases, the developer will see the defects very clearly—before any code is written. In this approach, developers are compelled to think more carefully, because they will need to anticipate, find, and fix defects in very tight feedback loop—instead of waiting days for a QA staff to give feedback from a conventional test regimen. Another benefit is that the developers can anticipate potential defects and fix actual defects while they are writing the code (for the first time).
Done properly, test-driven development forces developers to think about the viability of their code much further back in the development pipeline. The more resilient the code is against early testing, the easier it should be to automate the testing. Also, developers and testers will more quickly obtain the feedback that is necessary to increase delivery speed.
Test-driven teams find more time for innovation
Many developers complain that the test-driven approach diverts too much effort from writing code. The thinking is that developers should focus entirely on writing code and building features, not testing. But this largely misses the point, since the aim with TDD is to rebalance the development process to optimize how developers spend their time.
Typically, teams that consistently use test-driven development observe a decrease in the total time to get from the approval of a product requirement to the point at which it is releasable as well-functioning, defect-free software. Why is this? It’s because the team will spend some more time analyzing and specifying tests prior to coding, the team will save more time further along in the pipeline—with a shorter final QA stage.
Test-driven, test-priority development helps a team avoid what is lamentably all too common in software product/service development: a QA stabilization period that is much too long. But the additional time that your testers and developers invest earlier in the process will pay significant dividends after development is complete. The goal is to refine the test-driven approach so that the team minimizes rework.
Yes, TDD will initially decrease development momentum, as it learns how to specify tests and have developers code to those specifications. Ideally, after a few minor release cycles, the teams will begin to enjoy time savings when they realize—at code-complete—that there is hardly any QA work to be done.
Teams who integrate testing to the point that it becomes a symbiotic partnership throughout the development process will spend considerably less time on extraneous or unplanned work. Product teams that set quality as a top priority will eventually find more time for additional, value-producing features.
There will always be long-standing issues to fix. To the surprise of many managers, some development teams that have become successful at shifting QA leftward can devote as much as one-third of their time to developing new features that delight their customers even more.
Intensive focus on customer expectations
One of the most important benefits of pursuing test-first or test-driven development is the positive change in mindset—and the overall improvement to product development culture.
Customers expect you to deliver high quality products and services. If their expectations are not met, they will quickly seek the next best alternative. While innovation is important, quality is absolutely essential in satisfying your customers—so that they don’t even think about leaving for the competition. Quality products and services make an important contribution to long-term profitability and—together with feature innovations—will enable you to increase your prices in the future.
Maintaining a reputation for reliability
Quality influences your product and company reputation. The speed and importance of social media means that your customers—and prospective customers—can easily share both favorable reviews and and criticism of your product quality on forums, product review sites, and social networking sites. A strong reputation for quality can be an important differentiator in very competitive markets. In the extreme, poor quality or a product failure that results in a product recall campaign can create negative publicity and damage your reputation.
Reduce costs with a keen focus on quality
Lower quality actually increases costs. If you don’t have effective quality controls, your team is likely to spend extra effort to analyze defective products or services. You’ll consume more of your R&D budget to find root causes, fix defects, retest, and release again. In bad cases, it may be necessary to discard defective work products and incur additional costs for redesign and replacement. If customers receive your defective products, you’ll have to pay for returns and perhaps legal costs to compensate for failure to comply with industry or customer standards.
Cultivate a testing culture to provide the best levels of quality and service
Clearly, it’s worth the effort to reshape your testing culture so that developers deliberately seek to pass quality tests as early as practicable. Team members that master test-driven skills can mentor others. Each pairing—and every pull request—is one of many small feedback loops that help all contributors become adept at test-driven development—and pursue the highest possible quality products.
QA fully and directly affects the customer experience and, in some industries, is actually more important as a brand differentiator than price or features. Also, with increasing insight that comes with collecting more elaborate UX metrics, it’s becoming easier to measure the impact of quality enhancements on user engagement and experience.
Though it may seem daunting, test-driven development is actually quite achievable. Agile-based, TDD development can accommodate QA so that it continues to move further back in the product pipeline. By prioritizing QA, development teams can move rapidly while ensuring delivery of only the highest-quality products and services.
Business, development, and QA can no longer operate effectively in silos. In highly effective, test-driven teams, sales staff often participate in alpha testing, and QA staff are often given key roles during requirements definition. Such innovative rebalancing has become vital for delivering high quality, high availability, fully dependable products and services.
References:
https://techbeacon.com/why-you-need-test-first-development-meet-customer-expectations
https://www.accenture.com/gb-en/blogs/blogs-consumer-behaviour-importance-testing
https://www.tapqa.com/2016/11/11/the-importance-of-software-testers/
How much of your SLA focuses on reliability?
SLA – guaranteed reliability or an unnecessary expense?
https://www.3e.pl/en/cms/case-studies/sla-guaranteed-reliability-or-an-unnecessary-expense.html
What is an SLA? Best practices for service-level agreements
https://www.cio.com/article/2438284/outsourcing/outsourcing-sla-definitions-and-solutions.html
The Death of the SLA
https://www.cio.com/article/2883770/cloud-computing/the-death-of-the-sla.html
Why service level agreements are dead
https://www.cio.com/article/3064599/it-industry/why-service-level-agreements-are-dead.html
