Testers have long been asked to test earlier, faster, and more often. In truth, however, when critical APIs, integrations, or microservices aren’t ready, testing gets stuck. We’ve all been there, raring to go, like greyhounds in the slips… but with nothing to test, and increasingly concerned about the impending last-minute panic.
During the 2008 credit crunch, companies slashed technical investment. The mantra “do more with less” stuck—and 17 years later, testers are still paying the price as demands, complexity, and expectations have soared. It’s no coincidence that we’re witnessing an increasing number of high-profile software failures and cyber attacks. Yet, there’s still little willingness to invest in the right test tools and training.
Many small software teams turn to test automation, expecting substantial time and cost savings. However, they often fail to achieve any of these goals; instead of seeing a return on investment, they end up spending more effort and cost fixing their automation packs. This failure can leave lasting scars, deterring people from embracing automation and realising its many benefits…
I often speak to people who want to abandon legacy test tools and transition to shiny new solutions. They cite several reasons for the switch, many of which are valid, while others need greater consideration to avoid a negative or costly outcome. On the other hand, I also speak to people who are reluctant to ever change tools, even though they’d see incredible benefits.
Shift-left testing has become one of the most talked-about software development ideas. It sounds deceptively simple: test earlier in the process to avoid late surprises. But while the phrase is repeated at countless conferences and stand-ups, it is often misunderstood, misapplied, or reduced to a box-ticking activity (like many other testing initiatives).
The relentless obsession with ever-faster software delivery puts increased pressure on projects and teams, forcing them to adopt new processes and behaviours, but at what cost? The need for speed has transformed release frequency into a core metric, but is this relentless pursuit of speed undermining quality?
AI is everywhere. The software testing industry is flooded with buzzword-heavy solutions, and you’d be hard pressed to find a vendor that hasn’t marked at least one of their tools as AI-powered. But is AI another in a long list of cautionary tales, or does it genuinely herald a new era?
Read the marketing collateral from test automation vendors and you’ll encounter bold promises around costs, coverage, and defect reduction. However, for many who have been through multiple automation initiatives, the reality frequently fails to live up to the pitch.
You’re deep into a project, go-live is rapidly approaching, but there is a mountain of testing to get through. Then, a key stakeholder chimes in, “Let’s just pull more people into testing.” It sounds logical: bigger effort, higher quality. But doubling down on resources can easily lead to chaos, confusion, and worse software quality.
Are performance and security testing still treated as tick boxes to tag on to the end of a project when all the development is done? In my experience, neither performance nor security is taken seriously by enough companies.
Sign up to receive the latest, Software Testing Insights, news and to join the Calleo mailing list.
You can, of course, unsubscribe at any time!
By signing up you consent to receiving regular emails from Calleo with updates, tips and ideas on software testing along with the occasional promotion for software testing products. You can, of course, unsubscribe at any time. Click here for the privacy policy.
