How important are agile methodologies for Shift Left Testing? What are the benefits of Scrum in this path? Find out everything in this article by Gabriel Ledesma.

By Gabriel Ledesma

Is it possible to achieve the goals of Shift Left Testing with traditional methodologies in software engineering projects? First of all, I want to dwell for a moment on the concept of Shift Left, with the aim to achieve a thorough understanding of the subject.

As explained by Matías Fornara in this article, Shift Left Testing is the approach of expanding testing activities to the left of the development process, understanding it as a timeline. The etymology of this idea comes from the fact that in more traditional methodologies such as waterfall, quality activities are more “to the right”, i.e. at the end.

“The idea of Shift Left Testing is to include quality activities from the beginning, even from the planning of the functionalities, in order to mitigate risks and have a better quality analysis in each of the stages of this process,” Matías pointed out.

So, is it feasible to achieve these objectives with traditional methodologies? Projects can last months and sometimes years when using processes different from those proposed by today’s agile methodologies. 

Let’s imagine for a moment a 12-month project, with sequential and cascading phases. Here the iterations are made in terms of building software in phases, such as survey requirements, analyzing, designing, developing, testing, and putting it into production. As a result of this work philosophy, testing may not start to be performed until phase 8 or even later. 

In this framework, sometimes big bugs are found in advanced development phases, bugs that could have been easily avoided in earlier stages. The effect of this can be visualized without being an expert on the subject: an increase in the time required for the delivery of the product, with its consequent economic damages, dissatisfaction of the customer and also of the testing and development team due to the exhaustion that this situation can cause.

So, when a software engineering team changes this traditional way of developing technology for an agile one, a very important and radical change is generated. It implies the existence of a Shift Left Testing in fact. Why? The answer is straightforward: agile, and particularly Scrum, allows one to work in detail to achieve consistent delivery of incremental value, and thus mitigate a significant amount of risk.

To figure it out, a sprint, which is the name for iteration in the Scrum framework, should last less than a month. Usually, it lasts two weeks, during which the team must deliver usable, working software. To do this, in that time, the team needs to apply all the phases of building software, including testing. 

Scrum is a framework, and as such does not guarantee the result of the work. I emphasize this because I define myself today as an Agile Enabler: a person who promotes that teams and companies “be agile” rather than “use agile methods”. 

Scrum: Opportunities for Continuous Improvement

In my experience, I still see that there is a great opportunity for improvement in those projects where the Scrum framework is used, but the agile principles, and the right mindset, need to be put into practice. I will substantiate the above based on a concrete example. 

A team can use Scrum but stay in the method, i.e. in the events, artifacts, and roles. What does this imply? That when it has to generate work agreements in a self-organized way and focus on adding business value in each sprint, it works in a way in which the developers write code during most of the sprint, and only later, probably in the last days of the sprint, pass it to the testers, so that they are in charge of finding errors. 

This situation, in short, involves continuing to apply what has been developed in a sequential and cascading manner, but in a shorter period of time.

So: Scrum does not solve this? No. It absolutely does not. You need to build a team. Scrum does not recognize labels of any kind in the members of a Scrum team. Therefore, each of the team members must be responsible for building relationships of trust and then be accountable for the delivery of their work.

Scrum Does Not Solve It, But It Is a Great Support On This Path

There are no magic formulas, it requires professional maturity, putting into practice the 12 principles of the Agile Manifesto, and the 5 Scrum values: respect, commitment, openness, focus, and courage. 

“Scrum is linked from the analysis and inclusion of quality validations at each stage. Many times, this translates into the use of user stories with clear acceptance criteria that allow us to understand how a functionality or software increment should work and, therefore, how we should test it,” Matías Fornara outlined. “Another Scrum artifact that helps shift-left practices permeate is the Definition of Done (DoD), i.e., what a task has to accomplish to be considered ready by my team,” he continued.

I know many will be looking for recipes to achieve these goals, and while there is no one way to do it, sometimes they can help. One recipe I can give them is the following:

✔️Sprint Planning: 

This is the time when a Scrum team must understand what value it will deliver in the Sprint (Sprint Goal), what items in the Product Backlog are associated with that value, and how the team building the product is going to organize its work to achieve that Sprint Goal. 

With this in mind, the team must learn to design the construction strategy for each item, making an analogy with the elaboration of a cake or pie, instead of elaborating it by layers, must learn to do it by slices. Each slice needs to contain filling: top layer, bottom layer, etc. With this on the radar, the team will generate its work plan, called the Sprint Backlog.

✔️Daily Scrum:

Here there is an opportunity to identify if they are “building” that pie as they planned. If they are not, they should correct the plan, and be critical about whether they are generating “slices of cake” that can be delighted by any palate.

Some even more tactical aspects that can help teams put this into practice is to start designing the technical solution in pairs: a developer and a tester, each contributing their knowledge, as well as being able to employ concepts such as Test Driven Development (TDD), a design technique that involves starting development by writing the unit test first. 

You may be wondering if this is effective and efficient. I can assure you that yes, it is since it allows the generation of relationships between each member. That is why it is important to work in pairs. Before asking for efficiency from a team, it is necessary to build a team.

✔️Backlog Refinement:

Another activity that Scrum promotes in pursuit of bringing testing closer to the start of the build is called Backlog Refinement. It is not an event like Sprint Planning, the Scrum team organizes such activity thinking about how to partition the Product Backlog items so that in the next Sprint they are ready to be planned and actioned. 

In other words, they identify some slices of the pie that are too big and look for a strategy to leave them at a size that the palate can enjoy.

✔️Sprint Retrospective:

Finally, the team can focus the Sprint Retrospective on generating new working hypotheses, in consideration of moving toward “Shift Left Testing” or, what would be even better, “Shift Left Relationship” among the members of an engineering team, whatever their expertise.

Are you looking for your ideal software testing partner? Abstracta is one of the most trusted companies in software quality engineering. Contact us today to see how we can help your business!

What are the Responsibilities of a Software Tester? Figure it out in this article.

Follow us on Linkedin & Twitter to be part of our community!