Can We Overcome Testing Bottlenecks?
Break down traditional QA silos and empower developers to own quality checks.
Bottlenecks tend to be a common occurrence amongst software development teams, and most commonly during the testing phase. If you continue to experience this symptom, then you’re not alone as software development teams from all corners of the earth go through these phases. But is there anything we[the team] can do to prevent this from happening in the first place?
First, let me illustrate what a typical bottleneck that agile software development teams experience.
While it’s usually common that we assign all the testing to one QA to catch them all, it’s important to remember it’s not their fault that this bottleneck occurred in the first place. But if it’s not their fault? then who’s to blame?
This article should highlight a few common areas to think about and improve on.
If there’s one area in particular throughout the software development cycle that impacts our speed to move tickets through testing efficiently and quickly, it’s that we still believe it in the traditional practice to outsource the testing (usually) to a single QA engineer.
Software technology has come a long way since its introduction, and the growth within the past 10years has been exponential. We’ve seen the creation of tech companies across the board expand at an ever-increasing rate. Now while we’ve made many adaptions, there’s one that we’ve overlooked, and to help me explain, let’s quickly reference the mission statement:
The traditional testing practice we continue to employ within our teams is holding us back, specifically speaking, we assign all of the testing to a dedicated QA team member. Now while this may have served development teams well a decade ago, we need to remember that software has evolved. Testing has become more than just performing checks against an acceptance criteria, the scope of testing has increased, but the reliance on a single QA has remained the same.
Consider the following key aspects:
- Acknowledge that testing has become a more time-consuming process due to the fact how diverse and complex many systems have become.
- QA engineers are the experts in testing, and they need to share and teach developers to become more confident testers.
- Fill out your acceptance criteria properly if they lack the information, and work together with developers, in the beginning to help them understand all the areas you[QA] check.
The more businesses recognise the fact that software testing is evolving, and that change is required in moving forward, then the sooner more teams will benefit.
Testing environments, deploy pipelines, and the remaining infrastructure that helps to enable the safe passage of code from development to production all require time to set up. This type of work is usually adopted by developers in the early stages, and maintenance can sometimes be months apart.
Ill-maintained infrastructure is usually due to software teams that lack having a dedicated DevOps person or team. Integrated test environments and deploy pipelines require frequent maintenance, and constant optimisation in order to remain efficient, without it, these environments begin to work against us.
It’s not always possible for some companies to have a dedicated DevOps person, so consider the following:
- Aim for simplicity, doing so will promote the possibility for more developers to contribute in helping to maintain it.
- Invest time to regularly update and maintain your release pipelines.
The more developers you have helping to maintain these environments and pipelines, the easier it is to upgrade and progress with evolving software.
So how does this idea tie back to bottlenecks? Well, if the QA/DEV engineer is constantly left waiting for code to reach the right testing environment, then the need to improve that pipeline requires some attention.
Feedback times are important when everything that’s being developed and tested, had to be “released yesterday”. There’s great importance in ensuring that pipelines are regularly optimized. It’s unreasonable where 1-hour release build times can be normal for 1 feature to reach the right environment(s), and considering that a feature can bounce back-and-forth between a developer’s local machine and the testing environment, that’s time wasted.
An environment that lacks constant optimisation, runs the risk of eventually being unable to deliver with speed due to the growth of an advancing piece of software. These environments that were set up in the beginning, are sometimes no longer the right solution, but because a business isn’t always willing to allow for such improvements, bottlenecks can arise.
Automation suites can be regarded as a blessing or a curse depending on your experience, but ultimately, automation plays a large part in providing additional confidence to know that what you’re about to ship hasn’t unexpectedly broken your current working product.
While automating everything sounds like a resounding and courageous idea, it isn’t always a practical thing to implement, and if your team has undertaken the mammoth task, then you’ll soon notice that maintenance can become overwhelming so consider the following:
- Be clear about what you want to automate, identify your business-critical flows and systems that should have automation.
Focus on having automation implemented for business-critical functions first, ensuring to do them accurately the first time around. There’s nothing more wasteful than doing a half-ass job in the beginning only to have it hold you up down the line.
Seek out the help of developers, as they remain the development experts, and their knowledge and support in automation is an important one. Automation is a technical implementation, work with them and keep the following in mind:
- Developers should be able to run and maintain automation frameworks, in the absence of QA engineers.
Bottlenecks around testing can arise due to automation maintenance, especially when not looked after. But a team where all developers contribute towards building and maintaining the automation framework will keep bottlenecks out of sight.
Development is a process, and the way we work influences our likely hood of potential roadblocks along the way. So I do believe that ‘testing bottlenecks’ can be overcome with the right action.
Subscribe if you like what you’ve read ? Leave a clap 👏 and stay tuned for more!
