PRUEBAS DE PERFORMANCE Y PRUEBAS DE CARGA SON DIFERENTES

Empecemos explicita-mente con decir que las pruebas de Performance y las pruebas de carga son cosas diferentes. Uno debe ser exigente con el uso correcto de términos y debo admitir que estoy algo cansado de estar en situaciones donde la gente pide una prueba de performance pensando en realidad en una prueba de carga. Muchas veces cuando hacen eso me confunden, yo los confundo y todo es confusión.

Esto sucede cuando una o mas de las personas en la conversación, irónicamente no entiende o conoce la diferencia de los términos.

Un poco irónico.

Lo que deberíamos hacer, como nuestro amigo Plutarco dijo (que irónicamente fue mal traducido), "llamemos a una pala, una pala... no una herramienta de jardín". O como diriamos en español, "Llamemos a las cosas por su nombre".

Durante muchos proyectos el cliente me ha pedido frecuentemente usar esa herramienta de jardín, el aparato ese, el dispositivo, o peor aun, piden usar el articulo universalmente referido como "La Cosa Esa".

El punto que trato de hacer, es que, esta mal decir pruebas de performance cuando uno esta pensando en pruebas de carga. Seria algo tan tonto como pedir a alguien que use Office para editar un archivo, cuando en realidad quiere que usemos Word.
Word es un sub programa de la suite de Office. Al igual que las pruebas de carga son una sub categoría de las pruebas de performance. Si no queda claro que es en si una prueba de performance, tengo otro articulo explicando eso AQUI.
Despues de leer ese post podemos continuar con esta letanía mía.

QUE SON LAS PRUEBAS DE PERFORMANCE?

De nuevo, tenemos un articulo donde ya describo esta pregunta al detalle AQUI. Pero para resumir la definición, diremos que las pruebas de performance son una parte de la practica de las pruebas de calidad, donde se intenta validar la reacción de un sistema a un uso en particular.
Dicho uso puede ser variado: orgánico, proveniente de un usuario único, un solo clic aislado o incluso una acción generada por un programador al momento de probar el código.

Una prueba de performance es cuando uno verifica como reacciona un sistema, dada una circunstancia particular, la cual no necesariamente es un escenario de carga, pico, estrés u otras.
El tipo de prueba de performance ha ido cambiando al ritmo de los cambios de la tecnología. Dicho cambio ha generado algo de confusión en lo que una prueba de performance es en realidad.

POR QUE LA CONFUSIÓN?

Al principio las pruebas de performance eran usadas para modelar las capacidades del hardware para un uso particular. Como en antiguas computadoras que podían correr solo un programa o proceso. Incluso en esa situacion la gente confundía las pruebas de performance con la practica de modelado y proyección de capacidad. Lo cual no son en si la practica de pruebas de performance. Prueba y diseño van de la mano, pero son diferentes.

En otra etapa, la practica de las pruebas de performance fue confundida con la practica de optimización de performance. La cual no se enfoca a probar, sino a la actividad que va después de las pruebas de performance usando sus resultados. Tristemente, este es otro ejemplo de como se confunde el significado de las pruebas de performance. Una analogía seria confundir programar con debuggear (o como se diga en español).

En la ultima iteración de avance tecnológico y necesidades de performance, vino la necesidad de probar la reacción de la interacción de múltiples usuarios trabajando en el sistema al mismo tiempo. Este es un tipo de pruebas que comenzó a volverse difícil de probar manualmente debido a que el numero de usuarios interactuando con el sistema rápidamente se comenzó a volver alto.

Esto di a luz a una sub practica de pruebas de performance, conocida como pruebas de carga automatizadas, una sub practica que ha sido últimamente el mayor enfoque en todo el mundo de performance. Generando un interés ciego por parte de muchas áreas de QA que solo se concentran en hacer solo pruebas de carga para cubrir las pruebas de performance, y pensando que para toda ocasión es la mejor opción, y que sera suficiente para mitigar los riesgos relacionados al performance del sistema. Lo cual esta muy lejos de ser lo correcto o una buena opción.

CARGA=CARO

La mayoría de las veces las áreas de QA en realidad no necesitan pruebas de carga dado el riesgo que enfrenta sus sistema. Muchos podrían mitigar el riesgo simplemente monitoreando la reacción del sistema a la interacción de un único usuario, monitoreando el uso orgánico que se da en producción o incluso generando manualmente pruebas pequeñas de carga.

Sin embargo, siguen intentando generar automatizaciones solo para medir tiempos de respuesta y cumplir con una de las verdaderas razones de existir de las pruebas de performance, contando también que es mas lucrativo automatizar (para las compañías que proveen este servicio). Dicho en otras palabras pueden estar tratando de matar una mosca con un cañón. Un cañón que es muy caro. Dado que otras compañías lo hacen así, todo mundo quiere tratar de medir tiempos de respuesta de el mismo modo, lo cual en algunos casos puede ser justificable, pero que en la mayoría es un desperdicio de recursos. Muchos están consiguiendo estos cañones por que un vendedor de licencias para cañones se los sugirió como única defensa contra las moscas.

Mitigar riesgos pequeños de performance siempre con cañones, es caro. Automatizar pruebas de performance y ejecutarlas requiere tiempo, mucho expertise, conocimientos técnicos, inteligencia, etc. Habilidades que la herramienta requiere, la cual a su vez, suele ser cara y requiere mucha mas habilidad y conocimiento.

Encima, otro problema que este modo de proceder ocasiona, es que muchos dependen de la automatización para conocer los tiempos de respuesta de sus procesos. Esto es un proceder erróneo pues así se indica solo tiempos de respuesta que experimenta el cliente, sin dar a conocer el tiempo en el servidor. Ademas de que, de este modo es imposible conocer el tiempo de respuesta de llamadas asíncronas. Muchos siguen tratando de medir tiempos de respuesta en procesos asíncronos de este modo, aunque usted no lo crea... de Ripley.

Por ultima vez, LAS PRUEBAS DE PERFORMANCE NO SON LO MISMO QUE LAS PRUEBAS DE CARGA.

CIERRE

Las pruebas de performance son una practica completa que incluye muchos tipos de pruebas y las pruebas de carga son solo una parte de las de performance. Traten de no confundirlas o intercambiarlas. Es un error considerable usar estos términos de manera errónea. Un riesgo que se trata de mitigar, puede ser resuelto con un tipo de prueba diferente al que fue solicitado, creando confusión solo por un modo erróneo de referirse y solicitar la prueba inicialmente. O simplemente por ignorancia.

Las pruebas de performance se refieren a conocer como está un sistema y la velocidad en que responde bajo un uso particular. Las pruebas de carga son... pues carga. La carga es un tipo especifico de uso. Uno de muchos que puede haber.
No se confundan!

Besos <3

-Señor Performo
Follow @srperf