INTERTEC BLOG

Our Latest Content is on the FPT Blog

Feel free to browse our existing content below, however, if you're looking for the latest articles, we now post them to FPT Software's blog page

Are You Doing QA Testing Wrong?

May 21, 2020 / by Mark McLoud

Off the top, what does the phrase “quality assurance” bring to mind?

It sounds like something the manager of a production plant or factory would be concerned with to us. Or maybe that automated message when you call the bank, the one that tells you the call is being recorded.

What does any of that have to do with software development? Everything.

QA testing is frequently done wrong. Follow our advice to steer clear of common missteps.

Quality assurance, or as it’s more commonly known in the software world, QA, is an essential part of the software development cycle. Unfortunately, and to their great detriment, many companies forgo or underscope this phase of the cycle in order to save money and/or time. By discounting the value of thoroughly testing their product before releasing it into the wild, these companies are risking their very reputations. And while they might indeed save time and money, they’ll be gaining unhappy customers and potentially buggy software with their name on it.

Today we’re going to dive into QA testing, go over some do’s and ‘don'ts, and take a look at how you might very well be doing this essential step wrong. We will, of course, also give you some ways to correct course and ensure that you’re not letting buggy product leave production.

 

What Is QA and Why Is it Necessary?

In broad strokes, QA is any process by which a company ensures that they are providing the best possible product or service to their customers. Most QA processes are based, at least loosely, on what is called the PDCA loop:

  • Plan
  • Do
  • Check
  • Act

There is even a set of internationally accepted standards based on this loop, known as ISO 9000, that exists to certify that an organization’s processes are, in fact, working in the best interest of their customers and other stakeholders.

To bring it into the software world, this means that no software release is left untested or unchecked. This testing is what ensures that bugs are caught and fixed; and that all releases are as clean and functional as possible before the public gets its hands on them. The QA test phase of the SDLC consists of processes and procedures designed to detect anomalies and bugs as early in the cycle as possible so they can be addressed and corrected.

So the answer to why you need this is simple—issues cost less when detected early. By running code through a set of rigorously designed tests, you weed out any flaws or bugs that might crop up post-release and then eliminate them from the relative safety of your development environment. And by catching them before the public sees the update, they stay pleased with the performance of your product and remain happy customers.

 

The Top 5 Ways Companies Screw Up QA and How to Avoid Them

Now that you have a solid handle on what QA is and why it’s so important to get right, we’re going to cover the top 5 ways we see companies misstep and handle QA wrong. There are myriad ways testing can be carried out, many of them are good, some are great, but far too many are quite bad. By steering clear of these missteps, and following our suggestions for corrections if you find you are already making some of them, you can get your QA back on course.

1: Running one set of tests on all the code

Far too often, software companies rely on their development teams to also conduct what they deem QA testing. By having the same people run tests that wrote the code in the first place, they’re risking several issues. At the top of that list is confirmation bias, where the creator basically says, “I wrote it, so I know it’s right.”

The solution is twofold. First, make testing its own department with its own dedicated staff. This keeps that bias from creeping in. And second, test iteratively. Each test should focus on an individual feature set or update. By breaking the testing down like this, your team is far more likely to spot the small issues that can become huge once combined and run as a whole.

2: Assuming that old code will stay good through updates

Just because the code worked when it was released doesn’t mean it will continue to work after the next release. This is where regression testing comes in. New updates can mess with existing code in unexpected ways. By running automated regression tests on every new release, you ensure that the newest code additions don’t cause any of that older code to misbehave. Regression testing can be automated to run overnight, so the added strain won’t tax your production environment.

3: Thinking developers can test their own code as they go

We mentioned this in passing up in item 1, but it bears repeating. Just like a published author hires an editor to proofread their manuscript before publication, developers need someone else, someone outside of the development team, to check their work before release. When you’ve been staring at the same lines of code for hours on end, week after week, you lose the ability to see it clearly.

The fix is to run a solid bug tracking program. That way, no matter who finds any given bug, you can rest assured that they will all be addressed. You will also have a record of the individual or automated test that located the issue as well as who fixed it, so that down the line there’s accountability for everything. Keeping things as frictionless as possible helps the whole cycle move more smoothly.

4: Not paying attention to metrics

