Do you have a dedicated QA team? Quality assurance is a step in the product development cycle that is often overlooked, to the detriment of the final product as well as the team who built it. QA exists in a sort of gray area between development and production, leading to that all too frequent situation where it falls through the cracks entirely. To make matters worse, the QA process can be long and convoluted, meaning that it’s harder to justify to the decision-makers who hold the purse strings.
The thing is, the QA process isn’t that difficult to make short and sweet. And the benefits of doing so can be massive. Faster time-to-release, lower initial bug counts, and happier customers and investors are just the tip of the iceberg when it comes to reasons you should have a well-planned and funded QA team.
We’ve taken the most common ways enterprise QA processes get muddled into oblivion and matched them to suggestions for how to overcome these hurdles to get your QA process up and running smoothly.
Not Having a QA Process in The First Place
OK, this isn’t so much a muddling of priorities, rather more of an oversight of the first order. In the interest of saving limited funds, some startups and lean software companies will forgo QA entirely. This seems to stem from the mistaken belief that the same people who wrote the code can find all their own bugs. These organizations slip in a stage right after development is wrapped up where they have the devs do a round of regression testing before they call it a day. There are myriad problems with this setup, starting with, but not limited to:
- Confirmation bias in action. Any good author knows this one--it’s never a good idea to proof your own work. You wrote the words, therefore they’re the right ones, in the right order, and everything is spelled correctly the first time. Nope. Any writer can tell you that you need an editor to make the work truly shine. The same goes for code.
- Human Swiss Army knives don’t exist. Or, they might, but it’s never a good idea to count on it. We’re sure your developers are awesome, that’s why you hired them. This doesn’t mean they’re also great at QA, it’s a different discipline that deserves the attention of a specialist.
Solution: Even if you’re a small, bootstrapped startup, hire a QA specialist and save yourself the headaches down the road. Even if you start with one person who is also a support analyst or something, as long as they have a solid background in QA and regression testing, that’s the place to start. This is totally something that can be outsourced, by the way. A nearshore partner can provide a whole team of QA testers with their own hardware (see below) for a fraction of the costs of hiring a full-time onsite team.
Delays Cost More Than Just Money
Because of that gray area status of QA, slipped in there after development and before production can start, it’s not uncommon for the time dedicated to this crucial stage to be stolen away before they even begin. Alternatively, if one of these teams is located halfway around the globe, the time zone difference can throw another monkey wrench into the timeline.
Ideally, your QA lead will let you know how much time they require, and you’ll have it available after dev finishes work and before production needs to start. In reality, delays happen, developers need more time to finish their coding, or production has to be bumped up to accommodate another project. This inevitably leads to a shrunken, or missing, QA stage.
Solution: Once again, you could consider outsourcing. This takes the strain off of your infrastructure, it means the team can be ready at a moment’s notice. And, if you’re near-shoring, they’ll be located in your time zone, or at least within the same hemisphere, limiting the jetlag effect. That can mean the difference between an on-time release and a costly delayed one.
Leaving QA to the Last Minute
Release schedules are notoriously slippery. At the same time, release dates are often set in stone. How to reconcile this discrepancy? Well, most often, as we’ve mentioned, QA gets cut. If there’s a dedicated team, they’re asked to rush through testing, cutting tests short or eliminating some altogether in order to make up time and make that release deadline.
Solution: QA needs to be treated as the integral part of the development cycle that it is. If the QA manager says they need 3-4 days to thoroughly test the release for bugs, give them 3-4 days. And make sure the teams up and downstream understand the importance of this step and prioritize their own work accordingly.
Unavailable or Reserved Resources
It’s unlikely that your QA team has the horsepower they need to effectively test on their primary work computers. A full round of intense regression testing alone can task the most powerful server in your arsenal. Part of a solid QA process is to ensure the team has access to the resources they need, when they need them, and for as long as they need them.
Prioritizing QA is something you’ll have to work on, discussing it with all relevant stakeholders to be sure they fully grasp the importance of this team getting the resources they need and why it’s key to each of their respective teams as well. QA will need access to the fastest processors and the most RAM you have available to get the best results from their testing.
Solution: Since it’s expensive to give full-time access to a team that only needs it for a few days every release cycle, ensure that QA is on the calendar as soon as development gives you a hard date for their stage to be complete. Part of this will be the discussions you’re having with devs and production management to get buy-in from them on releasing these resources for QA purposes.
Ignoring the Humans Behind Your QA
Along with making sure they have the technological resources needed, there are human needs involved in running a QA team. Just like every other team in your organization, these folks have daily stress from their regular duties, and on top of that they have the added stress of a tight deadline for running some very involved testing on each release. If a product is let loose on the market with bugs, who’s going to take the brunt of the resulting backlash?
One of the pieces of this human monitoring is making certain the team is not being overcommitted. How many projects are they working on at present? Do they really have the bandwidth to take on a rush job for you? Don’t push them, or they’ll start missing crucial issues and you’ll end up releasing buggy software to your customers.
Solution: Treat your QA people like the amazing, appreciated humans that they are. Be sure they have the hardware access they need (see above), be sure they’re handling their stress suitably, and be sure they have the resources they need to keep up the great work.
Not Prioritizing Test Areas
Testing each and every line of code in each and every release would be, well... impossible. And a bit silly, to be honest. Thankfully, automated QA testing procedures mean you don’t have to. Also thankfully, this means you can focus your human-powered test efforts on the code runs that had the most drastic changes made. The automated testing can run overnight, while your people concentrate on the most likely locations for necessary fixes.
Solution: Adopt a two-tier model. Tier one should be triggered by every commit to the code base and should be nothing more than a once-over validation of the new code and shouldn’t take more than a few minutes to run. Tier two is the exhaustive regression testing that runs overnight to reduce taxing needed resources during the workday and to lessen the impact of network latency.
Not Running Simulated Environments
Along with the resources they need to effectively run their regression tests, a fully-funded QA team will also be able to run new code in environments built to simulate the real-world scenarios your customers will be using. What good is testing on the latest and greatest hardware when your client base might be on 5-year-old machines with insufficient RAM?
Solution: This is a two-parter. First, you can have virtual machines set up with a variety of configurations so testing can be performed on a wide variety of systems with stats that run the gamut. Or, again, you can consider near-shoring. When you hire an outsourced QA team, they come with their own hardware, so you don’t have the added expense of outfitting a whole team with daily machines, high-horsepower testing systems, AND real-world simulations. You hire the team, and they handle the rest.
Enterprise quality assurance is a critical part of any release cycle, no matter the product in question. Following industry best practices is always a great place to start, but you will undoubtedly encounter some issues that are unique to your product. Our hope is that this piece helps jumpstart your brain cells and will help you identify the places where problems may crop up and quash them before they get out of hand.
Learn More About Intertec's Quality Assurance Services:
Intertec offers a robust array of services in testing and quality assurance. In addition to personalized technical services throughout the software lifecycle, we offer experienced QA teams with the expertise and skills to manage this critical business process. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
