A recent academic study has shed light on the elusive question many QA teams in banking and financial services often ask: why don’t developers always test? The research revealed that testing is not simply a matter of tools and protocols—but of deeply human, organizational, and contextual experiences.
Led by Rashina Hoda, Professor at Monash University in Australia, alongside researchers Mark Swillus and Andy Zaidman, the study explored the lived experience of 19 software developers from sectors including finance, software, and transport. Their findings offer practical insights into why testing is sometimes embraced, and often sidelined, in high-stakes software projects.
“We investigated the lived experience of software developers using the so-called Socio-Technical Grounded Theory,” explained Hoda. “We wanted to describe what is common to and true for various observers of the same phenomenon.”
Socio-Technical Grounded Theory (STGT) is a qualitative research methodology designed to explore complex, intertwined social and technical phenomena, particularly in fields like software engineering.
STGT helps researchers understand how people experience and navigate technical work environments, such as how developers decide whether or not to engage in software testing, or how teams adapt to new tools.
Context
What emerged is a picture of software testing as something deeply dependent on context. Developers do not decide to test based purely on mandates or tools, but according to a personal, often emotional calculus.
Testing decisions are shaped by factors such as the complexity of the system, the team’s development process, the availability of testing infrastructure, and how much safety or risk is perceived in the work at hand, Hoda pointed out.
Developers are also influenced by what others around them are doing, what is considered valuable within the team, and whether testing is viewed as a collaborative, respected effort—or merely a box-ticking exercise.
The study introduces three new conceptual tools to help make sense of this. The first is the idea of Testing Echoes: short-lived conversations, impulses or external influences like blog posts that encourage reflection about testing.
These can evolve into what the researchers call Testing Signatures: concrete testing artefacts such as test suites or post-mortem reports that carry the values and decisions of a team.
Whether echoes become signatures depends on a third factor: Testing Efficacy, or the developer’s sense of being able to make a meaningful contribution to testing efforts.
These three forces create a dynamic system. When developers have strong efficacy, are surrounded by helpful artefacts, and operate in an environment where testing ideas are shared and welcomed, testing tends to flourish. But when one or more of these elements is missing, when, for instance, the culture is indifferent, or infrastructure is weak, the momentum stalls.
One interviewee described how a catastrophic system failure became a turning point, saying, “At least me and all the others that made the Armageddon-bug now understand that it’s completely normal to spend 99% of the time on your pull request to test your code and 1% to add the code itself.”
Motivation to test
The study shows that the motivation to test is often rooted in such personal, memorable experiences. Developers recalled moments of failure, breakthrough, or learning that caused their views on testing to shift dramatically.
As Hoda noted: “We hypothesise that there is a social element in tester experience as well. The social context gives meaning to experiences and thereby influences this connection.”
While some developers described testing as an essential discipline, others viewed it as inefficient or even a burden—especially in environments with high complexity and low support.
Still, complexity itself can become a motivator. One developer remarked that when systems became too large to understand completely, testing was the only way to regain confidence in making changes.
Yet another noted how collaborative testing structures can reduce communication overhead in large teams, suggesting that the way testing is integrated into the team’s rhythm often matters more than the specific tools used.
For QA teams in financial services, where software quality, safety, and compliance are paramount, the implications are clear. Simply introducing testing tools or mandating coverage targets may not be enough. Developers need to feel that their testing work matters, that it is seen, and that it contributes meaningfully to the goals of the team.
Creating environments where testing echoes can be heard and transformed into lasting signatures requires deliberate investment in culture, conversation, and context, not just infrastructure.
The study reminds us that software testing is not just a mechanical process, but an ongoing negotiation between people, tools, and organizational expectations. As one participant put it: “I learned all this testing stuff at university [and] never really do it… Time to change.”
For financial institutions that rely on resilient, secure, and high-integrity systems, embracing the human side of testing may be just as important as the technical one.
NEW EVENT
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
REGULATION & COMPLIANCE
Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.
READ MORE
- Inside JPMorgan’s $18bn QA push with OmniAI reshaping testing
- As AI takes hold, insurance firms face a new testing mandate
- K2view’s Amitai Richman calls out the ‘real bottleneck’ in healthcare and insurance
- AI in QA: how flexible testing is redefining assurance for financial firms
- Explainer: Why site reliability engineering is gaining momentum in banking
WATCH NOW
