Originally published in DataQuest (A CyberMedia Publication).
This interview is republished here with full credit to the original source.
In this interview with DataQuest, Shrish Ashtaputre, Senior Technical Director – Engineering at Calsoft, shares insights on how Quality Engineering has evolved in response to AI-driven systems, cloud-native architectures, and growing security and regulatory demands. He discusses the shift toward preventive, adversarial testing mindsets, the role of intelligent automation, and how QA is increasingly embedded across the software lifecycle.
The interview below is reproduced verbatim, without modification, from its original publication.
What has changed about QA in the last 4-5 years and how proactive, shift-left, AI-ready, AI-driven and security-sharp is this frontier becoming?
Answer:
QA used to come in at the end, checking if things worked. Now it’s part of how things are built in the first place — driving quality decisions instead of just verifying them. We’ve seen the rise in shift-left testing, AI-assisted quality engineering, and security-integrated validation. Test engineers are now expected to understand pipelines, cloud-native architectures, and even prompt engineering for AI tools. The mindset has become more preventive than detective.
AI has become part of QA’s toolkit, helping predict weak spots and optimize testing. At the same time, QA must validate the integrity and fairness of AI systems — making it both a user and a guardian of AI.
Also Read: Green buildings and their benefits for IT companies
Are QA and testing blurring their boundaries with Development- specially in the early phases of application-builds? What is changing here with DevOps and SecOps?
Answer:
Those boundaries are dissolving, and that’s a good thing. With DevOps, QA became embedded into the pipeline — automated test execution, environment provisioning, and feedback loops are all part of CI/CD now. With SecOps, we’re adding security scans and penetration checks earlier, creating a DevTestSecOps model.
QA is no longer a separate stage. It’s a mindset that exists throughout the lifecycle — from requirements to observability in production.
Is automation a good change in QA? What about jail-breaking concerns here?
Answer:
Automation is both a necessity and a responsibility. It accelerates validation cycles, eliminates repetitive work, and allows engineers to focus on exploratory and edge-case testing. However, blind automation is dangerous. With AI-based testing, “jailbreaking” or prompt manipulation risks can creep in — especially when validating generative systems.
The right approach is controlled automation — where humans design intent, and automation executes within guardrails. In QA, automation should assist judgment, not replace it.
What is/should be changing with red teams, blue teams and purple teams in software lifecycle?
Answer:
These team models, traditionally from cybersecurity, are now influencing mainstream QA. Red teams (attackers) simulate adversarial behavior; blue teams (defenders) improve detection; purple teams bridge the two.
We’re seeing QA functions adopt a similar pattern: offensive testing, defensive hardening, and collaborative resilience. Especially in cloud-native environments, QA engineers must think like adversaries to ensure security, scalability, and performance from day one.
Vibe coding, low-code and no-code tools, AI tools- do they help QA or slow/complicate it? Anything you can share about edge cases and QA?
Answer:
These tools are democratizing development — but they also complicate QA in interesting ways. Low-code and AI-assisted environments create abstraction layers that obscure the underlying logic. QA teams need new testing models that can handle intent validation instead of line-by-line verification.
Edge cases become trickier. For instance, an AI tool might auto-generate UI flows that behave inconsistently across browsers or devices. The key is adapting QA strategies to validate behavior, not just code.
What new implications have been observed in areas like regression testing, SDET, API testing etc.
Answer:
Regression testing has become AI-augmented and data-driven. Instead of re-running all test cases, systems now prioritize based on change impact analysis.
The SDET role is also evolving — they now bridge coding, observability, and automation frameworks, often owning quality gates within CI/CD.
In API testing, the focus has moved beyond correctness to contract validation, resilience testing, and chaos validation — especially with distributed and microservices-based systems.
Has skeuomorphism changed QA goals also?
Answer:
Interesting question. Skeuomorphism — the design principle of mimicking real-world elements — may seem like a UI concern, but it indirectly impacts QA goals. Testing now needs to validate user perception and trust, not just functional accuracy. When software behaves in familiar yet abstract ways, QA ensures that cognitive expectations match real outcomes.
So yes, skeuomorphism has subtly shifted QA from “it works” to “it feels right”.
Have security and performance/SDLC time in software come closer or are they still conflicting goals?
Answer:
They used to conflict, but modern architectures and tooling have brought them closer. Security checks are now embedded as automated gates within pipelines. Performance testing, too, is moving earlier — with synthetic monitoring and API-level load simulations.
In effect, security and speed can coexist, provided teams integrate validation rather than treat it as an afterthought.
What has been evolving at your company and its solutions after the advent of AI- have customer expectations and investments changed?
Answer:
AI has definitely shifted how we look at quality engineering. At Calsoft, a lot of our recent work has been about moving from traditional automation to intelligent automation, especially with platforms like CalTIA, our AI-assisted testing accelerator. It helps teams analyze change impact, prioritize the right test paths, and reduce the time spent on repetitive regression cycles.
What we’re seeing on the customer side is a clear shift in expectations. Earlier, the ask was faster releases. Now the conversation is around continuous validation, risk prediction, and how QA can keep up with highly dynamic, AI-enabled systems. Customers are also investing more in tooling that can adapt to frequent changes — not just execute scripts.
So yes, expectations and investments have evolved. AI is pushing QA to become more analytical, more data-driven, and much closer to development and operations than before.
Any thoughts on how regulatory changes related to data privacy - like (India's DPDP), EU's regulations and MeiTy's new strides - will improve or complicate privacy focus on the side of application-makers and IT companies?
Answer:
Privacy is no longer a compliance checkbox — it’s a design principle. With India’s DPDP and EU’s tightening frameworks, QA now includes data lineage validation, consent enforcement, and anonymization testing.
Regulations are forcing better discipline, but they also complicate global rollouts. Every geography now has its own flavor of privacy law, which means QA must validate behavior across multiple legal contexts.
In the long run, though, this will lead to privacy-by-default architectures, which is a win for both users and engineers.
