Testing has become a constant element of most software development processes; however, it is often a secondary issue for software companies. It is not surprising that if somebody wants to be the best at what he does (in this case software development), then he does not necessarily want (nor is able) to focus on other activities. In most cases, tasks which do not constitute core company business are outsourced in order to lower costs and improve functioning.
I have been working as a tester for many years and I often come across the need to justify the costs of testing. Inasmuch as performing simple automatic or manual tests has become kind of standard, more complicated tests and activities are becoming hard to justify from an economic standpoint, so they are pushed to one side during projects. Of course, I am not saying that the situation always turns out like this; however, having years of experience in many smaller-scale projects, I have observed this kind of “craft” management attitude.
Such management of the software development process is based on several talented “tester-craftsmen” on whom the entire test process depends. This is not unequivocally wrong; however it means that all test activities are undertaken by a group of testers who provide manual, automation, security or performance tests, and manage all the tests. The main question is – does such a small team have all the required competences?Especially when you consider that, during the project, eventually there will probably come a time when highly specialized performance or security testers and other experts will be needed, but having them employed on a permanent basis at our organization is inefficient in terms of cost-effectiveness.
Another problem is the fact that the number and type of tasks during the project development phase can fluctuate. The assumption that three employees will always have the same amount of work during the course of the project is just plain wrong. Stoppages and surpluses in projects are a totally natural phenomenon.
In the first case, we can assume that employees with nothing to do will undertake other activities which they don’t have time for during project development, such as putting things in order. At first glance, it makes sense – the only question is whether the activities left at the time are really necessary. It is much better to apply good practices that will not lead to situations where such actions are necessary. Of course, the issue of training and self-improvement remains, but I will leave this case to each company to deal with subjectively.
Much more cumbersome are these “mountains”: for example, with three testers working on a project, our resources are necessarily limited. Let’s assume that our test team was expecting to tackle tasks which had to be delivered. The team has made the necessary preparations, as well as all other activities. Unfortunately, the previous stage of the project preceding the testing stage ran long, and it turns out that the tests which were planned to last two weeks should be done within a week, and it is absolutely impossible to put the deadline back. Therefore, our three employees have to do the work of six people.
What can be done in this situation? We can bring testers across from less urgent projects if possible. Having people do overtime is another solution. However, in this case, the scale of overtime would be very large, far exceeding 50% of regular work time. This will not only increase costs, as overtime means higher rates, but will also lead to testers being overworked. Here we have to remember that an overworked tester will not work as efficiently as a rested employee. This means that even if our team tries to accomplish all of the tasks on time, this does not give us a guarantee of a suitable result.
Therefore, it is necessary to change the way of thinking about how we manage a test team, and look at the employees’ skill levels. A company which uses the craft model needs the most talented tester who has all the necessary skills to work on the appropriate level. However, in the real world, it is difficult to successfully implement such a model.
We have to remember that a specialist who has all the competencies from all specializations probably does not exist. Even a tester with many years of experience only has the competences and skills gained from projects he has participated in. For example, if a tester has 15 years of experience and 10 years ago he was very good at testing, but has not done any testing since then, he doesn’t really have any valid level of competences at present.
In a traditional, craft approach, we only have access to the specific skills of one tester or a group of testers, and not always when we need them.
Another problem is that the challenges associated with software development are getting bigger, and the scope of its use is increasing. It is difficult for testers to be a specialist in every specialization. A tester who is excellent at web testing will not necessarily be a specialist in Big Data testing. Of course, a good tester with basic knowledge should be able to cope with any project – but we have to ask ourselves questions about the effectiveness of his work. One of the methods of solving this type of problem is the testing center of excellence – specialized testing departments which conduct tests as a service for other departments within the company. However, this solution will only be effective if the entire potential of such a department is actually used, e.g. if the company has a wide portfolio of projects that can be supported in this way. Otherwise, such a department will generate excess costs.
Smaller companies, or those that don’t have a sufficient number of diversified software development projects, can solve this problem by deciding on Software Testing as a Service.
Software Testing as a Service is an outsourcing model in which particular tasks are outsourced instead of hiring specific specialists. This means that the recipient does not make use of a limited pool of employee competences, but rather benefits from the cloud of their qualifications. This way, we avoid a situation in which a senior manual tester performs the automatic tests that requires the skills of a junior automatic tester, which unfortunately our manual tester does not have. This is definitely an inefficient use of the employee’s potential.
In this model, tests are provided on demand as and when required. However, tests should be scalable, have a high level of independence, and also not burden the customer with costs related to tools, hardware, software, employee training or building test environments. Using cloud-based tools at work is also common practice.
Thanks to Software Testing as a Service, we can provide all services related to testing: from manual tests, to automation, performance, penetration, or even improvement of the test process, as well as conducting training for the client’s employees.
The form of the service should be as simple as possible for the client. The contract is signed before the details of the service are established. Subsequently, the client should provide all the documents, passwords and other artifacts necessary for implementing the testing process. Theoretically, his role should end at this point. In practice, it looks a bit different, as Software Testing as a Service is still classic testing, so the service shouldn’t be performed without any contact between the client and the service provider. Efficient communication and exchange of knowledge are a must, so that the service provided is of the highest quality. The STaaS service is finalized by presenting the results in the form of a report.
The above scenario is quite obviously a simplification, but the idea of Software Testing as a Service is to provide relief for the recipient firm, to make the form of cooperation most convenient and “trouble-free”.
The IT environment is changing and testing must change with it. It is not possible for the old model with a single “craftsman” tester to solve our problems. STaaS wants to be flexible, cost-effective, and provide the best solutions available for any company regardless of its size. It is a big challenge, but the final effect is worth it.
Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!
Comment