Errores más comunes al realizar Pruebas de Performance – Parte I

En esta primera parte (de la que serán varias entregas 😉 ) vamos a estar repasando algunos de los errores mas típicos al momento de realizar pruebas de Performance sobre una aplicación. Algunos de los errores que van a ver fueron sacados de la Web y el resto son por experiencia propia.

Si bien algunos puntos pueden llegar a discutirse, la lista es la siguiente:

Error 1: Arrancar tarde con las pruebas

Este es el mayor de los errores que me ha tocado vivir, no por decisión propia, sino porque las empresas se acuerdan de las pruebas de Performance una vez que entregan el producto al cliente y el cliente se queja por los tiempos de respuesta altísimos de la aplicación. Otra de las razones por las cuales se arranca tarde es porque confunden el Performance Testing o Load Testing con el Testing Funcional, lo cual es un grave error.

Las Pruebas de Performance o las Pruebas de Carga pueden realizarse sin que la aplicación este estable o este terminada la interfaz de usuario. Como mayormente (cerca del 80% de las veces) los problemas de Performance residen en la arquitectura o tecnología adoptadas descubrirlo una semana antes a la entrega puede causar dolor de cabeza a más de un PM o Vendedor ya que el costo del error es altísimo, provocando cambios en fechas de entrega y desconcierto en como solucionar el problema. Para poder visualizar estos problemas desde el comienzo existen practicas como PASA o planificar las tareas de performance como cualquier otra tarea paralela al desarrollo de la aplicación con objetivos y metas los cuales pueden ser administrados. En cuanto a que primero se necesita tener una aplicación para luego hacer pruebas de Performance, hay que tener en cuenta q las herramientas de Performance solo necesitan un servidor que pueda manejar las peticiones HTTP para los caminos más importantes, no es necesario que tenga una linda interfaz o cualquier otra cosa que tienen comúnmente las aplicaciones Web por lo que las pruebas podrían planificarse para ser realizadas a medida que avanza el desarrollo para que el costo de los errores sea menor.

Error 2: Pensar que puede ser realizado por una sola persona

Este es un error muy típico de aquellos tester funcionales que quieren incurrir en otras técnicas (es una muy buena actitud 😉 ) o reciben la orden de algún PM (con poco conocimiento técnico del testing o que recibió ese pedido del cliente y acepto sin conocer) y creen  que las pruebas de Performance pueden ser llevadas a cabo por una sola persona.

En cada caso nos podemos encontrar con los siguientes problemas:

• No se cuenta con la capacidad necesaria: Para realizar las pruebas es necesario tener un conocimiento de la herramienta que se utiliza, las técnicas y metodologías junto al conocimiento sobre las pruebas de performance en sí.
• Desconoce el código: Es necesario que la persona que desarrolló el código que causa los problemas de performance forme parte de las pruebas para que ofrezca un análisis del problema y posibles soluciones.
• El ambiente en que corre las pruebas no es el indicado: Sin la ayuda de las personas a cargo del hardware de la empresa puede ser que las pruebas se desarrollen sobre un servidor que genere resultados totalmente erróneos con la realidad de la aplicación.

Error 3: Confundir Load Testing con cualquier otra cosa

Las pruebas de carga básicamente apuntan a verificar la performance de la aplicación o sistema, bajo una carga de trabajo en simultáneo.

Load Testing esta muy lejos del Testing Funcional. Ya que las metas de cada tipo de prueba son diferentes, las habilidades necesarias para realizar las pruebas son diferentes, los casos de prueba son diferentes, las herramientas y tecnologías son diferentes, casi siempre la metodología del proceso de pruebas son diferentes.

Load Testing no se trata de verificar la performance de la aplicación ante un solo usuario. Es obvio que los tiempos de respuesta de un camino end-to-end no van a ser los mismos si en la aplicación se encuentra realizándolo un usuario a que si se encuentran mas de 1 usuario. Pero hay que tener en cuenta que el componente que es el cuello de botella o baja en performance de la aplicación puede ser distinto cuando hay un solo usuario a cuando hay mas de un usuario.

Load Testing no tiene por objetivo principal encontrar errores por concurrencia. Cuando varios usuarios llaman a concurrentemente al servidor puede ser que no existan problemas de Performance pero el servidor puede estar realizando acciones equivocadas, por ejemplo, vender el ultimo ítem del inventario a varios usuarios o solamente caer. Por eso, es buena práctica realizar pruebas exploratorias al mismo momento en que se están realizando las pruebas de carga las cuales tendrán por objetivo encontrar este tipo de problemas.

Load testing es una subcategoria de Performance Testing enfocada en determinar o validar la Performance de las caracteristicas de la aplicación bajo prueba cuando la misma es objeto de carga de trabajo simulando el uso que tendra la misma en producción.

Error 4: Confundir el Web Server con la aplicación Web

El servidor Web recibe las peticiones http y rápidamente las traduce en otras clases de peticiones para aplicaciones. La cantidad de tiempo gastado en el servidor Web por si mismo debería ser insignificante (o por lo menos por debajo del milisegundo por petición). Todo el tiempo corresponde a la aplicación  detrás de él.

Además, necesita asegurarse de que la capa del servidor Web pueda manejar el número de conexiones simultáneas requeridas, este numero va aumentando a medida que aumentan los pedidos al servidor, el cliente tiene un pobre ancho de banda, y otras posibilidades….

Pero al final, lo que se intenta testear es lo que esta detrás de la cortina, no la cortina. Esto significa que mientras hacemos Load Testing sobre una aplicación Web, comúnmente no debemos preocuparnos de cosas como: emulando variaciones http, enviando peticiones http a páginas o imágenes estáticas, o cualquier otra cosa que sea manejado por el Web Server y no por la aplicación. Otra cosa con la que no debemos distraernos son aquellas aplicaciones que realizan mediciones sobre el Web Server (MindCraft’s WebStone, SPEC’s specWeb96 o ZDNet’s WebBench) ya que son para testear Web Servers, no Aplicaciones Web.