Testear Software no es pegarle al teclado

Trece años atrás había que convencer a los responsables de cada proyecto de desarrollo de software para que incluyeran recursos dedicados al testing dentro del equipo de proyecto. Había un trabajo fuerte de evangelización cuyo objetivo era generar conciencia en la gente sobre las bondades de hacer testing y más aún, testing independiente.

Hoy eso no es necesario. En todos lados tienen claro que el testing es importante pues ahorra dolores de cabeza posteriores y dinero. La discusión por estos días está en cuánto es razonable pagar por el testing y es por eso que se escucha/usa mucho la frase "el testing de software se comoditizó".

Pero ¿qué quiere decir esto?

Extraigo de wikipedia sobre comoditización:

"Se dice que se produce una commoditization cuando unos bienes o servicios pierden diferenciación entre su base de proveedores, en ocasiones por la estandarización y difusión del capital intelectual necesario para adquirirlo o producirlo de forma eficiente. De esta manera, productos o servicios que en un momento han podido suponer una ventaja competitiva y que por lo tanto eran altamente rentables por sus altos márgenes, se han convertido en commodities perdiendo su diferenciación."

Cuando se dice que el testing como servicio (o producto) se comoditizó, se quiere decir que se transformó en un commodity. Y un commodity es un servicio (o producto) que no tiene diferencias entre competidores. Otra vez wikipedia:

"Una commodity, en inglés el término original, es un bien o servicio para el que existe demanda, pero que es provisto sin gran aportación de valor por el mercado. Se trata de un producto o servicio que es el mismo, no importa quién lo provea, como el petróleo, papel, leche o la electricidad. Una de las características de un bien que es una commodity, es que su precio viene determinado en función de su mercado completo. Algunos casos de mercados propios son los de productos agrícolas como el arroz, la sal, el azúcar, el café. Pero también de otros productos como el oro o la plata."

El problema que se le plantea a los proveedores es que dejan de competir por diferenciación y empiezan a competir por precios (recordar a Kotler: o somos diferentes o somos más competitivos). Esto achica los márgenes y presiona la estructura de costos. Estar en un mercado comoditizado es todo un problema para los proveedores.

Pero también lo es para los clientes y es aquí a donde quería llegar.

En un mercado comoditizado el proveedor está obligado a achicar costos para poder conservar márgenes. En testing esto significa buscar recursos más baratos y esto, muchas veces, significa menos capacitados. El cliente sufre estos ajustes pues la gente que testea es menos productiva, efectiva y eficiente.

Y entramos en un círculo vicioso entre clientes y proveedores que deriva en una disminución del nivel de calidad en el servicio. En testing esto se ve en el nivel de exigencia para con la capacitación que un tester debe tener, la forma en que una aplicación se debe probar y los tiempos que estas pruebas deben llevar.

Hay mucha gente que, producto de este deterioro, llega a pensar que hacer testing de software es pegarle al teclado de alguna forma para encontrar errores, que poniendo a cualquier a usar la aplicación se está testeando, que utilizando gente sin formación o experiencia en informática o con formación específica se logran los mismos resultados. Para poder pagar menos, tenemos que exigir menos.

En toda disciplina con cierto nivel de madurez (el arte de testear software fue escrito en los '70) es esperable un cierto grado de optimización pero hay que tener cuidado y no exagerar. En muchos casos, llevar al límite estas optimizaciones (o recortes) solo produce más costos al final del día (al poner el software en producción, al tratar de hacerle cambios durante el mantenimiento, etc.).

A veces pienso que estamos exactamente en el lado opuesto al que estábamos 13 años atrás pues creemos que cualquiera puede testear y que lo que era raro e inentendible hoy es común y simple.