Break down traditional QA silos and empower developers to own quality checks.
“Ready for testing” is a phrase thrown around the space of tight-knit software development teams. And it generally signals the turning point from which a bunch of code, representing a feature has reached a state where a developer perceives the feature as “ready for testing”.
From this point on we look to our fellow QA, dust our hands off the feature, take a well deserved break and move on to the next feature in sight.
And it looks a little like this:
But more often than not, the reality is more like this:
For many software teams, this posseses a big problem, and quite often the QA is faced with having to absorb, manage and perform testing.
If your team is like the majority of teams, then as a result, you’ll eventually experience and run into timely delays, halted releases and a sea of questions from all directions asking when we can expect to release.
A company may eventually get restless and expand the budget allowing to hire more QA’s: the delays we knew begin to vanish and we’re back to delivering at speed. This soon wears off, because more developers are eventually hired with the company expanding, and the unbalanced ratio of DEV:QA rears its head once more and delays are reintroduced.
For now this problem will continue to persist as the day to day activities of the QA slowly broaden, and we continue to rely on few QA’s to test the work of “X” developers.
Out with the old, in with the new
We know the problem, but what can teams do to move forward with a process that was originally introduced to help them excel, but now acts as a costly blocker.
Let’s refer back to the start of the article, my mission statement:
The dilemma isn’t that we have skilled developers writing code too quickly and efficiently. Nor is it a dilemma of the QA not having the knowledge and know-how to perform efficient testing, quickly. Instead we need to recognise that times have changed since the introduction of computers and the start of the internet. And moreso, acknowledge that traditional QA practices require change.
Let’s start by realising that modern day software applications require more attention, we need to be smart and share our knowledge on effective ways of testing with developers, thus empowering them to become better testers. It’s no longer about being Han Solo in tackling all of the testing, but more about educating and then relying on developers to own quality checks.
By educating and sharing the knowledge with developers, they’ll eventually write better quality code and they will be able to ship features not only faster, but on their own.
Like what you’ve read ? Subscribe and leave a clap and stay tuned for more!
