3 days of planning, 5 days of execution and then the whole work gets stuck for weeks on QA. On the flip side if it gets picked up, it results in a poor job of testing leading to a reactive firefighting later.
Does that sound familiar?
Well that was atleast my team’s state at Shuttl for every new feature our devs picked. No matter how big or small, the QA was the bottleneck for every change.
It was unavoidable because in the absence of the QA, the quality risk was even higher.
Nobody likes firefighting consistently. So, what’s the fix?
In this blog, we’ll talk about 5 steps (in order) which will help you get unblocked from a QA approval:
- Shift Left when QA gets involved
- You code it, you own it
- Always have their back when needed
- Look back to find improvement patterns
- Get inspiration from industry benchmarks
Shift left when QA gets involved
A typical development process starts from planning, then you program it, test it, release it and monitor incase of any failures. (as shown below)
In a typical software team, there are multiple engineers building features however 1 or 2 manual QA attached per team(or pod). Once the features/bug fixes are ready by the devs, the QAs are responsible to do systemic tests to ensure correctness and then it is released.
The problems occur when multiple features have to be released together.
That’s when the QA bandwidth gets crushed in toggling between different features.
That’s when the development team despite having a ready feature gets delayed to production.
Cherry on top is: after a long wait, there is a feedback and then again a long wait - so the cycle continues!
To fix this, the first step is to shift the QA towards the left in the process.
Instead of them testing the changes manually, ask them to create a test plan during the planning of the feature
Test plan
A document which consists of all scenarios where the product should work, all corner cases and cascading risks covered.
Since, the QAs are specialists of thinking about the corner cases, freeing them up from the grind will enable more quality and coverage in the test cases.
Once, the test plan is ready, we move to the next step ⬇️
You code it, you own it
We developers are more than able and smart to run everything end to end. The test plan takes the load off of thinking sad cases and now all we have to do is check, check, check
One of the benefits of having a test plan before programming is that you can fix your design in accordance to the test plan itself and save many days (and nights) from your life.
So, now nothing stopping you!
Always have their back when needed
However, life is not so ideal. And sometimes you might need to make fake data, set up new environments or knowing additional context which might totally derail your flow.
Then is the moment where you must remember QAs are our team mates 😄 and inform them beforehand what test plan items might require their help so that when you’re ready to test, they can support you with activating those activities.
Common ways to involve them in:
- Mark the items in the planning stage itself
- When you are about to finish development, book their time in advance to get your environment ready
- Request their help in your stand-ups
Look back to find improvement patterns
Throughout this change, there will certainly be different phases of problem:
- [Pre Change] Lot of time spent in just waiting for QA approval
- [During Change] Teething issues and process adjustment to your team’s comfort
- [Post Change] Iterations to find what can be improved to achieve your peak productivity as a team.
One practice that will always help you will be doing a retrospective after every sprint basis on actual data (as below)
Collating data can be time consuming and hence has a risk of de-railing all retrospectives.
(Disclaimer: I am also the co-founder) A tool like MiddlewareHQ helps you be focussed on your work by bringing all the process insights at one place from your tools like Jira, Git, etc.
Consider this as a fitness band for the whole team while the athlete (the team) is training 🏃🏼♀️
Get inspiration from industry benchmarks
We as software engineers have grown up looking at technology benchmarks and language benchmarks. However, when it comes to our productivity, there’s no standard practice.
QA being a bottleneck is one of the many challenges in your software delivery journey.
A great way to keep improving(IMO) is to leverage the industry benchmarks for teams like yours. DORA metrics is a great framework by Google and they publish an annual report every year with benchmarks on delivery process and quality. (Read more about DORA metrics)
That was the aim with which we decided to launch an open source offering to measure DORA metrics for any team in the environment of your choice.
Our mission is to remove friction out of the development process and enable builders to build better! Do consider giving us a ⭐️ if you like what we’re building!
✨ Open-source DORA metrics platform for engineering teams ✨
Open-source engineering management that unlocks developer potential
Join our Open Source Community
Introduction
Middleware is an open-source tool designed to help engineering leaders measure and analyze the effectiveness of their teams using the DORA metrics. The DORA metrics are a set of four key values that provide insights into software delivery performance and operational efficiency.
They are:
-
Deployment Frequency: The frequency of code deployments to production or an operational environment.
-
Lead Time for Changes: The time it takes for a commit to make it into production.
-
Mean Time to Restore: The time it takes to restore service after an incident or failure.
-
Change Failure Rate: The percentage of deployments that result in failures or require remediation.
Table of Contents
All the best and hope nothing blocks what you want to achieve!
Shifting left is one of those things that feels so obvious once someone says it to you. 👏