3 Ways to Improve your QA Process

May 24, 2016 by Ryan Quellhorst

And Testing.
Lots and lots of testing. 

The responsibility of the Quality Assurance (QA) team might not seem the most exciting in the software development life-cycle, but it's certainly one of the most important. A thoughtful QA process will prevent defects in an application before they happen. With such a crucial role, how can you and your team better the process to reduce business risk and maintain visibility throughout the development life-cycle? 

1. Use automation for your regression tests

The dreaded regression tests, it’s what the QA team does every project to ensure new functionality didn’t break the old functionality. For larger applications this might involve thousands of tests, and believe me your QA team is tired of performing these repetitious tasks.

For recurring testing (such as regression tests), it might be smarter to automate these tasks. There could be more work upfront, but there will be significant gains with each iteration of testing. When automating, identify the tests that give the greatest value such as,

  • Tests that are prone to a high level of user error (e.g. testing complex calculations)
  • Tests that are data heavy (require two or more data sets)
  • Tests that take a lot of resources (time, effort, multiple personnel, etc.) to manually test
  • Tests that contain functionality that is high risk

Once you automate your regression tests it will free up you testing team time to do other tasks such as exploratory testing. It could also allow you to complete the testing phase of the Software Development Lifecycle (SDLC) ahead of schedule or allow you to shorten the testing phase when you are planning for your next project.

2. Test your requirements

We’ve all been on projects where more time is spent on rework than actual development itself. Whether its defects due to ambiguous requirements, rework do to the product not meeting the business’s expectations,  or the requirement is not feasible, among many others things. Poor requirements can corrupt the rest of the project, and it leads to a lot of hardship and headache later in the project.

Many problems that a project has later on can be mitigated early on by testing your requirements. This might sound like an odd concept as we usually associate testing with product testing. Requirements testing is a review of the requirements documents (Functional, System, and Business Requirement Specifications) in order to identify defects early in the SDLC. Some attributes of a good requirement include:

  • Correct
  • Complete
  • Unambiguous
  • Testable
  • Solution Independent
  • Objective Driven
  • Traceable
  • Singular
  • Prototype

Your QA resources can check to see if your requirements contain these attributes and raise concerns when they don’t. The result of testing requirements is not to fill up binders with thousands of pages of detailed design specifications on how the product should do it, but it should drive a better understanding of what the system should do.

3. Leave time for exploratory testing

If you are unfamiliar with exploratory testing the process is exactly how it sounds. Exploratory testing allows the QA analyst to explore the product’s functionality without the aid of test cases. The analyst combs through the application in search of defects that were unaccounted for during test case execution. This might sound a bit like the Wild West, but exploratory testing is vital to releasing a good product.

User Experience testing is a great example of where exploratory testing can be a powerful tool for a QA analyst. It is very difficult to map out every path and ever procedure that a user might take while using your product. Exploratory testing can bridge the gap between the functionality tested using the test cases, and the fringe scenarios that the user might explore.

Exploratory testing also capitalizes on the different experiences that your analysts have. Each analyst has different backgrounds and experiences which allows him/her to view testing in different ways. Analyst are given the freedom to explore promising defect indicators, and not be constrained by the procedures of a test case. Exploratory testing allows the analyst to think in his/her unique way which might lead to an uncovering of different defects than other analysts on the team. 


Load more comments