Six myths about buying testing services

In this article, Testimate’s Juha Karvonen debunks six common myths about purchasing testing services.

As a member of the Testimate sales team, I talk to customers a lot. I engage in discussions with companies at various stages: some are initially interested in purchasing testing services, others are struggling with the purchase decision, some have decided to decline the offer, and some provide feedback on a project that has already been delivered.

The same themes often recur in discussions, such as uncertainty about purchasing testing services. Companies—or more accurately, company representatives, with whom discussions are held—have assumptions, prejudices, and even fears about purchasing consulting services.

In this post, I will address some of the most common, annoyingly persistent myths about purchasing testing. Which ones have you encountered yourself?

“Now is not the right time for testing”

Well planned is half done – this also applies to testing. It is a good idea for the tester to be involved in the team already at the planning stage, before active development work begins. Development planning takes time, and testing should not be started without planning.

The right time for testing is when the developer has created usable code and there is a deadline for the product release. In other words, when the product is being developed with the specific goal of release.

Testing – and fixing errors – is more cost-effective the earlier it is done. Conversely, the later testing begins, the more expensive (in terms of both money and calendar days) it becomes to fix the product’s quality.

“Our developers test their software themselves”

Yes, testing is also part of a software developer’s job – and that’s a good thing. However, developers usually test from a very narrow perspective: testing is code verification and testing of the feature that the developer is currently working on.

When the team is larger and the product is being built gradually, testing must cover the interoperability of components or features, integrations, and data flow, as well as ensuring that new features do not break old ones. More unusual edge cases and load testing, for example, are also on the tester’s to-do list.

The testing consultant also acts as a bridge between the development team and the business team. The tester helps to ensure that the developed product actually meets the requirements of the business processes.

“Testing is a big and uncertain investment”

Testing is sometimes perceived as a difficult-to-understand process that requires a large investment in terms of money and time. This is often due to a lack of awareness of testing needs or an inability to anticipate the benefits of implementing test automation.

If the testing requirements are unclear, work can be started in an agile manner. The situation is assessed, a small proof of concept project is implemented, and further steps are planned.

An agile approach limits the initial investment while providing vital information about the project’s needs, which can be used to demonstrate the benefits of testing.

“Outsiders don’t understand our stuff”

If the product or the process used to develop it is impossible for anyone new to understand, how could the team ever grow or change—regardless of whether the newcomer is a hired employee or an outsourced contractor?

Technical systems, business processes, and operating methods can all be learned. A key aspect of a consultant’s expertise is the ability to rapidly learn and apply previous experience. An experienced consultant has typically seen it all and been through all kinds of situations. Experience gained from various system projects and roles helps you jump right in at the deep end. 

Of course, completely new systems require some learning, but a competent consultant is not afraid to ask questions and seek information independently. During my consulting career, I have not encountered a system that could not be mastered by an outsider.

“Consultants are too expensive”

Yes, hiring a consultant will probably cost more than paying an in-house employee for the same number of hours. But.

1) With a consultant, you pay for what you need. A consultant can be available full-time, part-time, or on a project basis whenever needed.

2) There is no need to commit long-term to a consultant. Once the work is done, the consultant closes their laptop and moves on to solve the next client’s challenges.

3) Consultants are readily available. If time is money, a consultant who meets the team’s needs can be brought on board at the same time as the recruitment ad is published on LinkedIn.

“We definitely need someone with specific experience in technologies X, Y, and Z”

Admittedly, this comment makes this consultant’s head spin time and time again.

Of course, accurate experience is a good thing in principle. However, experience with a specific product or technology is not always necessary, or at least it is secondary.

For example, CRM or database skills can be generalized across product boundaries. The same applies to test automation skills: if you are proficient in a few tools, you will probably be able to master a third one with very little training.

Understanding concepts, grasping the big picture, and applying what you have learned are much more important. An experienced consultant’s toolkit includes the ability to apply knowledge, learn new things, and have a solution-oriented attitude.

I would also argue that, rather than a precise technological match, what is more important is the attitude and compatibility of the expert—both in terms of the product and the customer’s needs, as well as the chemistry and dynamics of the team.

How can I help?

At Testimate, every member of the sales team is well-versed in testing. As a salesperson, my job is to understand the customer’s needs and find the most suitable solution, developer, or team of developers.

If you don’t have your testing in order yet, get in touch. Let’s talk.