Why we Shift Left even more
At In The Pocket, we always strive to engineer digital products of the best possible quality. Even if the name of our role as Quality Assurance Engineers suggests otherwise, we shouldn’t be the only ones responsible for the quality of our products – the whole team is. Because in the end, it's that team of dedicated engineers who builds our products. And from our side, we as QA Engineers need to help and guide them on how to do so. It is our duty to shift their mind to think about quality the way we do. As QA Engineers, that's our main focus for 2020. We call it: Shift Left 2.0.
Before you start thinking otherwise: the ‘left’ is not politically inspired, nor is it a metaphor for taking a completely different direction. Shift Left is about moving our QA processes forward in the development lifecycle. About testing as early as possible. And about validating our products as soon as a requirement is being thought of. Of course, we've been through this process a few times before. Coming up with original names can be quite hard, so let’s call our first initiatives Shift Left 1.0.
We already did many things in Shift Left 1.0. From introducing small and agile teams, each with their own dedicated QA Engineer, to "3 amigos" meetings with a QA Engineer, Solution Architect and Product Manager to discuss requirements. And even continuous integration systems, to make sure we were able to test every new feature immediately. And still, we want to go even further. But why?
Why Shift Left 2.0?
Of course, striving towards the best quality remains our major focus. To accomplish that, we need to create as few bugs as possible. And we need to find them earlier. The cost of a bug rises exponentially with the moment it has been found in the development cycle. Fixing a bug in production is evidentially a lot more expensive than preventing the same bug during requirements analysis.
Image: Deepsource.io
Also, we don't want our QA Engineers to be a bottleneck anymore. It has a bad influence on scalability and creates an atmosphere of pressure. Of course, this is not where we want to go.
How do we Shift Left even more?
So how do we want to tackle those challenges and Shift Left even more? First of all, the whole team needs to think on how we are going to build in quality and how we are going to verify and monitor that. To ensure this, we cannot continue working in silos. Communication is key and we need to shift from a "mini waterfall" to a "real agile" way of working. Everyone in the team needs to closely work together.
To get to that stage, we have to focus on collaboration. Everyone should be in the loop and constantly involved to see the bigger picture. Each team member holds an equal responsibility for producing high quality software. Development teams need to adopt "quality engineering": a continuous and agile function that considers quality as an integral part throughout the development lifecycle. It has to be included in every part of the product making: product & design, architecture, planning & estimations and of course, development.
We see new opportunities in every role to integrate quality and Shift Left: you could call them Product Managers 2.0, Architects 2.0 and Developers 2.0. All are to be equally responsible for the quality of their creations and should think of how all of this can be tested.
What about the Quality Assurance Engineer?
The changes to these roles also come with a major change to the QA Engineer role. They should not be seen as the quality gate keepers anymore, because everyone should ensure quality in their own domain. In fact, a QA Engineer will shift towards a coaching role and provide a quality assistant service: the new Quality Engineer (QE) is born.
The Quality Engineer will facilitate everyone else in the team to deliver the best quality in their domains. In every main phase of the development lifecycle, the QE’s will play their role.
Following are the most important steps in the Shift Left approach we are currently rolling out. We believe they will have a great impact on our way of working and quality focus. Of course, there are still a lot more options that we can try to incorporate in our development life cycle.
Three amigo's
This phase was already a fixed value but still remains relevant. The Quality Engineer, Solution Architect and Product Manager closely work together to review the context of new features, check if all "what if" scenarios are covered and if all acceptance criteria are clear. This is mainly important to get good estimations during backlog refinements.
Story alignment
In a next phase, when a developer starts working on a new feature and moves the story to ‘in progress’, he or she needs to pair with someone in the team (QE, PM, architect, designer…) to make sure everything is available to start. Do we need to use a mock API or test data? Are all designs ready? What are the test cases? No assumptions should be made. This step is valuable because from now on, the developer knows what needs to be built – there aren’t any misunderstandings anymore – and what the quality standards are.
Development & testing
During coding, developers are responsible for testing their own features. We do this because testing needs to occur closer to the coding activities. And because the quality standards were already a topic in the previous step, it’s a lot easier for them to maintain the quality focus. This way, fixing issues goes faster and more efficient because there's less context switching for developers who have moved on to their next task.
Walkthrough
When developers complete features and consider it thoroughly tested, a walkthrough needs to be done. In this phase, they need to showcase the feature to the QE, PM or designer. It’s now possible to review whether all testing has been done and do some extra paired exploratory testing. This way, testing gaps can be discovered and feedback can immediately be processed. We have less context switches which makes all of this far more efficient than it used to be.
Of course, all of this is a huge step. Not only for all developers, but for the team as a whole. Testing your own software always feels a bit uncomfortable. That's why we need to take on our coaching role very seriously and guide everyone so they think about quality the same way we do. We know it will be difficult and challenging to get everyone on the same page, but we're convinced this is the way to go. In fact, these try-outs at In The Pocket prove it works out very well.
Of course, there are still many other options we can explore. Currently our objective is a real continuous delivery and deployment pipeline. To achieve this, we focus on optimizing automated testing in our way of working. Shift Left is a perfect means to emphasize this even more. QA is now no longer a phase in the development lifecycle, but a continuous process. Above all, Shift Left is much more than a process change – it’s a mindset and a culture shift.
