Discover what Shift-Left Testing is
Tips on how to use this approach in everyday life
A traditional software development process is sequential, where one phase needs to end to start another. Typically, the phases would be: Requirements Analysis, Software Architecture, Development, Testing and Deployment. That is, the entire testing effort is expected to happen only at the end of the process. For this reason, the tests are “on the right” in the process, as seen in the image below.
When the software development process is seen as a sequential, left-to-right process, anticipating testing activities can be seen as “shifting these activities to the left”.
Shift-Left Testing means moving the beginning of the test phase to the left, which means: instead of testing occurring only in the final stages, testing activities start to occur earlier, and last throughout the lifecycle.
The image below illustrates the attention given to quality in both the Shift-Left model and the traditional model.
You must be wondering: “wow, but I already do that!”
Really? If your team uses agile methodology it doesn’t necessarily mean that you test early. Having an “ In Test ” column on your agile board doesn’t mean testing is being done early. If testing activities are postponed after a task is developed, then you are testing late, too close to delivery. There’s nothing Shift-Left about it.
Have you found defects that could have been avoided if the functionality description were clearer, and the acceptance criteria better detailed? If you had acted from the beginning, you would have noticed these gaps.
This does not mean that it is enough to have QA participating in backlog refinement to “be Shift-Left ”. There are numerous activities that the QA can anticipate. Get involved with architecture decisions, choice of tools and frameworks, risk assessment, negotiations with the client, alignment of expectations about what quality is for the client and for the user, configuration of test tools, work on the definition of done, among others. Carry out these activities using your critical sense and knowledge of good practices in favor of quality.
Why adopt this practice?
One of the reasons is that bugs will be identified earlier, therefore, they will be easier and cheaper to correct, according to Myers’ Rule 10 in his book “The Art of Software Testing ”, in 1979. Forty-two years have passed, and what changed? We were able to learn from Software Engineering and agile methodologies, which gained strength over the years, and brought practices and principles that benefit the Shift-Left approach and thus, we have the opportunity to apply what Myers preached in his book.
Also, it is easier for a developer to work with code that is fresh in his mind, so the problem will be solved faster. Problems discovered by tests at an advanced stage can cause delays and even failure of projects.
Searching for quality is not just finding inconsistencies, but mainly planning and executing strategies to prevent them and, if they exist, finding them as soon as possible . For these reasons, the Shift-Left approach must be in the soul of every team!
Agile methodologies strengthen the Shift-Left Testing approach
One of the explicit goals of the agile manifesto is the focus on delivering software with quality and added value. To get benefit from the agile methodology, teams must follow practices and principles throughout the software lifecycle. Quality culture is one of these principles .
The Shift-Left approach can and should be part of the quality culture of an agile team.
The QA becomes a protagonist in the dissemination and structuring of this culture. This protagonism comes from his responsibility to engage the team in the practice of the quality strategy that was defined. The QA must act in such a way that it is clear that the responsibility for quality rests with the entire team, not just the QA.
Each individual becomes a quality representative . Therefore, everyone need to acquire the mindset of those who test, the mindset of those who analyze risks and seek quality for the product.
The role of the QAs is so important that the ideal would be for them to participate in all the decisions that are made. Unfortunately, it is common for teams to have only one QA, as shown by research by Júlio de Lima on team configuration. Therefore, the presence of the QA at these teams is not feasible. This is where the quality culture comes in and makes it possible to engage the mindset of the QA, represented by the developer or any other role. When adopting the Shift-Left, the QA must be concerned with transmitting to the team what this implies in PRACTICE, what changes and what the team has to gain from adhering to this mentality of anticipating testing activities.
How Does Agility Contribute to Shift-Left Testing?
By adopting agile methodologies, it becomes even easier to disseminate this culture, mainly for the following reasons:
- Agility involves fast and frequent feedback: have CI/CD, code review, identify risks from the beginning of development, use of linters and static analysis during development, daily meetings;
- More collaboration and less isolation: QAs and developers should work together, on the same team, and from the beginning, instead of forming isolated groups. Another option is to adopt pairing;
- Customer involvement: the customer is close by giving feedback and validating deliverables. Such proximity helps the team to understand its real needs, and to be more questioning and to identify the value of delivering each sprint;
- TDD: is one of the pillars of Kent Beck’s Extreme Programming (XP), which proposes that development be done together with testing;
- Coding standards: it is also suggested by XP. Adopt strategies that encourage the use of a single coding standard for the entire team. Coding standards keep code consistent and easy to understand and maintain. This will decrease the number of bugs as these standards prevent bad or insecure code.
Kick Off supports the Shift-Left Testing approach
The Kick Off happens when the developer are ready to start a new card (user story, task or technical debt). It is a quick ceremony — between 5 and 15 minutes — with the aim of understanding what should be done, according to the article “Defect Prevention Using Agile Techniques”. It is an excellent opportunity to carry out checks and validations on what is intended to be delivered. Below, ten questions to guide an effective Kick Off:
Has card refinement been done?
Is it complete with details and all relevant information?
Is the business value clear? Is there dependence on other cards?
Is there any technical debt related to it?
Are there any prototypes?
Are there any error messages expected?
Is the scope a good size or is it better to break it into more cards?
Is the “happy path” and alternative flows clear?
How do you intend to test?
All these questions help to fix in the team’s mind about the expectations regarding quality in relation to that scope. This will avoid rework, dubious, incorrect or incomplete information and, consequently, prevent erroneous and defective functionality from being developed.
Do Desk Checks to corroborate with the Shift-Left Testing approach
According to the article cited above, the Desk Check is a quick ceremony (between 5 and 10 minutes) that takes place right after the development of a card. Developers who worked on the card meet with business analysts, designers, and QAs to:
- Check what was developed
- Perform quick tests and checks to confirm acceptance criteria have been met
- Find defects
Below, 10 questions to guide a Desk Check:
Does the new feature do what is expected?
Is there any unforeseen behavior?
Does it cover alternative scenarios and the “happy path”?
What is the test coverage for this feature?
Did you go through the code review?
Has it been verified whether the implementation could have impacted another part of the system?
Are all acceptance criteria covered?
Is any kind of improvement or correction needed?
Does the implementation conform to the interface design?
Were they checked for grammatical errors in the texts?
These questions help to ensure that you have developed the right thing in the right way. The Desk Check must be conducted in the test environment (and not in the local environment) and, if defects are found, they do not need to be formally registered. The card goes back to development to make adjustments, or if the business value of the card has been reached, you can open technical debts and mark the card as complete.
Risk-based testing supports Shift-Left Testing
Risk-based testing is an important approach to predicting and mitigating application inconsistencies. According to Gabriel Santos, one of its advantages is that the most critical features are developed and tested first, in order to reduce the overall risk in the project.
Test automation is essential
Automation reduces human errors, increases confidence in delivery, and leaves more time for people to focus on more challenging/inspiring tasks than spending days doing exhaustive testing!
Final idea
QA, advocate for quality strategically. Propose small practices, little by little, and build your team’s mentality. Use the simple tips in this article to improve your quality strategy. Simple mindset shifts will already have an effect. Part of the role of the QA is to convey, in a simple way, the quality strategy, much more than inventing fancy strategies that nobody can execute in practice. Prefer the simple and efficient to the robust and meaningless.
References
- Shift-Left — www.devopedia.org/shift-left
- Defect Prevention Using Agile Techniques — www.thoughtworks.com/insights/blog/defect-prevention-using-agile-techniques
- What is Shift-Left Test ? — www.testim.io/blog/shift-left-testing-guide/
- Shift-Left Testing — www.browserstack.com/guide/what-is-shift-left-testing
Thanks
Thanks to the reviewers of this post: Cristhiane Jacques, Gabriel Santos, Júlio de Lima, Rafael Albuquerque, Rafael Bandeira and Vanessa Redes .
