A reinsurance calculation can be wrong without causing a system to crash. A payment service can return a technically successful response without completing the intended transaction. An online order can appear confirmed while leaving an important downstream process unfinished.
These are different failures, but they expose the same challenge: establishing that software runs is not the same as establishing that it delivers the correct outcome.
Chandrakanta Ghadei, a Senior Software Development Engineer in Test, has built his career around this distinction between software that runs and software that delivers the right business outcome. His experience across reinsurance, payments, e-commerce, education technology and operational platforms demonstrates why quality engineering must be designed around business risks, rather than treated as a collection of standard test scripts.
Over approximately six and a half years in information technology, Ghadei has progressed from software quality assurance and automation engineering to senior SDET responsibilities, framework architecture and independent engineering-tool development. His technical experience includes Selenium, Playwright, Cypress, Appium, Rest Assured, Java, TypeScript and JavaScript, as well as web, mobile and API automation and CI/CD integration.
His professional experience has required him to apply these technologies across distinctly different business environments.
During nearly two years with EPAM Systems on Swiss Re engagements, Ghadei worked on applications supporting reinsurance costing and calculations. In reinsurance pricing, actuaries use estimates of expected claims and risk to inform pricing decisions, making the reliability of the supporting software important. His quality-engineering work focused on validating calculations, data integrity and business rules, not merely checking that a screen loaded or an API returned successfully. The problem being addressed was the possibility of software producing a technically valid but incorrect result that could affect subsequent analysis and decisions.
His subsequent work in the Mastercard payments environment introduced another transaction-sensitive domain. Although payment platforms involve different workflows, the underlying engineering responsibility remains similar: automated checks must reflect the business outcome, not merely the technical response produced by the system.
Earlier assignments included waste-management software at Cigniti Technologies, customer-facing e-commerce systems at Ferns N Petals and education technology initiatives serving school learners across different subjects and languages. Each environment required a different understanding of users, integrations, operational dependencies and potential points of failure.
This breadth becomes valuable when it influences engineering decisions. An automation framework may be reusable, but a testing strategy cannot simply be copied from one industry to another without reconsidering the risks of the product.
Ghadei’s responsibilities have extended beyond executing predefined test cases. His work has included automation strategy, test-framework structure, regression planning, test coverage, defect management, release readiness and the integration of automated checks into continuous delivery pipelines.
These are architectural decisions as much as testing tasks. How tests are organised affects their maintainability. Where they run determines how quickly development teams receive feedback. What an assertion examines determines whether a passing result provides meaningful confidence in the product.
That practical experience led Ghadei to independently develop a multi-framework automation code-generation tool. The completed tool captures browser interactions and translates a recorded workflow into reusable Selenium, Playwright or Cypress automation code in their supported programming languages. It was designed to reduce the repetitive effort involved in drafting locators, interaction commands and the initial structure of browser-automation tests.
The objective is not simply to produce a greater volume of code. By reducing repetitive scripting work, Ghadei wants quality engineers to devote more attention to scenario design, business validation, risk assessment and meaningful test coverage.
The distinction is important. Recording a successful checkout journey does not determine what should happen when a payment is declined, an order is interrupted or information becomes inconsistent between connected systems. Those possibilities still require engineering judgement.
Having completed the core multi-framework capability, Ghadei is now working on expanding the tool with AI-assisted features. This next stage is focused on helping engineers generate and refine automation structures more intelligently while retaining human control over test scenarios, assertions, business validation and risk assessment. The value of this direction lies not simply in generating code faster, but in reducing repetitive work while supporting automation that remains useful, reviewable and maintainable as applications evolve.
One area of this development involves using structured API information, including Postman definitions, to assist in generating Rest Assured automation structures. While the existing browser tool begins with recorded user interactions, this AI-assisted work begins with information about API requests, responses and service behaviour.
Both capabilities share a common purpose: reducing the effort required to create an initial automation structure while keeping engineers responsible for the decisions that determine whether a test is meaningful.
An API definition can explain how to send a request without establishing all the business conditions under which its response should be accepted. An example response can demonstrate the expected data format without confirming that every returned value is correct. Generating more assertions does not automatically close that gap.
Ghadei’s approach therefore treats artificial intelligence as an engineering aid rather than a substitute for technical judgement. AI may assist with code generation and framework scaffolding, but engineers must still determine what should be tested, which failures carry the greatest consequences and whether the results provide sufficient confidence for release.
This direction reflects a wider change within software development. AI-assisted coding is helping teams create and modify software faster, but faster development also creates pressure for quicker and more reliable validation. Quality engineering must consequently move from being a final testing phase to becoming an integrated capability operating throughout the development lifecycle.
Ghadei’s professional progression reflects that shift: from quality assurance to automation engineering, from automation engineering to framework architecture, and from framework architecture towards engineering-tool development and AI-assisted quality systems.
The real opportunity is not automation for its own sake. It is the possibility of shortening feedback cycles, reducing repetitive engineering effort and helping teams make better-informed release decisions without weakening scrutiny of business-critical behaviour.
Ghadei began his career in mechanical quality engineering within the automotive industry. That experience introduced him to defect prevention, process control, root-cause analysis and structured quality standards before he transitioned into software engineering.
Manufacturing quality and software quality operate in different environments, but they share a fundamental objective: understanding how failures occur and preventing them before they affect the final product or its users.
As digital systems become more interconnected, engineers who can combine automation architecture with business-risk awareness and the responsible use of AI will become increasingly important. Ghadei’s work offers a practical example of how that combination is beginning to take shape.
