Nadie quiere pagar por las pruebas.
por Fran Moreno, Principal QA en Technosylva

Mi carrera profesional ha estado ligada al mundo del testing desde hace muchos años y, durante todo este tiempo, me he tenido que enfrentar a una realidad incómoda: nadie quiere pagar por las pruebas. Probablemente, tú tampoco.

En esta Bonilista intentaré hacerte cambiar de opinión. Puede que el testing no te interese demasiado como disciplina, pero quizás sí como modelo de negocio. Porque, créeme, hay pasta —MUCHA pasta— alrededor de las pruebas. 1 de cada 13 euros que se gastan en desarrollar software, va al testing. Si no te los quedas tú, se los quedará otro.

Antes de nada, un pequeño disclaimer: no soy un genio empresarial ni tengo recetas mágicas. Aunque lideré la creación del equipo de QA en Sngular, estoy seguro de que hubiese ocurrido de cualquier manera. Tampoco quiero venderte nada. Trabajo en una compañía de producto que no tiene nada que ver con el testing de software.

Y en una compañía de producto, el uso del mismo es el modelo de negocio y el testing para asegurar su calidad se considera una inversión. En el caso de las consultoras, lo que se vende es un servicio de asistencia o ejecución de proyectos informáticos y todo lo que no genera ingresos se considera gasto. Así que, si quieres generar un impacto real, debes vender o construir algo que se venda.
 
Al poco tiempo de unirme a Sngular, empecé a darme cuenta de esta realidad después de una conversación con Manuel, director de operaciones en aquella época. Cuando le planteé la posibilidad de montar un equipo de QA. Su respuesta fue directa al grano, sin rodeos. «Si el negocio lo justifica, sí».

El mensaje era claro: busca la manera de que esto se venda y el resto vendrá sólo.

Y ese era el principal problema. Intentar vender pruebas como tal, era como pegarse contra un muro. Ya sabíamos que ni los clientes querían pagar por ellas ni íbamos a convencerles con justificaciones técnicas o frases de gurús de la programación. Insistir con eso no tenía sentido, el enfoque debía ser otro.

Entonces me centré en los mismos argumentos que uso con los equipos técnicos que no hacen testing. No se trataba tanto de hacer pruebas como de ahorrar costes, acelerando las entregas de manera consistente, mantenible y robusta.

TL;DR. Cuando me uní a Sngular en 2016, era el único tester de la empresa. Nueve años después, teníamos un equipo internacional de cincuenta Quality Engineers, divididos entre España, México, USA y facturando 3 millones de euros al año.

Muchos pensaréis que no hace falta leer más. Que ya conoces el final de la historia. Sí, Fran, esto ya lo he escuchado mil veces en charlas, libros y blogs. Fuiste equipo por equipo y cliente por cliente hablando sobre buenas prácticas de testing, automatización, integración continua, detección temprana de errores y todas esas milongas hasta que se convirtió en una práctica asumida.

PUES NO.

Factorial, patrocinador de la Bonilista 755


El informe que debe leer tu manager


Los amigochos de Factorial han publicado un documento que, más que un informe, es un buen punto de partida para entender hasta qué punto la IA va a afectar a tu trabajo.

Si tu responsable aún no tiene una estrategia clara al respecto, deberías reenviarle el enlace para que se lo descargue. Contiene datos actualizados, entrevistas con referentes para contextualizarlos y un montón de información práctica, como una lista de las herramientas más populares o 100
prompts útiles y consejos para hacer que los tuyos sean más efectivos.

Pero, sobre todo, es una excelente excusa para iniciar una conversación con tus compañeros sobre cómo aplicar la IA en vuestro trabajo. Un debate donde todas las opiniones son válidas, la único que no tiene sentido es seguir evitándolo. Puedes descargártelo aquí
✌️
¿Te gustaría patrocinar una Bonilista? Escríbeme a david@bonillaware.com y te informaré sobre disponibilidad y precios.

