A paradigm approach to bring testing early in the application development, to assist in finding the bugs sooner than expected during the cycle is all a part of Shift left Testing. The term ‘Shift left Testing’ is perhaps a misnomer. The word ‘shift’ signifies movement or rather indicates removing something from one spot and placing it on the other. Now, when we apply this to testing, it does not strike a chord immediately!

In ‘Shift Left Testing’, we do not move the entire testing that was executed somewhere to another place. Shift left brings in testing activities that are happening or have happened from extreme right to left, so that it is quicker to discover problems that matter. Sometimes, it is also important for us to note that we may need to retain certain types of testing towards the right as well, so essentially, it is ‘Shift Certain Test Activities Left’.

An example of shifting left is moving from traditional performance testing to performance engineering. Performance testing is introduced at a stage where an application is functionally close to the expectations. This is usually done via simulating the load to verify if the performance metrics like response times and CPU utilization are as per the expectations for the load generated. The usual outcome is to locate the transactions that make it slow.

While in performance engineering, practices are incorporated early during the development to question and optimize the transactions as needed. This helps in identifying any performance issues before they are brought to test execution.

With distributed teams for software development, it is difficult to keep everyone on the same page with the updates on product development. The general practice is to have a separate test team introduced subsequently in software development, but over time it becomes difficult for the test teams to be adept with product/business knowledge. To take control of the situation, here we are with four tips that you must look for with a distributed test team in the ‘Shift left’ scenario:

1. Onboard your Test Team Early

Distributed/outsourced test team is often introduced late in the development cycle for several reasons. In a typical flow of activities in agile from Epics > Stories > Tasks, onboard the test team at least during the sprint planning meetings, where user stories are estimated and scoped out.
Involving the test teams during estimations will get them a deeper understanding of the product along with other stakeholders. Asking the right questions during sprint planning meetings would assist in checking the quality right from the planning stages.

While working on the planning phase, onboard your test teams on relevant project management tools, to access the information after the planning meetings and give early feedback on the implementation. Set up a communication channel for easier communication rather than just waiting for an email or a web conference to be scheduled.

2. Have Separate Environment(s) for Testing

For most products during the initial stages, developers do entire testing, limiting the deployed environments to minimal. Testing could be done on a Dev environment and with distributed/outsourced test team, it becomes important to have a dedicated environment for testing. Now, depending on the merging model, introduce the test environments to conduct feature testing, manual, and automated regression testing.

3. Implement Continuous Testing

Automation is a crucial part of testing to get quick feedback on the build. In the Shift-left Testing transformation, it is important to automate tests as needed and execute them without any delay.
While the testing team is involved early in the lifecycle, manual testing may not always yield immediate results due to the:

• Time taken to execute tests.
• Waiting time for human intervention to carry out tests.

Implementing continuous testing via having automated tests run immediately after the build is triggered, will give early feedback on the build, as necessary. This helps the test teams to easily assess the next logical steps on continuing with detailed level testing of the build.

4. Define Clear Ownership

A crucial aspect to consider when you have distributed teams is to create clear ownership of tasks. It is inevitable to have testing tasks (or tasks that enable testing) done by different stakeholders – BAs, Developers, SDETs.
Sometimes, we may have a set of testers limited to do a certain type of testing, and hence the ownership needs to be defined and published. Here are a few tasks that need clear ownership:

1. Choosing the next set of candidates for automation
2. Integrating tests into CI/CD pipeline
3. Review and report automation failures
4. Maintaining automation scripts on the pipeline
5. Triggering Non-functional testing

All these years, ZenQ has been successfully collaborating with leading global clients to create milestones by incorporating highly trained engineers and SDET’s into our customer’s development practices. Contact us, for more inquiries and information on projects, and our team of experts will get back to you.

By: Rakesh Lokireddy