Join Ashish Ghosh, Engineering Lead at ING, as he dives deep into the world of shift left testing, showing how you can accelerate delivery without sacrificing reliability.
In this insightful session, you’ll learn how isolation-first validation improves software stability and development speed, and how early, deterministic testing can become your safety net in today’s fast-moving AI-driven landscape.
[Secure your free spot now] (LinkedIn)
How can teams test early without risking that the results won’t match real-world conditions?
What is the key initial action a team should take to transition from UI-heavy testing toward a more effective shift-left strategy?
How should a team that primarily tests at the UI level begin their shift-left journey, and what’s the most important first step?
What are the most effective metrics and KPIs for tracking and evaluating the effectiveness of our early testing strategies in improving real-world software reliability?
What trade-offs have you seen between using ephemeral containerized environments versus shared staging environments?
What organizational or cultural changes are necessary to support developers taking on more testing responsibility, especially in companies with traditional, siloed QA departments?
For a team that currently does most of its testing at the UI/E2E level, what is the single most important first step to start shifting left effectively?
What’s your biggest challenge when testing early in the development cycle?
Can AI or automation help predict real-world reliability issues during early testing, and if so, what’s the current maturity level of these approaches?
How can testers optimize the balance between automated and manual testing efforts in early stages to maximize defect detection while maintaining coverage of complex, real-world scenarios?
Is TDD best practice or it might waste some time which could have been used in main development ?
How can ROI be quantified regarding investing in early testing activities, and how does this compare to the costs associated with defects found in later stages or in production?
How do you decide which tests should be executed early in the development cycle versus later?
How do you audit your AI testing tools? Should we be testing the testers?
What are the most effective metrics and KPIs for tracking and evaluating the effectiveness of our early testing strategies in improving real-world software reliability?
How to prevent snapshot-based resets from masking stateful bugs that only appear in production?
In the rush to test early, how do we stay grounded in real-world reliability?
Which metrics best indicate that early testing is effectively predicting real-world stability?
How can teams test early without risking that the results won’t match real-world conditions?
