Comencemos con lo básico. Explora los dos modos de prueba generales y tres tipos comunes de automatización de pruebas.
A todos nos pasó alguna vez, ¿qué meme de programación recurrente que aparece con demasiada frecuencia en la vida real?
Este meme resume muy bien: cada panel lateral funciona perfectamente bien de manera individual, pero en combinación con el otro panel lateral, se bloquean entre sí y no funcionan. Es conveniente que ambos paneles funcionen bien juntos y que se puedan usar al mismo tiempo.
Aplica esto al desarrollo web: escribiste algunas pruebas, tal vez hasta alcanzaste el 100% de cobertura, pero tu aplicación aún debe funcionar cuando se instalan otras partes. Las unidades pueden funcionar bien por sí solas, pero no en relación entre sí. Escribir algunas pruebas es crucial, pero solo es una parte de la configuración de prueba ideal para tu proyecto. Como primer paso, debes determinar qué partes de la calidad de la aplicación necesitas garantizar y cómo puedes lograrlo.
En pocas palabras, necesitas un plan antes de comenzar a escribir el código de prueba real. Para abordar el tema de cómo realizar pruebas de manera práctica, comencemos con una plantilla y respondamos dos preguntas básicas:
- ¿Cómo quieres hacer la prueba?
- ¿Qué quieres probar?
Este artículo se centra en los aspectos generales que debes saber para responder la primera pregunta. Para empezar desde un punto en común, primero aprendamos qué modos de prueba existen y, luego, enfoquémonos en los tipos comunes de pruebas. En artículos posteriores, responderemos la segunda pregunta, combinaremos las respuestas y encontraremos la estrategia de prueba que mejor se adapte a tu proyecto. Comencemos 🙌
Comienza con lo básico: Modos de prueba generales
Al responder la pregunta sobre cómo realizar la prueba, el primer punto que hay que aclarar es muy abstracto. ¿Deberías hacer la prueba de forma manual o dejar que una computadora se haga cargo? Sin embargo, es importante no caer en el pensamiento binario aquí.
Pruebas manuales frente a pruebas automatizadas
Si les pides a los ingenieros de control de calidad que definan las pruebas, probablemente primero las dividan en dos "modos":
- Pruebas manuales. Este es un método de prueba típico que realizan personas reales. Un ingeniero de control de calidad hace clic en la aplicación, comprueba si funciona y, al mismo tiempo, intenta romperla. La forma más común son las pruebas de exploración, en las que el ingeniero investiga la aplicación usando su conocimiento sobre la aplicación con una ruta de acceso o lista de tareas predefinidas.
- Pruebas automatizadas. Este es un tipo de prueba que se realiza mediante una computadora. Los ingenieros de control de calidad la implementan para automatizar las pruebas repetitivas y monótonas.
Esta serie de guías se enfocará principalmente en las pruebas automatizadas. Sin embargo, no debes enfocarte en una sola forma de realizar pruebas. Incluso si la automatización ahorra mucho tiempo y esfuerzo, las pruebas manuales y humanas siempre tendrán un papel fundamental. En su lugar, la automatización de pruebas debería liberar a las personas para que se enfoquen en las pruebas de exploración y la resolución creativa de problemas. Por ejemplo, para garantizar la calidad de las experiencias de los usuarios o proteger la lógica empresarial de alto riesgo. En otras palabras, la automatización está para ayudarte. ❤️
Caja opaca frente a caja transparente
Ya definiste los modos generales de prueba. Sin embargo, eso todavía no es suficiente. Para planificar la estrategia de prueba, hay una pregunta más que responder: ¿sabes cómo funciona tu aplicación de forma interna o es mejor probarla sin este conocimiento? Según la respuesta, hay dos procedimientos que puedes elegir para derivar y seleccionar casos de prueba:
- Prueba de caja opaca (o de caja negra). Se basa en el análisis de los requisitos funcionales o no funcionales de un componente o sistema (especificaciones) sin considerar su estructura interna.
- La prueba de caja blanca (o prueba de caja blanca) es un procedimiento que tiene en cuenta la estructura interna de dicha caja. En otras palabras, cómo funciona de forma interna tu aplicación.
Ambos procedimientos se pueden aplicar a pruebas manuales y automatizadas. Sin embargo, es posible que algunos aspectos de los modos de prueba generales se centren más en uno de estos dos, pero lo veremos más adelante. Por ahora, desglosemos más la automatización de pruebas en tipos.
Tipos de automatización de pruebas: ¿Cómo quieres hacer las pruebas?
A medida que te acercas a responder la pregunta del tipo “cómo”, ya decidiste hacer algunas pruebas manuales. Sin embargo, elegir y aplicar tipos de automatización de pruebas es un poco más difícil. Los tipos de pruebas de automatización están estrechamente relacionadas con las métricas que deseas crear en tus proyectos. Veamos con más detalle las más importantes.
Como se ilustra en el meme mencionado anteriormente, ya te has encontrado con dos tipos: pruebas de unidades y de integración. Las pruebas de extremo a extremo son la tercera opción importante que debes tener en cuenta. Pero eso no es todo de todos modos. Veamos los detalles.
Pruebas de unidades
La prueba de unidades es un tipo de prueba en el que las partes o unidades de una aplicación menores que se pueden probar se prueban de manera independiente y individual para garantizar un funcionamiento adecuado. Estas unidades pueden variar en alcance desde funciones, clases o interfaces, hasta servicios o componentes completos. Sus atributos principales son la velocidad de ejecución, el aislamiento y la facilidad de mantenimiento. Si quieres profundizar en la prueba de unidades, consulta esta guía sobre pruebas de unidades.
Pruebas de integración
Las pruebas de integración se centran en las interacciones entre componentes o sistemas. En otras palabras, en qué tan bien funcionan juntos. Los ejemplos típicos de pruebas de integración son las pruebas de API o de componentes.
Pruebas de extremo a extremo
Estas pruebas se suelen llamar pruebas de IU y su nombre explica aún mejor su función. Estas pruebas interactúan con la IU de tu aplicación, incluida la pila completa de aplicaciones, y prueban tu aplicación de un extremo a otro.
Se asemejan a una prueba del sistema si te refieres a la teoría de aseguramiento de la calidad. Estas pruebas simulan a un usuario genuino y sus interacciones. Las pruebas de extremo a extremo requieren más tiempo de ejecución porque involucran todo el sistema, y más tiempo de ejecución requiere más potencia de procesamiento. Como resultado, este esfuerzo adicional genera costos de mantenimiento más altos.
Pruebas de IU visual
Una subcategoría interesante de las pruebas de IU son las pruebas visuales. Estas son pruebas extendidas de extremo a extremo que proporcionan un medio para verificar el resultado visible de una aplicación. Esa prueba toma una captura de pantalla después de un cambio y otra captura de pantalla que contiene el “status quo” (o archivo dorado) y, luego, proporciona esos resultados a un revisor manual para que los inspeccione y compruebe. En otras palabras, ayuda a encontrar “errores visuales” en la apariencia de una página, más allá de errores puramente funcionales y no escritos explícitamente en aserciones.
Análisis estático
Hay algo más que introducir aquí: el análisis estático. No es un tipo de prueba en el sentido de un libro de texto. Sin embargo, será un aspecto esencial de las estrategias de control de calidad más adelante. Te imaginarás que funciona como una función de corrector ortográfico: analiza tu código en busca de defectos y errores de sintaxis más significativos sin ejecutar el programa, y detecta así problemas de estilo de código. Esta simple medida puede evitar muchos errores. Este es un buen punto para aprender sobre el análisis estático si quieres conocerlo en más detalle.
Pruebas en todas las formas: ¿Cómo funciona todo esto en conjunto?
Mientras buscas las respuestas a todas estas preguntas, puedes encontrar una posible solución en algunas analogías. En la Web y en las comunidades de pruebas específicamente, los desarrolladores tienden a usar estas analogías para darte una idea de la cantidad de pruebas de cada tipo que deberías usar.
Las cinco estrategias que se muestran en esta imagen son las más comunes:
- Pirámide de prueba
- Diamante de prueba
- Cono de hielo de prueba (también conocido como pizza de prueba)
- Prueba Honeycomb
- Trofeo de prueba
Es realmente mucha información para procesar. ¿Cómo deberías decidir si utilizar una estrategia de prueba coincidente en función de todo esto? No te preocupes, tenemos lo que necesitas. En el siguiente artículo, analizaremos estas diferentes estrategias con más detalle y explicaremos cómo elegir la mejor opción para tu proyecto. ¡No te pierdas las novedades! 🔥