Metrics matter. By including what QA factors you’re going to track before a project gets going, you’re ensuring not only that accountability will remain strong, but that you’ll have concrete numbers to back you up. When it comes time to justify your spending on hiring that QA team, nothing works as well as a solid set of numbers showing ROI.

Leveraging the analytics in the bug tracking system you implemented above can drastically cut the work involved here, as the metrics are all there, ready and waiting. You just need to pick the ones you want to highlight and compile a graph or chart for visual impact.

5: Ignoring your users’ unique situations

You undoubtedly deploy outstanding hardware when you onboard new hires. That means your QA testers are likely to use brand new, high-end machines with more than enough speed and copious amounts of RAM. The thing is, the chances are just as good that your users are not using equipment that’s nearly as new or cutting-edge.

Making sure the testers have access to virtual environments that more closely simulate real-world computing scenarios is key to a well-rounded QA process. And giving them enough time to thoroughly thrash the new code in those environments is what will ensure that all possible bugs are found early and fixed pre-release.

contact us

General Tips and Tricks for Better QA Results

Let’s move on from specific missteps and solutions to a more general look at QA and how you can be doing it better. Adopting as many of these tips as you can means that, over time, your QA process will continue to improve. And that means your products will continue to be top-notch, and your customers will remain happy.

Find the right mix of manual and automated testing

As a general rule, usability and exploratory testing are better done manually, while performance testing is a perfect candidate for automation. You can run your regression and load testing overnight when demand on your network is low. Then, you can have your testers manually conduct the usability testing within their sandboxed environments.

Stay agile

Agile methodologies incorporate QA testing into the design and development cycle. Unlike other systems where it stands alone off on the side, making it easier to overlook or skip altogether. A collaborative approach that includes testers and users alongside developers ensures a process that will turn out the best possible product while shortening the development cycle.

Consider crowdsourcing

You might have noticed that we mentioned users in the last paragraph. That wasn’t a typo. A growing trend in QA is for companies to crowdsource a final round of testing. By taking advantage of the communities that sometimes grow up around software solutions, these companies  are able to reach out to power users, share beta copies of the next update, and ask them to provide feedback on their experiences. There is simply no better way to get a large number of testers on a wide range of equipment and with a broad range of perspectives all working on your product at the same time.

Take the time to design thorough test cases

Stress tests, load tests, and regression testing are all necessary pieces of the QA puzzle. But just as integral are the cross-platform tests, integration tests, and so on. By taking the time at the beginning of the cycle to lay out test cases and document how they’re going to be approached, you can avoid the headache of a bug slipping through the cracks later in the process.

 

Additional QA Solutions for SMBs

What if, after reading all that, you’re wondering how on earth you’re supposed to find the time in your day to even begin building yourself a strong QA team and set up the processes that will lead to success in this arena? Never fear—as always, there are service providers ready and waiting to help out.

Testing as a service

This is a general category of service partners that you can hire to conduct your testing. They usually operate on one of two models: automated testing or outsourced human teams. In the first case, you upload your code via a secure connection, and results are returned within a set time. In the latter case, your testing is conducted by a real-life team of testers, usually located in an outsourcing office somewhere up to half a world away.

What you can’t always know, in either scenario, is how accurate the tests actually are. Is the software programmed to follow all the nuances of your codebase? Do the human testers have any certifications that prove they know what they’re doing? How about the security of that upload link?

Near-shoring

A newcomer on the outsourcing scene, near-shoring aims to provide solutions to those issues. By locating your testing team in a country in your same time zone (or at most 1 or 2 hours away), the time lag is eliminated. Communication is also simplified when you can call the office during regular business hours instead of in the wee hours of the morning or after dinner.

Your near-shoring partner should also be able to guarantee a common language for all communication, removing even more friction and making the process of back-and-forth smoother for everybody.

All of this goes to show that while there are plenty of ways to mess up QA testing, there are even more ways to get it back on track and provide the accountability and reliability you and your customers need to ensure the best experience possible using your product.

 

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

Tags: Quality Assurance

Mark McLoud

Written by Mark McLoud

I was raised in a rural town in the state of Iowa where I learned the value of hard work. My passion is working hard for my clients and colleagues with enthusiasm, responsiveness, and creativity. As the late, great Vince Lombardi once said, "The harder you work, the harder it is to surrender."

Contact Us