2 Ways to Standardize QA Practices
Testing can be hard to understand for people not doing the work, and even more so when there are several testing projects running at the same time within a company. This gets even more complicated when each project is using a completely different toolset, language, and reporting status, with different measurements and formats.
At this point, leadership is either happy with product quality and quietly ignores this big blind spot, or they demand complete standardization across projects in an attempt to understand what is happening.
Testing work, much like programming or management, can’t be standardized. But some other important things close to testing can.
Standardize the Process around Testing
The act of testing is driven by everything that happens around it, otherwise known as context. Testers exist in a system of scope, teams, hierarchy, and technology that is, at best, difficult to change. The way we test is a reaction to all of this and to what we learn while working in the product, and because of that, how we test cannot be standardized.
What we can standardize is the stuff that surrounds the testing.
That generally begins with tooling and communication around product quality. If teams are using different tools and workflows for reporting problems, it might be time to center around one tool and possibly one process that everyone can live with. If teams are using multiple toolsets for testing, reducing that number can make projects easier to manage and knowledge easier to share.
The task of testing still fluctuates as it needs to, but it is performed within an understandable framework of tooling and communication.
Include Testing inside Another Process
The more modern way of standardizing and understanding testing is to treat the task as part of software development. Rather than having testers and developers, you have a development group. Rather than having development phases and testing phases, you have a development phase that produces shippable code when it completes.
The standardization in this scenario is woven into the development practice. Programmatic testing—unit tests, API tests, and testing in the user interface—become very important because you want good, changeable code. Testing happens in tandem with development; there is no back and forth.
Rather than reporting on testing progress, you report on the much more important big-picture question of when the code can be delivered. You might have several different product changes happening at the same time, but the conversation at this point is focused on how much time is remaining to deliver.
Process and practice can be personal, but standardization is there to serve the business. Managers want meaningful information as quickly as possible so they can make decisions that affect the future of the project and the company. This becomes slow and tedious when you have five different teams using eight different tools and sending spreadsheets in several different formats.
Centering around a toolset, a process, and a set of practices as much as possible can make development a little easier to understand and manage.
