You are here

Tweaking Six Sigma and BPM tools for QA

public://pictures/areichertpropix.jpg
Amy Reichert, QA Engineer, RxMxUSA

Business process management (BPM) tools and processes like Six Sigma are business management aids that organize results in order to improve processes and productivity. The idea is to reduce waste in workflows or team processes and improve business productivity. BPM tools also provide metrics and dashboard views that allow managers to display results. You can use these for other business areas, so why not use them to improve QA processes and productivity?

BPM tools can be configured to provide metrics for and from QA. Analyze these tools and see if QA can improve as part of the software development team. QA doesn't have to be a bottleneck that the larger organization must survive; it can be the center of quality and productivity. Let's discuss the business gains of using your existing BPM tools to improve QA processes and the quality of testing overall.

[ Learn how to apply DevOps principles to succeed with your SAP modernization in TechBeacon's new guide. Plus: Get the SAP HANA migration white paper. ]

QA process improvement: The key is organization

The biggest problem in QA organizations is the lack of organization. I'm talking about simple organized procedures, processes, and methods of testing and reporting issues. This applies to large or small companies. In my experience, QA is where it all falls apart. Even if other pieces of the software development puzzle are well organized, QA is generally not organized at all or organized minimally at best. This may be because the pressure is always there to do more with less—that is, to test a growing number of configurations and platform variations faster and more thoroughly, with fewer resources. It's that cloud always hanging over QA's head because they simply can't test fast enough. And the cloud only gets heavier and darker when a poor quality customer experience gets blamed on QA, even though the entire development team is responsible for quality.

Never mind that QAs never write a line of code or actually create a defect. If the QA team isn't organized, they can't provide the test coverage they're capable of. Multiple QAs may be testing the same thing and never know it. Or perhaps everyone is testing the same area and avoiding the more defect-prone sections of the application. Or, frequently, everyone is testing superficially and not digging deeper into the application. QA and testing can be drastically improved with basic process organization—in other words, knowing what is being tested, by whom, on what platform, and at what depth. This is in the spirit of Six Sigma.

[ Is it time to rethink your release management strategy? Learn why Adaptive Release Governance is essential to DevOps success (Gartner). ]

QA metrics

Metrics for QA are a dilemma. What do you measure? The productivity of each tester or the number of defects customers report? None of that really matters. Customers may find defects that QA doesn't because of configuration variability and platform differences. QA typically tests only on one known configuration pattern or several undefined configuration patterns. There are so many possible configuration settings in most applications that planning and deciding which one to test is critical.

But does it happen? Not typically. More likely, the QA environments are built in one flavor, maybe two at most, and each tester alters the configurations as needed for their own uses. On the other hand, customers often have several hundred configuration variations, sometimes thousands. Add platform and hardware differences, and the number of variations to test can increase exponentially.

For example, the figure below, shows how the Six Sigma DMAIC pattern can be used to create an organized process flow for the QA team.

Define, measure, analyze, improve, and control steps from Six Sigma can guide testing teams in their planning.

Development teams need to measure testing coverage to determine how much of the code is covered by unit or QA testing. Find out and define what configurations customers are using and whether or not you're using a test environment that is similar. Measure what tests you're running and in what area of the code. Measure the amount of testing that's done in each functional area. Are you testing in the defect-prone areas? Measure testing depth. Are your testers given enough time to focus on finding defects and breaking the software, or are they simply trying to survive and prove the happy path functions as expected? Measure to improve, but measure what matters.

Reuse and reduce waste

Six Sigma and BPM tools help manage business processes in a predictable, presentable fashion. Tweak your existing tools and use them to improve QA. Even if your QA is perfect, you can find duplicate processes or overlooked areas. Find out how deep your testing goes—customers will dig in, so make sure you've covered the depth necessary to find defects before release.

One of the best things BPM tools offer is the ability to use historical data and analyze it in order to improve. Granted, it may take a quarter or two to generate enough data to analyze. However, the more data you have, the more real that analysis will be. Analyze and find the problem areas or weak spots and create a prioritized list. What to fix first is determined by the data analysis and the improvements that will create the highest quality for the end user.

Image source: Flickr

[ Get Report: Buyer’s Guide to Software Test Automation Tools ]