Ese camino, aparentemente lógico, hubiese requerido una cantidad desmesurada de tiempo y esfuerzo, además, sin garantías de éxito. Por eso decidí seguir otro camino: hacerlo inevitable. Que se firmasen proyectos con QAs embebidos como una práctica obligada en los equipos.

Los comerciales incrementarían su facturación, los clientes recibirían más valor y los desarrolladores verían su trabajo reforzado. Era un win-win claro.

Así que formé a nuestra fuerza de ventas para que incluyéramos QA en nuestras ofertas. Empezamos a llamar a todas las puertas, pero no para hablar de testing sino de ahorro de costes y las consecuencias de la baja calidad, con un lema muy sencillo: «No vendemos pruebas, mejoramos el delivery

A medida que llegaron más clientes y el equipo creció, pasamos gradualmente de vender esos proyectos embebidos a propuestas independientes con su propia propuesta de valor. El testing vendía solo.

El aprendizaje más importante que me llevé de aquella aventura fue que, en una empresa, los cambios culturales deben estar alineados con la estrategia de negocio, pero no fue el único:

  • Empieza por la estrategia comercial, no por los equipos. Es más fácil vender algo nuevo que cambiar la cultura interna sin que nadie te lo pida.
  • El equipo comercial es tu aliado. Quieren vender más, úsalo a tu favor. Dales un buen discurso y material para que hagan su trabajo.
  • Si no te diferencias, compites en precio. Esa batalla la vas a perder siempre. Busca tu mensaje único. Vende valor, no coste.
  • Hazte visible. Da charlas, escribe, participa en eventos. Atraerás talento y te posicionarás como referente.
  • Crea equipo y visión compartida. Intentar hacerlo todo tú mismo no es escalable ni sostenible.

 

¿Y ahora con la IA?

Quizá pienses: «Vale Fran, muy bien lo tuyo en 2016, pero ¿qué pasa ahora con Cursor, ChatGPT o Copilot? ¿Harías lo mismo hoy?».

La premisa sigue siendo la misma: impacto en negocio. Antes, el dolor estaba en la falta de automatización y agilidad. Esos obstáculos siguen existiendo, pero gracias a la IA, es más fácil superarlos. La propuesta de valor debe evolucionar.

Seguirá habiendo bugs, pero por razones diferentes: la comprensión de sistemas disminuye cuando IA genera código que aparentemente funciona, pero nadie entiende. En ese contexto, surge una oportunidad más estratégica: Quality Engineers que desarrollen herramientas de calidad para optimizar la experiencia de desarrollo.

Profesionales que mejoren workflows mediante MCPs, que desarrollen herramientas de análisis, creen agentes especializados, empujen el spec-driven development, implementen sistemas de monitorización y predigan errores.
Mi lema 2.0 sería: «No vendemos pruebas. Hacemos sistemas que se mejoran solos.»

¿Repetiría la estrategia? Sí, pero evolucionada. La transición es clara: de encontrar bugs a prevenir que ocurran mediante análisis predictivo y desarrollo de herramientas inteligentes.

Yo ya no vendo testing, pero si tú pretendes hacerlo, quizás es un buen momento para posicionarse con esta filosofía: mientras todo el mundo usa IA para ir más rápido, usarla para ir mejor. En un mundo donde la velocidad sin control genera caos, «ir mejor» se convierte en una ventaja competitiva.

Con IA o sin ella, los pasos siguen siendo los mismos: encuentra el dolor, posiciónate como solución y vende valor, no herramientas o procesos. Esa es la clave.

No sé si te lo he dicho ya, pero nadie quiere pagar por las pruebas...

 

¿Quieres ayudarme a difundir este texto?

16993 suscriptores han recibido esta Bonilista.
*|LIST:DESCRIPTION|*

¿Quieres modificar tu suscripción?
Puedes gestionar tus preferencias o desuscribirte de la lista.

Copyright © 2011-2025 *|LIST:COMPANY|*, todos los derechos reservados.
_

*|HTML:LIST_ADDRESS_HTML|* *|END:IF|*