Justice League of Tests – Cloud Competence, Part II
Justice League of Tests – Cloud Competence, Part II
Testing isn't always easy, sometimes you need to hire a team full of testing superheroes to get the job done well and on time.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
I openly declare that "The world needs a Justice League of Tests," a collection of superheroes, or test teams for special tasks. So we need companies that specialize in tests which are designed to test all kinds of software and do it as well as can be done. I dare say that it is necessary to separate development departments from the ones that deal with tests and create separate companies. Why? So that the companies which are created after such a division could be even more specialized – from the perspective of both competencies and business. Of course, this is an extreme approach which aims to portray a certain idea. If we specialize in delivering software, then software is the priority of the company, and not testing, which means that tests may be of lower quality. But what if quality is important to us? Then we have to find a company for which testing is a priority.
We do not necessarily have to use third-party services because, at the point when our own company is the right size, the creation of a testing center where diversified testing resources will support other departments in specific tasks seems to be a good solution. Of course, it’s also a question of the scale of the tasks at hand, because it is expensive to maintain and there is still the danger that some competencies will not be fully utilized. Even in very large companies, there is often no guarantee that we will deliver as many tasks as possible to take full advantage of our potential. Added to that, the experience of such a testing center will be limited to typical projects for our company only. In the event that we face challenges beyond this range of competence and experience, which exceed the typical range of activities of our company, we are again condemned to mediocrity or an extended recruitment process, the purchasing of new tools, or having to quickly learn the process ourselves.
Software Testing as a Service
One of the models that seeks to address this problem is the STAAS (Software Testing as a Service) approach, as well as MSTAAS (Management Software Testing as a Service) and similar models. Generally speaking, it is a service model which draws on the philosophy of the cloud, not only in terms of the tools hosted in the cloud, but also the so-called Cloud Skills. How does this differ from the classic form of outsourcing, namely hiring two specialists for a defined project? Teams that are built to deliver a service such as tests are built in such a way that they are able to cover the different testing requirements within the project.
Let’s imagine a typical project - two of our testers are working on it, but we suddenly need to increase the intensity of the work. If we have the available resources, we expand the team, and if not, we have several solutions to this problem. One such solution is overtime, which is ineffective in the long run as it increases the cost of operating hours in relation to performance. Another way is to look for people on the labor market, but the chance of finding them in a short time is quite small. So if we are looking for a flexible solution in terms of both time and cost, ultimately only the service model is left. We allocate tasks to the team, which is ready to start testing in a short time, exactly at the moment when it is required.
Additionally, these services are scalable, which means that if one specialist is needed, only that person does the job, and if five are needed, then that’s how many will undertake the project. We don’t have to limit ourselves to the skills of the two particular people in the project, but, instead, we can use the range of skills of the entire team. The efficiency of the work which is undertaken, as well as the cost-effectiveness ratio, is immeasurably improved.
Testing teams in this model use their free time to get themselves ready in order to face the challenges which emerge. They are built around the skill set of the team as a whole so that they are self-sufficient. In addition, these teams have:
- The ability to call on practical experience.
- Their own tools, selected after careful analysis and research on the market and needs.
- The ability to work in the cloud with the aim of building testing environments as quickly as possible, with the most accurate reflection of client environments.
Testing services performed by such a team must be at the highest possible level, because their effectiveness, and more precisely the higher value when compared to the standard model, is the raison d’etre of such a team. They have to be better, faster, and more efficient than others. This is exactly the point of the specialization of a company that builds such teams.
Tests as a Service – Why Not?
Everything seems simple and beautiful. We report to an outside company and present the budget for testing and specific tasks. The company starts testing the right tasks, the best specialists are seconded, and when certain people are not being used in the testing process they develop or work on other projects. When there is a need to increase resources, they are increased, and when work is not necessary we don’t do it (nor do we pay for downtime). We work according to needs, the budget, according to best practices and abilities, while reducing costs. Beautiful? Yes, but as always there are no ideal solutions. There is a big problem here, which is a lack of trust.
Trust in the testing team is critical. In order to perform their duties to the best of their ability, testers must have full knowledge of the business, so the flow of information must be as smooth as possible. But let’s not kid ourselves - passing on the knowledge of processes, products, and also transferring responsibilities outside the organization, is not an easy subject to tackle. For some companies, this is a matter of overcoming a certain psychological barrier, while for others it will be a very serious challenge in terms of security. This is hardly surprising. Not everyone is ready for it, not everyone wants to trust, not everyone can afford to trust - especially in the case of strategic areas which testing software may affect.
An entirely different matter is to break through the barriers related to a completely new service model, something that customers are not familiar with. It is much easier for a customer to hire a specialist for their team in the form of employee leasing, instead of trusting an external service provider and outsourcing the testing process in its entirety. We must remember, however, that the customer usually does not need to fill vacancies in their project, but has a specific problem that must be solved. The problem, in this case, will be to find the best way for testing a given application with limited resources. After all, you do not buy a brewery if you only want to drink a beer. The STAAS model will be increasingly popular as it is rational and optimal in the increasingly specialized business environment.
The final question should be not if, but when we are able to move away from the model of allocating specific people to a given place, replacing it with a model in which we deliver concrete solutions to the problems. As I have shown, it is not always easy, but certainly flexible models of cooperation, in the face of ever more complicated tasks, will be an increasingly desirable solution.
I know one thing: when I have the choice as a tester, to be a Jack-of-all-trades, master of none, or to be a Jedi Knight in my specialization, I prefer being a Jedi Knight. And that, in my opinion, is the recipe for success. In every business.
See the Part I of this article.
Published at DZone with permission of Leszek Zielinski . See the original article here.
Opinions expressed by DZone contributors are their own.