Errores comunes que se pueden dar en un proceso de pruebas de rendimiento y cómo prevenirlos

Las pruebas de rendimiento son aquellas que se ejecutan para determinar lo rápido que se realiza una tarea bajo unas condiciones determinadas. Pero en algunos casos, no se ejecutan adecuadamente. En MTP somos especialistas bien formados en todo lo relacionado con el aseguramiento de la calidad de software (QA) y en las tareas complejas que conlleva, y con nuestra experiencia e información sobre la materia vamos a relacionar algunos errores que pueden obstaculizar los trabajos en este ámbito de las pruebas de rendimiento.

Errores comunes en pruebas de rendimiento

Explicamos a continuación casuísticas y los consejos que dan algunos  testers experimentados, para subsanar posibles errores. Aquí van algunos fallos comunes.

– Planificación inexacta: Algunas organizaciones no incluyen consideraciones de rendimiento durante las primeras etapas de desarrollo. Esto puede generar problemas durante las siguientes fases del ciclo de desarrollo del software. La planificación de cada actividad es crucial. Hay que tener en cuenta que un proceso de correlación de los equipos, es complicado, y la mayoría de las veces, requiere tiempo y esfuerzo.

– Modelo de carga de trabajo incorrecto: La elaboración del modelo de carga de trabajo sin errores, es uno de los primeros pasos que hay que seguir para determinar los problemas de rendimiento. Los modelos de carga de trabajo proporcionan información, como, por ejemplo, que tipo de acciones realizará un usuario bajo un nivel de carga determinado, cuáles serán los escenarios de negocios para todos los usuarios y la distribución de los clientes en cada escenario.

– Entorno de prueba poco realista: Elegir un entorno de pruebas de rendimiento puede resultar un reto y requiere de grandes esfuerzos tecnológicos y organizativos. Si el entorno de pruebas no es realista, los resultados no serán precisos.

– Ausencia de documentación (registro): Repetir escenarios y comparar los resultados de varias ejecuciones entre los escenarios son importantes en las pruebas de rendimiento. Por eso, puede ser molesto cuando hay muchos escenarios y usuarios virtuales, pedidos. Precisamente por eso, hay que reportar los avances y resultados preliminares del proyecto en cuestión en la bitácora.

– Saturación de la máquina generadora de carga: La falta de capacidad o potencia del hardware o demasiados usuarios virtuales que interactúan con la aplicación, puede hacer que sobrecarguen la máquina generadora. El resultado será negativo en los tiempos de respuesta. Para evitarlo, debemos de tener muchas máquinas generadoras de carga, y así, distribuir correctamente el modelo de carga.

– Resultados Inexactos: Puede ocurrir que los resultados sean inexactos, por eso, hay que asegurarse de tener un conjunto de métricas e indicadores en servidores donde se encuentran alojadas las aplicaciones que se están ejecutando. Estos indicadores tienen que estar monitorizados con las pruebas de rendimiento lanzadas.

– Falta de comunicación: La comunicación es vital en un proyecto y la falta de ella es perjudicial, sobre todo cuando se trata de desarrollo software. La falta de comunicación en el equipo, o con la persona enfocada en QA hacen que la calidad de este se resienta. Pero no solo es la calidad. Si en un proyecto, un equipo en el que haya mal ambiente o falta de comunicación, dará como resultado un producto fallido también.

– Separar desarrollo y testing, pero con cabeza: ¿Cuántas veces desarrollo acaba una funcionalidad y se la pasa a testing para probar? ¿Cuántas de esas veces salen errores básicos que se habrían podido evitar si desarrollo hubiera hecho unas pruebas básicas? Es normal que, dentro de los equipos, se dividan las tareas porque son dos cosas distintas. Cada paso que se da a la hora de desarrollar un producto sirve para algo, todo cuenta. Tenemos que tratar de entender y aprender lo que hacen los demás. En ocasiones, debemos sentarnos con un compañero y que nos explique lo que está haciendo en esa parte del proyecto, o realizar reuniones para compartir información entre el equipo, que afiance, no sólo en las relaciones, sino que, además, la repercusión será positiva en el producto final.

– Dejar las pruebas para el final: Dejar las pruebas para el final sólo traerá problemas a lo largo del tiempo y alargará el tiempo de desarrollo.

Ver más historias