DEV Community

Cover image for 5 ways to skip QA approval forever!
Dhruv Agarwal for Middleware

Posted on

5 ways to skip QA approval forever!

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.

Whack Mole GIFs | Tenor

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:

  1. Shift Left when QA gets involved
  2. You code it, you own it
  3. Always have their back when needed
  4. Look back to find improvement patterns
  5. 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)

Software Development Life Cycle

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

Software Development Life Cycle with QA involved in planning

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!

You Got It Dude

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.

Stop It Get Some Help

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

Retro

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)

Sprint Flow  and effort investment

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!

GitHub logo middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Middleware Logo

Open-source engineering management that unlocks developer potential

continuous integration Commit activity per month contributors
license Stars

Join our Open Source Community

Middleware Opensource

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!

The end

Top comments (20)

Collapse
 
californiak15 profile image
DEVing_Testing

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.

Collapse
 
dhruvagarwal profile image
Dhruv Agarwal

That is spot on! All efficiency approaches are bespoke to the context ☺️

Collapse
 
arifchauhan profile image
Arif Chauhan

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.

Collapse
 
dhruvagarwal profile image
Dhruv Agarwal

You're right! All process improvements are bespoke ☺️

Collapse
 
craig99 profile image
Craig • Edited

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.

Collapse
 
jayantbh profile image
Jayant Bhawal

Shifting left is one of those things that feels so obvious once someone says it to you. 👏

Collapse
 
samadyarkhan profile image
Samad Yar Khan

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!

Collapse
 
jayantbh profile image
Jayant Bhawal

Oh yeah. I've seen an impact of this pretty instantly at one of my previous jobs.

Collapse
 
shivamchhuneja profile image
Shivam Chhuneja

the genie is out of the bottle!

Collapse
 
ahmed_saif_b41028964a6d30 profile image
Ahmed Saif • Edited

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

Collapse
 
dhruvagarwal profile image
Dhruv Agarwal

Haha!

Collapse
 
dhruvagarwal profile image
Dhruv Agarwal

Although automation comes slightly later when the use cases are solidified. For the fresh features, it's generally and rightfully on a lag

Collapse
 
motss profile image
Rong Sen Ng

Devs can be good at writing test plans. QA engineers who do not test anything should not even exist. Just ditch them.

Collapse
 
dhruvagarwal profile image
Dhruv Agarwal

💯

Collapse
 
martinbaun profile image
Martin Baun

Well done! QA is something that can start from the design/requirement state

Collapse
 
pauluz profile image
Paul Canning

What if it's the opposite and there isn't enough QA resource?

Collapse
 
dhruvagarwal profile image
Dhruv Agarwal

Then someone needs to prepare the test plan. The devs then ☺️