With over 18 years of experience in the BFSI and retail sectors with specific focus on end-to-end delivery and managed test services, Kishan Sundar is in charge of Digital offerings at Maveric.

Through the imple­mentation of Dev OPS and Agile, en­gineering teams and product management teams collaborate and communicate intensely, mul­tiple times a day. Developers are merged into a testing cycle or test­ers are merged into the development cycle right from the early stages. With these changes in the role of a tester, the scope for Quality Assur­ance (QA) has broadened tremen­dously. Be it a software-developer-in-test (SDET) or a QA engineer, as a member of a collaborative team, a modern day’s tester now has a cadence similar to that of a soft­ware development engineer. These changes have brought in two major essential parameters which everyone should adopt:

Shift-Left Testing: Where test­ing is part and parcel of continuous integration (CI)

Shift-Right Testing: Where the horizon of testing is broadened after receiving feedback from the end-users Shift-Left has been the most pre­ferred word in testing parlance in the past decade and has enabled the evolution of quality assurance into something more than just testing. The concept of Shift-Left has been enabled to operate right from the requirements stage and increasing demand for services such as require­ments validation and requirements assurance, which establishes the stra­tegic role played by quality assurance in the IT industry. Adoption of Ag­ile, DevOps & CI/CD have further aided shift-left principles and it is a common understanding that testing cannot be limited to the end of the SDLC as was done in the past.

QA is actually defect prevention and not detection

However, quality assurance is still seen as the next step to development, which runs quite contrary to the pur­pose of QA being more about defect-prevention rather than defect detec­tion. Even in an Agile setup, we find that development and automation, despite their proximity, operate in silos and often imitate a fragmented waterfall operation mode. True de­fect prevention can be achieved only when QA starts left, not just by a left­ward shift.

Termed DevQA integration or Quality Assistance, this new model focuses on streamlining the devel­opment process itself and creating tools and environments that outline bugs or defects that can be avoided. In short, it is all about defect preven­tion.

The SDET will now be involved in the creation of:

• Unit tests and TDD (test driven development) scripts which will inte­grate with entire solution

• Stubs and services around the application in development

• Methods for synthetic data gen­eration through services/back-end automation

 • Definition of testing toolsets/ environments early in the lifecycle

Unlike the traditional notion of testing where QA specialists are ac­tive only after development, SDETs work in tandem with developers and understand the underlying code, thereby enabling testing at the unit level and extending it to the function­al level with acceptance and product performance testing.

Significant benefits of enhancing the role of SDET across the lifecycle will be evident only in the develop­ment and operations side of the life­cycle. The efficiencies gained during the development phase creates indi­rect, yet significant impact on the QA space.

Disruptions by Behavior-driven and Test-driven development (BDD and TDD): 

Developers often commence devel­opment with ambiguous test expec­tations since requirements tend to be loosely structured or unstructured at the beginning. The use of non-stand­ardized methods of defining require­ments, interdependencies, work­flows, business, and data rules often result in improper and incomplete impact assessment, leading to modifi­cations and changes after many stages of development, or during the first stage of testing.

The DevQA model disrupts the existing practice with the introduc­tion of BDD and TDD implemen­tation right from the requirements stage. Feature analysts are injected into the requirements phase to define BDD scripts from user stories and SDET is introduced in the develop­ment stage to define TDD scripts from BDD scripts.

The most significant benefit of a BDD+TDD approach is the overall reduction in cost of quality by:

• Structured and automatable script definitions from both require­ments/test design automation feed­ing into execution automation

• Early detection of defects in re­quirements and test

• Facilitating early UAT (user-ac­ceptance testing) due to elaboration of requirements at a granular level

Be it in an exclusively digital or legacy context, or in the more prev­alent digital front-end and legacy back-end model, DevQA integration will help increase efficiencies tre­mendously. As the entire process of validation starts left and plays a more strategic role by incorporating BDD when defining features, development in itself becomes more accurate, thereby setting the stage for effective defect prevention.

The subsequent BDD+TDD ap­proach for all subsequent stages, new initiatives, and enhancements, fur­ther strengthens the SDLC, and im­plementation by a skilled SDET with development capabilities, unit and functional testing, as well as perfor­mance testing, enables organizations to implement the ideal Agile setup that truly prevents errors.