The changing role of Quality Engineers in a shift-left paradigm

While the tech world is talking about quick and high quality deliverables, many organizations are still struggling to market their products on time, while ensuring superior quality. We believe this is largely due to the way the software delivery lifecycles (SLDC) are being managed.

After the completion of code development, time-consuming testing follows. The testing phase is usually lengthy, thanks to manual testing or because of prolonged execution time for end to end tests. There is an expectation that testing increases the overall cycle time. But, that’s only because conventional product testing comes right at the end of the software delivery cycle. This negatively impacts on-time delivery and hinders the organization’s performance.

This builds the case for something called ‘shift-left’ testing. However, it’s not an easy task for an organization to move all their projects from traditional testing to shift-left testing.

It’s risky to, overnight, get rid of all the end to end tests and solely depend on whitebox testing. We’d recommend an approach of slowly reducing the over-dependency on end to end tests and the maintenance required for the same.

Instead, organizations would be better off using their Quality Engineers’ (QE) time and efficiency to focus on bigger issues such as identifying missing requirements, and on the behavior of dependencies like external systems or even validating security and performance on a particular piece of functionality at early stages of development through analysis and exploratory testing.

What is shift-left?

In order to achieve a faster feedback cycle and quick product delivery, it’s important to focus on testing early. The earlier the testing happens, the earlier the issues surfaces, resulting in lower costs to fix identified defects.

While defects are usually introduced during the analysis and development stages, conventional testing is carried out (much later) towards the end of SDLC. Shift-left testing is different because the focus is ‘not to find defects but rather prevent them’ from even entering the system.

It requires rigorous testing during the analysis and development stages. This approach can involve — validating designs, validating requirements, discovering dependencies early, testing integrations early and even checking security, performance and accessibility testing much earlier in lower environments.

In effect, shift-left testing champions the ‘baking in of quality at all stages of product development’. This calls for a lot of analysis, exploratory testing and also a fast CI/CD process. And, a definitive evolution of the role of quality engineers.

Shift-left testing and QEs’ new role

Here’s an overview of what I believe will change, with respect to QEs’ tasks, with the shift-left testing paradigm taking center stage in the world of testing:

• More exploratory testing

Test cases play an exceptional role in deciding what to test. However, in reality it’s out of box thinking that identifies the most interesting and severe issues in a software system.

To get this kind of thinking right, QEs will need to have a good grasp of the software system’s functionality and architecture (from end-to-end) and should be willing to go beyond the test case boundaries to explore and test everything. This means documented test cases could end up being automated while only exploratory testing are manual.

• Fewer end-to-end tests

We’d suggest that end-to-end tests focus only on business cases and personas. Products with very few business or user flows demand less than ten end-to-end tests.More tests lead to flaky and brittle end-to-end tests, irrespective of the tools being used. Edge cases and boundary conditions don’t belong here and should be moved to unit tests.

• Wider range of tests — integration tests, component tests, contract tests etc.

The test pyramid makes evident that writing tests in the smallest possible components helps with faster product testing. This calls for time being spent on writing unit and integration tests rather than on end-to-end tests.

• Testing begins before development begins

Early testing or testing before development even starts is a proactive approach that visualizes all possible edge cases in advance. This approach makes it easier for developers to handle edge cases in their code. Also, testers can verify if stories have been written in a testable manner. For instance, if a story requires dependencies to be handled before it can be tested, testers can prioritize such dependency-handling before story development.

• Inclusive requirement gathering and estimation

We recommend that requirement gathering and estimation be thought of from the ‘quality perspective’ as well. This calls for QEs to be an active part of these discussions that will help the team to come up with comprehensive estimations.

• Learning never stops

Ever changing technology requires QEs to be on top of the dynamic digital world. In order to perform testing on the latest technologies, QEs will have to upskill themselves in areas like Cloud, AI, ML, data engineering, robotics etc.

This is because shift-left testing calls for QEs to understand implementation along with functional aspects. Taking part in conferences, workshops and experimenting on one’s own will help QEs to upskill their technical knowledge.

Shift-left testing and why QEs should not be worried

While shift-left testing can deliver fast and reliable software delivery, QEs seem to be concerned with the adoption of the approach.

• QE jobs will stay secured

The shift to more tests at the bottom of the pyramid and less end-to-end tests does not make the QE’s role vulnerable. It only means more effort will go into early testing and exploratory testing, making the QE’s roles even more strategic and involved throughout the SDLC.

• No additional burden

As an experienced QE, I can attest to what a nightmare it can be to attend all the several kickoffs, desk checks and other analysis discussions, especially if QEs are already burdened with maintaining and writing a large number of end-to-end tests.

Prioritize making the end-to-end tests stable and visible in the CI pipeline, so it’s the entire team’s responsibility to maintain them. The less time spent on maintaining automation suites means more time to focus on product quality.

• No sacrifice of technical skills

Writing fewer end-to-end tests and working on more manual exploratory testing, does not dilute one’s technical knowledge. Looking at different ways to optimally test the product and improve subsequent integration and deployment processes are new areas in which QE’s can enhance their technical abilities.

We’d say, utilize the time to learn and contribute to deployment pipelines, cloud architecture, containers, mobile testing, accessibility testing, security testing, performance testing etc. All of which will make QEs technically well-rounded, adding to the adoption of the shift-left approach.

The aggressively-paced technical world brings new challenges in testing and the QE’s role is more important than ever before. For instance, the future is pitted on the likes of big data, AI, ML, AR, VR etc. Each of these emerging technologies will require a deep understanding of the technology to better support testing ‘in’ them. Shift-left testing has the potential to elevate the QE’s role to become more advanced, strategic, integrated and centered on product quality.