5 reasons changing performance platforms shouldn’t be scary
Change doesn’t have to be scary. This eBook shares tips to ensure you have a smooth migration to your next performance testing platform.
One of the major steps in our 8 Step Guide to Modernizing Your Testing Organization is selecting the right operating model for your testing team. Why? Because this is were you determine how your testing organization will actually run. This is where you’ll establish accountability and communication needed to continue testing innovation and maintain best practices.
But which model should you choose? After evaluating the testing organizations of 85 Fortune 500 companies, we’ve noticed that they tend to be structured based on one of three models. This article will focus on the three common operating models we see in testing organizations and the strengths and weaknesses of each approach. You’ll learn about the models that other companies are using so that you can choose the one that’s right for your organization. Before you go forward, make sure you already have in place the Vision, or baseline, for your transformation plan.
The operating model defines the structure of your testing organization and the way it will be embedded in your enterprise to deliver the greatest value to its customers. A set of roles and responsibilities will dictate how the organization will be run with the goal of having the greatest possible impact on your testing transformation.
So, how do you want your transformed testing organization to run? In evaluating the testing organizations of 85 Fortune 500 companies, Tricentis has determined that they tend to be structured on a centralized, decentralized, or hybrid model. Each of these models has distinct advantages and disadvantages that you should consider carefully before you commit. You should also be prepared to adjust your model to the unique needs of your organization.
In a centralized model, all testing-related roles are part of a single responsible and accountable testing team. Much like test centers or test factories, this model focuses on all kinds of testing after development. Testers work in a specialized group. Any collaboration between development and the business is specially planned. Most of the time, the development team, testing team, and the rest of the business stick to their own specific responsibilities.
While the centralized model provides definite strengths, it often lacks the speed to keep up with today’s pace of software delivery. It also isn’t designed for the kind of collaboration on which continuous testing organizations tend to thrive.
Although the centralized model has proven valuable to countless companies, it’s not ideal for organizations that are implementing continuous testing at an enterprise level. Consider that if the testing team is seen as holding sole responsibility for continuous testing, they may struggle to recruit other teams across the organization to participate.
The decentralized model is, in many ways, the opposite of the centralized model. The testing is performed in autonomous agile teams and the members of these teams may hold other roles within the organization. These teams are only loosely connected, and some of the testing activities —such as performance testing— may even be outsourced. As a result, the decentralized model is the model least suited to supporting a continuous testing strategy.
Teams that work in a decentralized model have total control over their own testing tools and strategies. On the plus side, they can implement testing quickly and work efficiently with a lean team. But because these teams are autonomous, they may or may not decide to implement the tools, strategies, and processes needed for continuous testing.
The organization will have little ability to mitigate the risk incurred by decentralized teams—and these teams will not be accustomed to engaging in the kind of cross-team collaboration that is at the heart of continuous testing. Any organization implementing continuous testing in a decentralized model will need to think carefully about establishing governance to ensure quality across autonomous teams.
In a hybrid model, a small team of experts is accountable for the testing strategy. The hybrid model delivers the best of both worlds: a streamlined quality approach from the Team level to the Enterprise level, with ownership of the test strategy and tooling held by a centralized team. Test execution is done by shared agile teams that collaborate to achieve common goals.
The hybrid model is a highly efficient approach for implementing enterprise continuous testing in your organization. It balances the competing needs for agility, flexibility, cost reduction, and risk mitigation. In the hybrid model, there are clear priorities and shared responsibility between the Enterprise Enablement team—which is responsible for strategy and implementation—and the execution teams.
The Enterprise Enablement team includes Test Architects and Automation Engineers. Depending on how your organization is configured, these experts can work at the enterprise level or on a program-by-program basis. The experts in your Enterprise Enablement team will share several responsibilities across roles:
Define and refine the testing strategy
Set up the testing infrastructure
Build a service catalog
Train the organization
In addition to the Enterprise Enablement team, the hybrid model will include two roles from within teams:
In the recent Tricentis survey of Fortune 500 companies, 35 percent were using a hybrid testing model. When you weigh the advantages of the hybrid model against the drawbacks, it’s not hard to see why the model is nearly as popular as the centralized model.
Compared to the decentralized model, the hybrid model will require more effort to align teams, which can slow down software delivery to some degree. However, we believe the benefits far outweigh this drawback. In continuous testing, multiple teams share responsibility for the quality of the final product. In a hybrid model, these teams can retain a certain degree of flexibility and autonomy, but they’re motivated to adopt a common toolset and embrace common strategies so that they can achieve common goals.
Tricentis has found that the key to achieving success in continuous testing with a hybrid testing model is to employ an Enterprise Enablement team. In our recent survey of Fortune 500 companies, we found that companies that use Enterprise Enablement teams are more than twice as likely to have achieved automated continuous integration. We highly recommend you consider the hybrid model as you implement continuous testing.
The task of choosing an operating model, establishing an Enterprise Enablement team, and implementing continuous testing may seem daunting. If your organization is not sure where to begin, simply focus on making small improvements, measuring your results at each step of the way, and remaining open to changes of direction.
Consider implementing a hybrid model and establishing an Enterprise Enablement team that will focus initially on your most pressing projects. Once your people and processes begin to take shape, you can then begin to make decisions about the technology you’ll need to support continuous testing long-term and your strategy for scaling it up across your enterprise. If you don’t get started somewhere, your organization will never know the benefits of continuous testing.