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.
Open-source testing tools like JMeter and Selenium have obvious appeal—no licensing fees, endless customisation, and a community to lean on. But, if you’re using open-source for mission-critical testing, you need to ask—is it really worth the risk?
Your testers find a critical bug the night before a major release. Should they have the power to stop the launch?
Testers provide essential insights into software quality and risk. Their analysis is critical for decision-makers, so would it make sense to give them the power to veto releases?
Would you intentionally plant defects to test your test team? Bebugging, as it’s known, is a technique where software flaws are purposely introduced to gauge testing effectiveness. Are there times and places where bebugging is a valid way to help improve processes, tighten up testing, or root out a potential weak link?
We have all witnessed an alarming rise in deceptive marketing practices that undermine customer decision-making and market integrity, with tool vendors increasingly comparing their tools to industry leaders using deliberately misleading information.
Is flaky automation better than no automation at all? Does it help accelerate projects and reduce timelines, or does it end up causing more problems than it solves? And are the questions moot when, with modern AI-powered tools, there’s no excuse for flaky tests?
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.
