Performing testing in an Agile context require a completely different approach to software testing activities that is often named “Shift Left”. This term emphasize the move of software quality activities to the beginning of the software development life cycle. In this article, Kishan Sundar shares his perspective about the consequences for Scrum teams of shifting left software testing in Agile.
Author: Kishan Sundar, Maveric Systems, http://maveric-systems.com/
In the digital world, constant innovation and upkeep is a day-to-day activity or a routine rather than a scheduled maintenance activity that disrupts the said routine. Innovation has been embraced and fueled by end-user expectations and every consumer is constantly seeking more from a bank, an online shopping website or even the internet provider’s complaints portal. With technologists constantly striving to enhance and better the experience for the demanding customers, the whole world has to grapple with incessant operation systems and device upgrades, feature enhancement and a number of other changes that might require a complete or at least partial overhaul of existing systems every month.
To keep up with these whirling changes, businesses globally adopted Agile. Agile is an approach that involves development of a software in an incremental fashion, where one complete feature is developed in what is called a sprint, with testing being done within every sprint, and subsequent sprints being built on its foundation.
Doing things the Agile way offers quick releases, enables defect prevention and most importantly, makes room for reassessment and subsequent realignment of plans. With this approach, a complete feature can be built at a time, with development and testing happening simultaneously and complementarily. This shift in paradigm, often termed as “Shift Left”, has change the perspective and scope of assurance to the very beginning of the software development life cycle (SDLC). Companies and service providers have released that every penny spent on technology adoption has to add up to a tangible business benefit and since it is assurance that provides this validation, testing now starts even before development activities.
Image Traditional Shift Left. Source: https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html
In the Agile environment, testing plays an important role right from the requirements stage. It plays a role in validating the viability and feasibility of every feature that will form a part of the application. And most often, companies want to start testing with a sample user audience who will validate the use case of the feature which is getting built into an application or as it is known in Agile, an epic user story. Testers will start validating the epic to ensure it is complete and covers one whole feature. With the epic, they work with the development team to break it down into sub-user stories or user stories and also estimate how much time is needed to do both development and testing and write an acceptance test case even before it goes for development. This type of development that is driven by testing is known as Acceptance Test Driven Development or ATDD.
As evident, the interaction of assurance specialists with other stakeholders also increases drastically in an Agile testing environment. The scenario, as in the past, where the tester would work only with the project/program manager has changed and now, it is imperative that they interact with all the stakeholders in the program. The Agile model, with its comprehensive testing and quick release objective, requires assurance specialists to be involved everywhere:
- Given that testing begins early with a sample audience well ahead of release, testers are called in for field testing wherein they interact with the customer or product owner, understand the type of application they are looking for and how they feel when using the app. These will also determine the satisfaction conditions towards that the development and other teams will work towards.
- Since Agile Testing works in the Shift Left mode, there will also be initial interaction with Epic owners and enterprise architect on how the application will be rolled out, and details regarding the devices, operating systems, and browsers that need to be supported.
- There is considerable interaction with program management units to determine timelines, whether the release will be monthly in nature, how will regression cycles be completed and regarding the sign-off of test activities.
- With regard to day-to-day activities, assurance will be part of the Agile team rather than outside the Development Team. Today testers are known as test developers much like code developers. While the code developers write the code for functionality, test developers script the automation test cases using ATDD.
So what does the typical engineering team look like in an Agile environment? An Agile team in the digital or mobile space, often work with 3-4 sprint teams if not a full stack developer. And the sprint teams are usually organized into Services Sprint Team (Consisting of 5 developers to 1 Tester called Test Developer in charge of unit testing and complete automation of services using Soap UI, Fiddler or J Unit), Web Sprint Team (5 developers to 2 testers with functional and technical knowledge who undertake automation during the sprint and exploratory testing during the hardening phase), 2 native development teams – iOS team (working in the same ratio as web sprint) and Android team with a much thicker test population due to device diversity (while 2 developers for a tester is the recommended ratio, it is usually higher, often consisting of 5 developers to 3 testers and a fourth tester engaged in device and operating system coverage testing).
Given this rapidly changing technology landscape, it is essential that companies and service providers bridge the skill gaps in their work force to enable efficient implementation of such an iterative style of operations. Assurance specialists need to be techno-functional experts, who have domain expertise as well as technology competency on automating the test cases using any of the open source automation tools like Appium, Selenium or a proprietary tool like UFT, Perfecto, etc.
Without the conventional milestones and KPIs to evaluate performance and achievement by an individual or a team on a given project, Agile Scrum and its iterative nature offers multiple evaluation points such as sprint planning, review, retrospective, standup meetings, etc. so that the team members can evaluate their progress, inspect their work, make changes if needed and adapt accordingly.
About the Author
Kishan Sundar is Vice President, Delivery Leadership, at Maveric Systems. He has over 18 years of experience in the BFSI and retail sectors with specific focus on end-to-end delivery, managed test services. At Maveric, he spearheads digital design thinking, strategize customer experience testing frameworks and manage Maveric continuous assurance solution.
Good Post, ATDD scripts by test developers would need a good framework and reusable functions/methods which can help test team to focus on functional aspects then thinking on the logic for developing the code. As sometimes test team might deviate and concentrate on writing the automation scripts and leave all the functionality, so process should be there where after sprint planning test team develop the Quality Scenarios and then develop the test code using that..