You probably have heard this expression many times already. Shift-Left QA is a movement about changing the approach where we constantly improve the quality of the software. In the old world, we used to have a waterfall process where Devs and QAs were completely different and had completely different responsibilities. Working with agile the teams need to deliver fast, but also with quality and on top of this they also need to think about reducing the costs of the tests.
The mindsets are still different, but now we are becoming more collaborative and sharing the knowledge as soon as possible and as often as possible. This is the real continuous improvement/continuous integration approach, the team delivering the software with high quality standards.
The workflow looked something like this example from Winston Royce’s “Managing The Development of Large Software Systems”, first published in 1976:
There is a variety of different shift left approaches that you can take nowadays as you can see here, but the traditional one is something like this:
So where should you start with this Shift Left approach?
You can find loads of guides to follow, but in general, the steps are something like this:
- Pick a small team
- Select a feature for the first interaction
- Integrate Test Feedback in the workflow
4. Create Coding Standards
5. Embrace Test Automation (Different test scopes for each stage)
Now you have a better understanding of what shift left approach is and how you can adjust the workflow to improve the quality of the software. Since this would be your first trial using this approach, you might feel the need to change some things. Overall you will notice this approach makes individuals and interactions more important than processes and tools, gives more importance to working software instead of documentation, also improves the customer collaboration and responds to change over following a plan (which in Agile is always changing anyway).
One of the most critical components of your shift left efforts will be the automated tests you adopt since you need to test earlier and faster, you need to make sure you are not going to spend too much time on maintenance. Your testing tool shouldn’t be a bottleneck in your process. Don’t automate everything, do risk analysis and reduce the scope of tests for the most expensive layers of the test!
Why is this Shift Left approach so important?
First reason is money and time – you are going to find bugs early and reduce the cost of solving them. Second, improve the quality of the product – customers will be happier and satisfied to know they are not going to bump in a different issue every time. Third, with this approach your release cycle can be reduced and you will become less likely to not achieve the deadlines. Fourth, maintain a high-quality codebase also making the tech team happier 😎
So, now you are asking: OK, so how is the QA role going to change following this approach? The way I see it, QAs are going to be more like specialists, sharing their knowledge and advice from the beginning of the SDLC until the end.
Here are some of the QA responsibilities:
This varies depending on the level of the QA (Junior, Middle and Senior), but as many responsibilities you achieve, the more senior you are 💪
- Coach developers to improve unit tests and update existing automated tests, relieving the need for manual tests on small tech tickets and the need to update existent automated tests.
- Create automated test frameworks, performance test projects, functional and non-functional test frameworks, etc.
- Verify Acceptance Criteria and needed information for the tickets.
- Perform Exploratory Tests and sign it off with PO.
- Ability to follow and proactively improve QA standards, templates and documentations.
- Ask meaningful questions that will yield more information and help perform testing effectively.
- Create Test Strategy for the products.
- Review Unit Tests, Integration Tests, Automated Tests and Development PRs, highlight when scenarios are missing on the different test layers. Taking into consideration the percentage of the scope for each layer.
- Writes code following best practices.
- Ability to develop the procedures and hardware/software needed to manually test an application or its constituent components, such as modules or libraries.
- Clearly understand who the end-user is, what purpose the product serves, and how it will be useful to the customer.
- Holds wide knowledge of testing approaches.
- Ability to change test priorities to meet delivery deadlines.
- Able to be auto sufficient and investigate bugs to give more details to the developer.
- Take ownership of the quality and release of the product, documenting, adding evidence, creating test cases, test closure reports, regression package, automated tests, monitoring CI/CD pipelines.
- Share acquired knowledge of feature/automation with the team as required.
There is no right or wrong. You will need to adapt to what works for you, your team and the project. I would suggest analyzing what you have, what problems you want to solve, and pick the most appropriate approach. You will be able to adapt as you learn, but at least the first step is done ✅