Pruebas tempranas de performance

Si se tiene la premisa de que los defectos son más baratos y fáciles de corregir en etapas tempranas del proyecto, ¿entonces por qué las pruebas de performance se dejan al final?

Las pruebas de performance se han enfocado en generar un gran número de peticiones, y ¿qué pasa del otro lado, todo eso llega al servidor, cómo lo monitoreamos?

Imaginemos un asesino a sueldo, con el objetivo de "matar" la aplicación/servidor, ¿quién sería más efectivo? Aquél que hace un desastre y demasiado daño colateral por el desperdicio de municiones (recursos de red y hardware) o aquél que dispara sólo las municiones necesarias a objetivos específicos.
¿Cómo seleccionamos nuestras armas (herramientas), las configuramos correctamente?

¿Nos preocupamos por el desempeño de la aplicación, o sólo del servidor?.....y al final ¿todo se arregla a fierrazos (agregando más procesadores y memoria)?

¿Y qué pasa con las bases de datos, las involucramos en las pruebas de performance? ¿Nos sirven las mismas herramientas y la misma estrategia de pruebas?

Acerca del conferencista

Miguel Angel De León Trejo
Quality Assurance Manager en Intellego. Ingeniero egresado de la Universidad Nacional Autónoma de México, 6 años de experiencia en el aseguramiento de calidad y testing. Asesor de carrera y formación de talento en prácticas de testing.