Pruebas de Rendimiento en QA: ¿Tu app está lista para el mundo real? 5b4rv

Hola y muy buenas a todos, bienvenidos, bienvenidas a un nuevo episodio de QA Talks, Calidad para hispanohablantes, el podcast donde exploramos el mundo de la calidad del software en castellano.

Hoy hablaremos sobre las pruebas de rendimiento, un aspecto fundamental para garantizar que nuestras aplicaciones sean rápidas, estables y escalables.

Imaginaos que lanzáis una aplicación y en el peor momento posible, por ejemplo el Black Friday, se cae vuestra aplicación por sobrecarga.

¿Cómo evitamos este tipo de fallos catastróficos? ¿Cómo los prevenimos? Pues justamente con pruebas de rendimiento.

¡Vamos a ello! Antes de empezar a hablar sobre cualquier prueba de rendimiento, antes de meternos directamente en el núcleo del tema de hoy, conviene dar un poquito de contexto y entender realmente qué es el rendimiento.

Es básicamente, digo básicamente, entre comillas así con pinzas, pero es una medida que vamos a utilizar para determinar la eficacia con la que la aplicación utiliza los recursos del sistema.

Bien, yo creo que sí, ¿no? Cómo de eficaz va a ser nuestra aplicación a la hora de utilizar los recursos de los que dispone.

¿Cuáles son estos recursos? ¿Con qué aspectos puede interactuar nuestro programa? Vamos por ejemplo con el uso de la U, vamos a ver y vamos a determinar cuánto consumo de energía y de memoria tiene nuestra aplicación, cuál es el uso de la red o del almacenamiento, por ejemplo, y todo esto y muchas más cosas tienen un coste económico y de reputación con el .

¿Y por qué es tan importante que las aplicaciones tengan un rendimiento aceptable? Pues precisamente por eso, porque los s dan por sentado que la aplicación va a tener un rendimiento, el rendimiento que ellos esperan.

Quieren que las aplicaciones tengan la capacidad de respuesta cuando ellos hacen un clic o una llamada o hacen algún movimiento dentro de la aplicación y espera que ésta les responda sin esperas.

Si ocurre lo contrario, lo más probable es que el se frustre, lo que puede provocar que deje de utilizar nuestra aplicación y eso es lo último que queremos, para proporcionar a nuestros clientes la mejor experiencia posible, lo que necesitamos es asegurarnos de que nuestra aplicación tiene un rendimiento aceptable.

Y claro, ahora mismo os estaréis preguntando, pero Silvia, ¿qué entendemos por aceptable? Bueno, pues muy buena pregunta.

En realidad la respuesta corta es depende, depende del tipo de aplicación, de sus s y del contexto en el que estemos utilizando la aplicación, pero sí que hay algunas referencias comunes que podemos utilizar como punto de partida para definir un rendimiento aceptable.

Y es que el rendimiento no se mide con un solo parámetro, sino que hay varios parámetros, por ejemplo, el tiempo de respuesta es un parámetro bastante socorrido, entre si es menor de un segundo, perdón, que es el tiempo de respuesta, me refiero al tiempo que tarda en recibir una orden y darte una respuesta, ¿vale? Eso es el tiempo de respuesta, bueno, pues si es menor de un segundo, quizá es lo ideal, el siente que la respuesta es instantánea, inminente, si tarda entre uno y dos segundos es aceptable, la mayoría de los s pues no lo percibiría, no percibiría su lentitud o no nos frustraría y si es entre dos y tres segundos, podemos experimentar como s, como humanos, que es lento y si es mayor de cinco segundos, el riesgo de abandono aumenta exponencialmente, especialmente cuando hablamos de aplicaciones web y de móviles.

Otro parámetro que podemos tener en cuenta para determinar si nuestra aplicación es eficaz a la hora del, en el rendimiento, es la tasa de errores, una tasa inferior, una tasa de error inferior al 1% en condiciones de carga normal es normalmente aceptada, pero si hay situaciones de estrés y esta palabra me encanta, estrés, no por la vida misma, sino porque nos va a ayudar mucho a determinar si una aplicación rinde o no, bueno, pues en situaciones de estrés se puede aceptar una tasa de error un poco más alta, pero siempre que esté monitorizada y justificada, quizá esto lo vayamos a ver un poquito más adelante cuando hablemos de las, de los test de rendimiento, los performance testings que también los podéis haber escuchado así. Vale, otro de los parámetros es el uso de recursos que lo veníamos hablando, cuánta U consume, la memoria RAM, las bases de datos, el tiempo de consulta, etcétera. Y un último parámetro que también es bastante, como bastante común es el de la escalabilidad, si el sistema.