Testing Is Now More About Defect Prevention Than Defect Detection
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 implementation of DevOPS and Agile, engineering teams and product management teams collaborate and communicate intensely, multiple times a day. Developers are merged into a testing cycle or testers are merged into the development cycle right from the early stages. With these changes in the role of a tester, the scope for Quality Assurance (QA) has broadened tremendously. 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 software development engineer. These changes have brought in two major essential parameters which everyone should adopt:
• Shift-Left Testing: Where testing 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 preferred 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 requirements validation and requirements assurance, which establishes the strategic role played by quality assurance in the IT industry. Adoption of Agile, DevOps and 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 purpose of QA being more about defect-prevention rather than defect detection. 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 defect prevention can be achieved only when QA starts left, not just by a leftward shift.
Termed DevQA integration or Quality Assistance,
this new model focuses on streamlining the development process itself and creating tools and environments that outline bugs or defects that can be avoided. In short, it is all about defect prevention.
DevQA integration advocates an enhanced model where the role of the SDET (Software Development Engineer in Test) moves beyond just creation and execution of unit tests.
The SDET will now be involved in the creation of:
• Unit tests and TDD (test driven development) scripts which will integrate with entire solution
• Stubs and services around the application in development
• Methods for synthetic data generation through services/back-end automation
• Definition of testing tool sets/environments early in the lifecycle
The efficiencies gained during the development phase creates indirect, yet significant impact on the QA space
Unlike the traditional notion of testing where QA specialists are active 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 functional level with acceptance and product performance testing.
Significant benefits of enhancing the role of SDET across the lifecycle will be evident only in the development and operations side of the lifecycle. The efficiencies gained during the development phase creates indirect, yet significant impact on the QA space.
Disruptions by Behavior-driven and Test-driven development (BDD and TDD):
Developers often commence development with ambiguous test expectations since requirements tend to be loosely structured or unstructured at the beginning. The use of non-standardized methods of defining requirements, interdependencies, workflows, business, and data rules often result in improper and incomplete impact assessment, leading to modifications and changes after many stages of development, or during the first stage of testing.
The DevQA model disrupts the existing practice with the introduction of BDD and TDD implementation 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 development 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 requirements/test design automation feeding into execution automation.
• Early detection of defects in requirements and test.
• Facilitating early UAT (user-acceptance testing) due to elaboration of requirements at a granular level.
Be it in an exclusively digital or legacy context, or in the more prevalent digital front-end and legacy back-end model, DevQA integration will help increase efficiencies tremendously. 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 approach for all subsequent stages, new initiatives, and enhancements, further strengthens the SDLC, and implementation by a skilled SDET with development capabilities, unit and functional testing, as well as performance testing, enables organizations to implement the ideal Agile setup that truly prevents errors.