Este tema puede parecer simple para muchos, pero a pesar de los cientos de artículos en la Web, Smoke, Sanity, Retesting & Regression son los temas más incomprendidos en Pruebas de software. Hay una enorme cantidad de literatura sobre el tema, pero la mayoría de ellos son confusos. El siguiente artículo hace un intento de abordar la confusión. Antes de comprender estas terminologías, lo primero y más importante es comprender el concepto de Software Build.
Compilación de software
¿Qué crees que se necesita para construir un software? ¡Sí! El código. Pero no es solo un archivo de código único, generalmente hay varios archivos de código fuente. Ahora, estos archivos de código fuente deben compilarse y combinarse en un solo archivo ejecutable que luego puede ser implementado por el equipo de lanzamiento. Este proceso de combinar varios archivos de código fuente en un solo archivo ejecutable se conoce como ‘Software Build’. Como habrás adivinado, antes de ser entregado al cliente, un software experimenta múltiples cambios (arreglos de defectos), es decir, múltiples ‘Builds’!
Pruebas de humo (chequeo general de salud)
- Cómo obtener más donaciones de mis eventos Meetup
- ¿Cuál es la diferencia entre educación y adoctrinamiento?
- ¿Es la tendencia general de la religión a no ser atribuida por el signo más inteligente de la iluminación o la arrogancia?
- ¿Hay alguna evidencia experimental que respalde la teoría de Marvin Minsky, La sociedad de la mente?
- ¿Por qué las amenazas y las tentaciones funcionan con unos y otros no?
¿Qué pasa si los desarrolladores son demasiado imprudentes? Hay un defecto en el primer paso: el usuario no puede iniciar sesión por sí mismo. ¡Sí! Dirá lo que pasa con las pruebas de unidad, pero generalmente los desarrolladores no siguen las reglas cada vez que las pruebas de humo J son las pruebas preliminares para revelar fallas simples lo suficientemente graves como para rechazar un posible lanzamiento de software. En otros términos, puede llamarlo ‘Pruebas de confianza’ o ‘Pruebas de verificación de compilación’. Las pruebas de humo cubren las funcionalidades MÁS CRÍTICAS. El propósito es rechazar una construcción de ‘defecto crítico’ antes de que el equipo de pruebas inicie pruebas funcionales detalladas. Antes de comenzar el día, una de las mejores prácticas de la industria es una prueba diaria de humo y construcción.
Nota : el término “prueba de humo” se refiere a encender un dispositivo simplemente para asegurarse de que no empiece a fumar (lo que indica un problema importante). Se originó en las pruebas de hardware electrónico.
Pruebas de cordura (chequeo de salud especializado)
En primer lugar, independientemente de las pruebas, la comprobación de la cordura es un concepto básico: una comprobación simple para ver si la salida producida es racional (que el creador del producto estaba pensando racionalmente, aplicando la cordura). Extender el concepto al software, después de cada cambio en una compilación, se realiza una prueba de cordura para verificar que los cambios en particular están funcionando como se espera de la publicación de las pruebas detalladas. Si la prueba de validez falla, la construcción se rechaza para ahorrar tiempo y costos en una prueba más rigurosa.
Nota : La cordura en general se refiere a la solidez, racionalidad y salud de la mente humana. Una persona ya no se considera sana solo si es irracional.
Reprobación (chequeo de salud de recuperación, después de la medicina)
Este es el más simple de entender. ¿Qué haces en las pruebas? Obviamente encontrar y registrar defectos. ¿Después de esto? ¡Sí! El desarrollador arreglará el defecto. Como equipo de prueba, debe verificar que la solución del defecto funciona bien, en otras palabras, debe “volver a probar” el defecto según sus pasos para reproducir. Simple, ¿verdad?
Pruebas de regresión (sin efectos secundarios)
Aún no se ha terminado el trabajo. J se desarrolla el código >> Se implementa la compilación >> Se ejecuta la cordura >> Se realiza la prueba completa >> Se registran, se arreglan y se vuelven a probar los defectos. ¿Qué más? ¡Sí! La verdad es más extraña que la ficción, y el Software también. Nunca se sabe que un cambio en una función (corrección de defectos, mejora o solicitud de cambio) puede afectar varias áreas del software. Es nuestro deber como equipo de pruebas garantizar que todo lo que está impactado (aparte del cambio) funcione como se espera. En otras palabras, para asegurar que no haya nuevos defectos introducidos. Como habrá adivinado, ¡conocer el impacto (análisis de impacto) es imprescindible para realizar pruebas de regresión efectivas!
Punteros clave
Hay un problema inherente en la Comunidad de Pruebas. No solo llamamos al mismo proceso por varios nombres, sino que a veces algunos de nosotros también usamos el mismo nombre para llamar a diferentes procesos. Esta es la razón de gran parte de la confusión. ¡Pero debes despejar todas tus dudas antes de ser un gran probador!
· Es posible que no haya observado, pero la secuencia de estas pruebas es la misma que se indica en este artículo 😉 Por lo general, la prueba de regresión es el último ciclo de prueba antes de cerrar la sesión del software.
· Se realizan ambas pruebas de Humo y Sanidad para verificar las funcionalidades críticas y evitar cualquier esfuerzo desperdiciado (pruebas funcionales) en caso de problemas críticos.
· La prueba de regresión es donde el ‘análisis de impacto’ es útil para medir las áreas afectadas debido a cualquier cambio de software.
· Las pruebas de cordura y regresión se pueden realizar manualmente o mediante automatización. Las pruebas de regresión son las más adecuadas para las pruebas de automatización que utilizan herramientas efectivas como Selenium, HPE UFT, etc.
Diferentes organizaciones y personas tienen una comprensión diferente de las pruebas de Humo y Salud, por lo que a menudo se usan indistintamente. La mayoría de las pruebas de regresión se descuidan o el equipo confía completamente en la automatización, pero si se realiza con diligencia utilizando el análisis de impacto, es uno de los ciclos de prueba más importantes.
Espero que este artículo te haya ayudado a entender claramente estos conceptos. Si es así, considere suscribirse a Software Testing Studio para obtener todas las actualizaciones nuevas en su Bandeja de entrada GRATIS. ¡Gracias!