Testing and test automation have in the past been seen mainly as one part of software development. With the development of digitalisation, the topic has become familiar to almost every company. In many cases, testing and safeguarding processes that are critically important to businesses have come with the systems purchased, almost as a surprise to the purchaser. For example, when switching to cloud-based systems, it may not have been possible to predict how big and permanent the change in testing would be.
The situation is made more difficult by the fact that to the extent required, the topic is new to many companies – there is no existing testing culture or practices that can be scaled to meet changing needs. Test initiatives have been handled in the past under the guidance of a few system experts, and have often focused on very specific and known changes. No large-scale and regular regression testing has been performed in the company, or it has been done very rarely.
When system vendor version updates suddenly start running at least quarterly and all testing has to be done within a few weeks, however, previous practices and resources are no longer sufficient. The challenge is made more difficult by the fact that there are usually only a handful of people who know the business processes of the systems well enough, and these are largely business experts. They may have a good understanding of the processes to be tested, but in the long run they can’t be burdened any further with testing without it having a negative impact on their other productivity.
With the difficulties described and the increasing testing load, it can be quickly concluded that help is needed for testing. Moreover, test automation is more likely to be considered a more sensible approach than having a large group of testers.
Awareness of the need for test automation is often a long way from a situation where automation handles any whole part of the company’s testing needs. One clear bottleneck is identifying and acquiring the necessary resources. If it was previously difficult to outline the overall test and the amount of testing required without systematic work on the topic, outlining all the requirements of test automation is even more difficult. Suddenly, there should be answers to what kind of skills are needed, how much they are needed, how long they are needed for, where they come from, and how much they cost.
Typically, an automation deployment project involves some form of planning and preparation process. The scope of this is often directly proportional to the initial situation of the company in terms of testing. The end result is at the very least a test plan, sufficiently detailed use cases, and a technical analysis of the processes to be tested and their suitability for automation. In addition, test environments, users and data are required. Finally, it is decided how things will be prioritised, monitored, reported and responded to, and where all this will be managed. This is a lot of different things to know, even when shared by multiple people.
As technical performance is achieved, the need for different capabilities increases. The technical implementation of the project requires infrastructure experts, software developers and test automation experts. Alternatively, it is possible to choose a commercial product to handle some of the challenges.
Often, the amount of skills required is so difficult to determine in advance that after a procurement or recruitment decision, the company ends up seeking a mixture of consultants or individuals without knowledge of the actual need for skills. Recruitment processes are then unnecessarily cumbersome, time-consuming, and the progression of test automation from the deployment decision to the start-up phase can be several months – and several test cycles – away.
Testing as a Service
Imagine choosing a previous type of procurement model, for example, in terms of construction. The established operating models are ignored, and the necessary resources are calculated for the next three years with the aim of having the premises renovated. All the needs are successfully planned and procured for. Sure. Difficult, and most likely also quite slow, expensive and risky.
What if the setup is reversed – what if testing and test automation projects could be ordered and delivered like plumbing repairs? Or how about breaking it down into even smaller parts. Why buy an entire project at once if you only need a smaller single part to start with, one that brings things forward by a controlled amount at a time.
The customer buys it as a service, and the supplier makes sure that the customer always has the core skills needed at that moment in the current work phase of the project. Work and costs can be paced in an agile way with the most suitable schedule and capacity for the customer. In some situations, the service may be a few people who are constantly needed in the project, and the number can be scaled to suit the situation as necessary. In the second case, it could be one common human resource model where the work input is given today by a test manager, tomorrow by a cloud expert, and next week by a test automation developer. In the third case, for example, a fixed-length sprint of two weeks to one month can be agreed, in which the supplier jointly submits a work performance based on a defined workload estimate and is responsible for its implementation (= renovation). In all cases, the service scales up and down. According to the need and the situation.
Get agile test automation as a service from Gofore
Speed and agility are directly included in the Gofore operation model. Subscriber is not bound to anything more complex than a single kiosk purchase which can be, for example, a specific training course or the automation of a single use-case.
Invoicing is carried out only when the process is in progress, and the supplier ensures that the right kind of expert is always available. Instead of one person, there is always a bigger team behind the implementation, with all the necessary expertise needed at any point during the project.
