Transformación digital
Pruebas de rendimiento
¿En quién o en qué confías? Piensa en tu relación con las personas o los productos y dinos: ¿confías en alguien o algo con lo que no has tenido experiencia previa? Hablando más específicamente de productos: ¿confías en ellos antes de realizar pruebas básicas? Dicho de otra manera: ¿comprarías un coche si, al girar la llave o pulsar el botón, no arrancara?
Por muy obvias que puedan parecer las preguntas anteriores, nos llevan a una conclusión evidente: confiamos en un producto, un servicio o incluso una marca después de haberlos probado mínimamente.
En general, la confianza está directamente relacionada con el cumplimiento de nuestras expectativas. Ya hemos hablado aquí, en el blog, de lo valiosa que es la automatización. Gracias a ella, podemos hacer realidad, en el futuro, algo que antes solo existía en nuestra imaginación. Si pensamos lo mismo sobre un producto o servicio, si suponemos que va a funcionar como esperamos, nuestras expectativas se cumplen. En consecuencia, creeremos que es de calidad.
Es precisamente por eso que las pruebas son la herramienta principal para la ingeniería de calidad en la industria del software. Gracias a ellas confiamos en un sistema y, por lo tanto, nos sentimos seguros al utilizarlo.
A grandes rasgos, podemos dividir las pruebas en dos grandes grupos. En el primero, «quién» realiza las pruebas: una persona o un robot. Las pruebas manuales las llevan a cabo personas, normalmente un analista de control de calidad (QA, por sus siglas en inglés), mientras que los robots se encargan de las pruebas automatizadas.
En el segundo, se comprueba «qué»: las partes y la relación entre ellas. En las pruebas unitarias, verificamos el funcionamiento de partes del sistema, a menudo muy pequeñas, mientras que en las pruebas de integración combinamos varios bloques de la aplicación y los probamos en conjunto.
Para facilitar tu navegación por este universo de conocimientos, hemos recopilado en esta página los contenidos elaborados por Inmetrics sobre este tema. Desde aquí podrás acceder a la historia de las pruebas, conocer mejor los manuales, las pruebas de experiencia, las pruebas unitarias y una metodología muy conocida para llevarlas a cabo: el desarrollo orientado a pruebas.
Puede resultar difícil de creer, pero hubo un tiempo en el que la gente no comprobaba si un programa funcionaba, sino que esperaba a que fallara.
Esta situación comenzó a cambiar a partir de la década de 1950, cuando las pruebas y la depuración empezaron a considerarse actividades distintas. Y en 1979, con la publicación de la obra «El arte de las pruebas de software», el panorama de esta actividad cambió, adquiriendo la relevancia que tiene en la actualidad.
El libro propone una forma nueva y holística de comprobar si el programa funciona y cumple los requisitos. En lugar de probar y confirmar lo que funcionaba, el objetivo de la actividad pasó a ser ejecutar un sistema con la intención de encontrar errores, verificando todas las hipótesis que podrían dar lugar a un error.
¡Descubre un poco más sobre la historia de las pruebas en la industria del software haciendo clic aquí!
Las pruebas manuales son aquellas que realizan personas, normalmente un analista de control de calidad o un analista de calidad. Dado que las llevan a cabo personas, en muchas de estas pruebas manuales será necesario recurrir a habilidades y capacidades que son eminentemente humanas: las sensoriales.
La mayor parte de las interacciones que establecemos con las aplicaciones se limitan a las pantallas y, para llevarlas a cabo, utilizamos la vista y el tacto, ya sea para manejar el ratón, el teclado o las pantallas táctiles. Sin embargo, hay aplicaciones que emiten señales sonoras, vibran… Gran parte de nuestros sentidos se activan en las pruebas manuales.
En la era de la inteligencia artificial, los analistas de control de calidad se han centrado en realizar aquellas pruebas manuales en las que la cognición o la creatividad humanas aportan valor y agilizan el proceso: las pruebas exploratorias o las centradas en la experiencia del usuario.
¡Haz clic aquí para conocer un poco más tanto sobre la historia de las pruebas manuales como sobre su papel en la era de los agentes de inteligencia artificial!
El todo solo existe porque hay partes que se relacionan entre sí. Cuando aplicamos esta reflexión a las aplicaciones, las vemos como un conjunto de pantallas en las que hay botones que contienen funciones, que activan otras funciones… Podemos descomponer toda la aplicación en partes muy pequeñas y, para inspeccionarlas, realizamos pruebas unitarias.
La principal característica que diferencia las pruebas integradas de las unitarias es su nivel de granularidad. Estas se llevan a cabo en funcionalidades aisladas, sin conexión con otras partes del sistema, servicios o agentes externos.
Naturalmente, las pruebas unitarias se ejecutan más rápido y son más fáciles de llevar a cabo. Sin embargo, a pesar de lo sencillo que resulta ejecutarlas, su importancia es enorme: es a través de ellas como detectamos los fallos de forma precoz y, en consecuencia, creamos una «red de seguridad» que evita que los errores se propaguen a las capas superiores de las aplicaciones.
¡Descubre con más detalle cómo se definen las pruebas unitarias y cómo aumentan la eficacia en los proyectos de desarrollo!
En el sector del software, buscamos una característica muy valiosa: que sea «agradable de usar». Para lograrlo, realizamos pruebas de experiencia con el fin de comprobar qué «sensación» transmite el sistema cuando lo utilizamos.
Tal y como hemos comentado en este texto, podemos dividir las pruebas en dos grandes dimensiones: los agentes que las realizan y «lo que» se prueba. Sin embargo, más allá de estas dimensiones, podemos clasificar las pruebas desde diferentes perspectivas. Podemos, por ejemplo, agrupar las pruebas de usabilidad, accesibilidad y experiencia en el espectro de las pruebas de calidad centradas en el usuario.
Esta observación es importante porque quizá la forma más sencilla de definir las pruebas de experiencia sea diferenciándolas de las de usabilidad. Mientras que estas últimas se centran en las interfaces —diseño, claridad de la información, flujo de navegación, comportamiento del usuario frente a la pantalla— con el fin de evaluar la facilidad de uso de una aplicación, las pruebas de experiencia van más allá. El objetivo es comprobar cómo «percibe» el usuario las aplicaciones, qué sensaciones y emociones se despiertan ante las interfaces.
Las pruebas de experiencia han ido cobrando cada vez más importancia ante el aumento exponencial de las actividades que se están trasladando al ámbito del software. Para conocerlas con más detalle, ¡haz clic aquí!
Se espera que las aplicaciones modernas sean capaces de: a) procesar rápidamente grandes cantidades de datos sin errores; b) ofrecer una experiencia fluida al usuario, independientemente del dispositivo; y c) llevar a cabo estas dos funciones para muchos usuarios de forma simultánea. Las pruebas de rendimiento sirven para comprobar si la aplicación es capaz de hacer todo esto.
Analizar el rendimiento consiste en medir la eficiencia de un sistema ante diferentes volúmenes, ya sean de usuarios, datos, transacciones o tiempo de exposición. Con los programas que utilizan la computación en la nube como modelo de soporte, estos análisis cobran aún más importancia, ya que son ellos los que determinan si la aplicación es capaz de escalar manteniendo la estabilidad.
Cuando realizamos cualquiera de los cuatro tipos de pruebas de rendimiento, nuestro objetivo es identificar cinco métricas fundamentales. ¡Descubre cuáles son los tipos, las métricas y su importancia haciendo clic aquí!
Probar algo antes de que exista: parece imposible, pero, desde un punto de vista conceptual, es precisamente lo que propugna el enfoque del desarrollo orientado a las pruebas.
Para que los programas se actualicen con frecuencia, se aplican prácticas de calidad desde la fase conceptual hasta el entorno de producción. Los sistemas se someten a validaciones continuas y exhaustivas en todas las etapas, y cada uno de sus pequeños componentes se crea de forma conforme. Esto solo es posible gracias al enfoque del desarrollo orientado a pruebas, un método para ejecutar pruebas unitarias y automatizadas.
Desarrollado por Kent Back a finales del siglo XX y principios del XXI, el enfoque que se hizo mundialmente conocido con las siglas TDD —que significa «desarrollo basado en pruebas» (Test-Driven Development )— es uno de los más utilizados en el mercado para aumentar la fiabilidad del sistema en todas las fases de producción, reduciendo así el volumen de trabajo de inspección en la fase de lanzamiento.
¡Descubre en detalle el enfoque de desarrollo orientado a pruebas accediendo al texto aquí!
