Having built a number of enterprise level QAOps solution one of the strategic design question that comes to mind is – should we architect the solution as a platform or as a service model?
Let’s dive into what we mean by platform and service model.
Platform – If the solution is built in a way that users can use it on their own and won’t need support from QAOps team to use it, the pipeline is built as a platform solution.
Service model – When the users need to work with QAOps support team to use the solution then it is built as a service model.
In an enterprise, the users of the QAOps pipeline are spread across multiple teams. It is used by Testing team, Development team, Business team and many others.
Testing team needs to run their tests using the QAOps pipeline. Within an organization there are usually several testing teams aligned to different projects or business lines. An enterprise level QAOps platform is used by all the testing teams for integrating their automation to the software delivery pipeline. If the QAOps pipeline is built as platform then all the testing teams in the organization should be able to leverage the platform on their own without minimal to no involvement from support team. Easy to follow user interface design and step by step online instruction can facilitate easy adoption of the platform without support team involvement. Each team can then onboard their tests to the pipeline and adopt a centralized QAOps model.
Platform level solutions are available on demand whenever any of the teams need to use it. Onboarding new test suite and triggering of tests are faster as there is no need to depend on any group to provide the service to set it up or trigger it.
QAOps pipeline is often used by Dev teams and Ops teams as well to run their unit tests and integration tests. Building it in the platform model allows these groups to use the pipeline without having to depend on support groups to set it up. Also, they can trigger the tests or it can get automatically triggered without having to ask testing team to run the tests. It helps to increase the usage of automation across the organization and promote continuous testing.
Business teams often need to test to ensure the functionalities of the application are working fine. Platform model of QAOps allows them to use the automation on demand and make it easy for them to use it.
In the service model the usage of QAOps pipeline has dependency on the support team for the QAOps. It often adds delay in process of using the QAOps pipeline. Teams has to wait for the support team to process the request. As the number of users grow for the QAOps pipeline, time taken to respond to the requests can increase unless additional resources are added to the team.
It is an important design decision when planning for QAOps pipeline to build it in the platform model so that it is a self-service solution rather than a service-based solution. While building each of the components of QAOps pipeline, we need to keep this key thought in mind that we design each component in a way that any team involved in the software delivery process can use it on their own with minimal or no support team involved.
As the organization grows and usage of the QAOps pipeline also increases. With the adoption of platform model you won’t need to keep increasing your team at the same pace to support larger user base in your organization.