In the beginning, software development followed a waterfall methodology. While the interactions between the teams could still be respectful and open, the testers were getting involved so late in the software development process, that there was always a sense of disconnect. This disconnect could result in multiple issues. Three such examples:

1. A lack of understanding of the expectations or changes that have been made.

2. Bugs being found that cause the Developer to have to context switch from a task they are currently working on.

3. Releases are getting delayed due to critical bugs being found too late in the release stages.

Taking a traditional developer/quality team and asking them to change how they interact during the release cycle can be challenging. So the question becomes, how do you begin the Shift Left mindset while retaining your development and quality teams and not increasing the risk for a deliverable product? Today, we will go over some of the changes a team made in an attempt to implement Shift Left testing. What worked, what failed, and how they adapted. Some of the questions the team had to ask themselves, and how they addressed potential problems. What is the difference between quality engineering and quality assurance? Why does this difference mean so much to this shift? Where and how do the interactions begin, and how often during the course of product development? Team cohesion plays an essential role in Shifting the Left and can kill this initiative if it does not exist.

Takeaways from the topic:

It is all about a mindset shift.

• It is not Dev and QA/QE it is an engineering team working together to develop and quality maintainable and sellable product
• The engineering team collaboration should begin before the beginning, starting this collaboration as early as refinement will help to cultivate the collaborative spirit and foster it throughout the lifecycle.
• The engineering team collaborates on test scenarios, and code design, and iterates this collaboration throughout the development process

Changing these mindsets and interactions will provide the testing team with more confidence in every level of automation, it will reduce unnecessary duplicated testing efforts, reduce the more costly manual or end-to-end automated tests, and will overall provide a better quality product at a lower cost to the company.