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!
middlewarehq / middleware
✨ 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!
Top comments (20)
devs should always own the code and never throw crap over the wall to be tested.
that said there is no left or right approach. dev needs to be responsible for coding and unit testing and automation. QA is there to be sure all requirements are met as a extra set of eyes 👀 for the development and PM.. keep everyone honest.
That is spot on! All efficiency approaches are bespoke to the context ☺️
Shift left is fine and approach has been in use for some time. QA is never a bottleneck if the code quality you build is good. And, if your code quality is good and QA taking more time to validate then you need to review the efficiency and skills of testers, and fix the team accordingly with right testing skills.
You're right! All process improvements are bespoke ☺️
This is the age old issue....Dev takes their time to create, QA is always the bottleneck. Solution, create an accurate project plan, follow it and adjust it when situations happen when something takes longer than expected. Keep management informed. And, when deadlines have to be met, the team puts in the extra effort and in some instances you drop features to make deadlines. You need QA....recall recent issues last week. That was a failure in the development, QA and release process. Final thought, the most successful projects are, when DEV and QA are working together. The writer of this article sounds like they work in a Waterfall development environment. They may want to try Agile development . It's a team approach to development.
Shifting left is one of those things that feels so obvious once someone says it to you. 👏
Great post! The struggle with QA bottlenecks is real. Loved the idea of shifting QA left and having devs own their code. Collaborating better and looking back for improvements can make a huge difference. Thanks for sharing these tips!
Oh yeah. I've seen an impact of this pretty instantly at one of my previous jobs.
the genie is out of the bottle!
Wonder post , can we shift the ITIL to UP or DOWN as well as kind of shifting coz they need to be automated Lol... Waiting to your article about it
Haha!
Although automation comes slightly later when the use cases are solidified. For the fresh features, it's generally and rightfully on a lag
Devs can be good at writing test plans. QA engineers who do not test anything should not even exist. Just ditch them.
💯
Well done! QA is something that can start from the design/requirement state
What if it's the opposite and there isn't enough QA resource?
Then someone needs to prepare the test plan. The devs then ☺️