ºÚÁÏÃÅ

While the agile movement broke the work into smaller pieces, the testing phase remained the last. Although the amount of work that needed to be tested was reduced, the same problems persisted - long running flaky end to end (E2E) tests , Quality Engineers (QE) performing rigorous time-consuming testing before production release.

Shift-left testing means early testing. This brings a different mindset to the Software delivery Life cycle (SDLC) where QE is involved much earlier. Shift-left testing allows the QE to identify and prevent defects from happening by testing during analysis and development stages. 

The current practises have to be slowly dismantled in order for the team to shift to this mindset safely and confidently. They can do so by focusing on three main areas: Restoring confidence in E2E tests, Re-Building the test pyramid and ensuring Team collaboration. 

Restore confidence in the E2E automated tests

 The rise of automation has resulted in hundreds and thousands of  E2E tests.  These  tests  are often unstable and generate false negatives causing build failures in the Continuous Integration pipeline. Continuous red builds tend to be ignored. Real defects get conflated with these flaky tests. The first step towards shift-left is restoring confidence in the automated tests.

 Below are the steps that can be taken to ensure that the E2E tests are manageable and reliable:

1. Tests that have already identified defects can be temporarily tagged out as defect (@defect) and should not be executed until the issue is fixed. These tests may also be removed completely and rewritten as part of the defect fix. Such tests if executed before the defect fix, can cause constant build failures and can be ignored. This can result in not validating a new valid test failure on time.
2. ​The flaky tests have to be fixed and may be run separately in another pipeline temporarily. Once these tests are stable, these can be moved to the stable test suite.This gives confidence to the team that any failed build is a sure indicator of defect in the application.
3. Faster feedback can be ensured only through fast builds. Hence adopting ways such as parallel tests and proper refactoring of E2E tests can mean a lot to the team.
4. ​E2E tests should be run after every code commit and if the execution time is within acceptable range then having these tests as part of the main build is advisable. Thus making it visible develops a sense of ownership and priority in not just the testers but also in other concerned roles to maintain the tests green.

 

 Re-Build the test pyramid

In the shift left testing model, maintaining a test pyramid testing strategy is key. Following the test pyramid model keeps the number and quality of E2E tests under check. Also, this ensures tests remain a focus not only during testing but also during development.

1. Adopt below ways to make an ice cream cone a pyramid testing structure:
2. Remove E2E / system tests which are duplicates of the unit or integration tests. Repeating the tests that have the same objective or testing the same feature does not add any value to the product quality. To start with, document all the E2E tests against its objective. Look through unit and integration tests to identify if there are tests with the same objective and note them alongside the E2E tests in the document. Using a code coverage tool can make this task easier. Another approach is to go through the GitHub commits to check if a particular story had corresponding unit or integration tests that satisfied the acceptance criteria. This approach however would work only in cases where the commit messages had the story number specified.
3. ​Improve the coverage of unit and integration layers. Have a code coverage tool and analyse areas of code where unit and integration tests could be written rather than improving the coverage through E2E tests.
4. Move tests from top (e2e or system test layers) of the pyramid to the bottom (unit/integration). Once enough unit and integration tests are in place and the duplicate E2E tests are removed, the next item is to identify more tests that ideally belong to the bottom of the pyramid and move those down.​

Improve team collaboration

Quality is not a thing for Quality engineers or testers alone. It is a collaborative effort by all the roles involved. With shift left testing, everybody is responsible throughout the Software Delivery Cycle.

Here are some steps to ensure team collaboration in a project: 

1. Team members should not be segregated by role. Everyone working to the same team goal should be seated together. This allows continuous conversation between everyone working on the product or feature, creating a sense of unity towards the same goal of high-quality product. In a scenario where team members are remotely located for reasons such as the COVID situation, then, daily catch ups with the whole team including sign up and sign off meetings may be useful to ensure a sense of belonging.
2. Work collaboratively with UX and BA on analysing cards. Review cards and write test scenarios before it gets to the developers. This helps guide developers to write good quality unit and integration tests thinking from a feature perspective rather than from an implementation angle. It also helps to maintain a balanced test pyramid. 
3. Discuss test scenarios in story kick-offs and dig out analysis gaps and edge cases. This practise can be successfully carried out even while working remotely.
4. Review and collaborate all throughout the development and testing stages. Zoom rooms can be kept active for jumping in for discussions if teams are not physically colocated.
5. Use desk checks as a platform for early integration testing with other systems.
6. Pair up to write more unit tests during desk checks and keep the test pyramid model under check.

 All the above, can be seamlessly practised even while working remotely using conferencing tools.


Adopting a Shift-left mindset not only will reduce lead time for code deployed into production, but also, it will improve the overall product quality. Shifting the team to this approach is not trivial. But focusing on these three key areas and the steps outlined here can help to transition effectively and efficiently into this model. Test Early and Test Often has never been so relevant.