¿Qué diferencia hay entre la prueba de humo y la prueba de cordura?

Este tema puede parecer simple para muchos, pero a pesar de cientos de artículos web: el humo, la cordura, las pruebas y la regresión son los temas más incomprendidos en las pruebas de software. Existe una enorme cantidad de literatura sobre el tema, pero la mayoría de ellos son confusos. El siguiente artículo intenta abordar la confusión. Antes de comprender estas terminologías, antes que nada debe 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 múltiples 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 múltiples 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 sufre múltiples cambios (correcciones de defectos), es decir, múltiples ‘Builds’.

Prueba de humo (chequeo general de salud)

¿Qué pasa si los desarrolladores son demasiado imprudentes? Hay un defecto en el primer paso: el usuario no puede iniciar sesión. ¡Sí! Usted dirá qué pasa con las pruebas unitarias, pero por lo general los desarrolladores no siguen las reglas cada vez que las pruebas J Smoke 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 como ‘Prueba de confianza’ o ‘Prueba de verificación de compilación’. Las pruebas de humo cubren las funcionalidades MÁS CRÍTICAS. El propósito es rechazar una compilación de “defecto crítico” antes de que el equipo de prueba comience pruebas funcionales detalladas. Antes de comenzar el día, una prueba diaria de construcción y humo se encuentra entre las mejores prácticas de la industria.

Nota : El término “prueba de humo” se refiere a encender un dispositivo simplemente para asegurarse de que no comience 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 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 cordura). Extendiendo el concepto al software, después de cada cambio en una compilación, se realizan pruebas de cordura para determinar que los cambios particulares funcionan como se espera después de las pruebas detalladas que se realizan. Si la prueba de cordura falla, la construcción se rechaza para ahorrar el tiempo y los costos involucrados en una prueba más rigurosa.

Nota : La cordura en general se refiere a la solidez, racionalidad y salubridad de la mente humana. Una persona ya no se considera cuerda solo si es irracional.

Retesting (chequeo de recuperación de salud, post 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 corrección del defecto funcione bien, en otras palabras, debe ‘volver a probar’ el defecto en función de sus pasos para reproducirse. Simple, ¿verdad?

Pruebas de regresión (sin efectos secundarios)

El trabajo aún no ha terminado J el código se desarrolla >> Se desarrolla la compilación >> Se realiza la cordura >> Se realiza la prueba completa >> Los defectos se registran, corrigen y vuelven a probar. ¿Qué más? ¡Sí! La verdad es más extraña que la ficción, y también lo es el Software. Nunca se sabe que un cambio en una función (corrección de defectos o mejora o solicitud de cambio) puede afectar múltiples áreas del software. Es nuestro deber como equipo de prueba asegurarnos de que todo (aparte del cambio) afectado funcione como se espera. En otras palabras, para garantizar que no se introduzcan nuevos defectos. Como habrás 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 ordenó en este artículo 😉 Por lo general, las pruebas de regresión son el último ciclo de prueba antes de cerrar la sesión del software.

· Ambas pruebas de humo y cordura se realizan para verificar funcionalidades críticas y evitar cualquier esfuerzo inútil (prueba funcional) en caso de problemas críticos.

· Las pruebas 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 de forma manual 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 cordura, por lo tanto, a menudo se usan indistintamente. Las pruebas de regresión se descuidan en su mayoría o el equipo depende completamente de 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 comprender claramente estos conceptos. En caso afirmativo, considere suscribirse a Software Testing Studio para obtener todas las actualizaciones nuevas en su Bandeja de entrada GRATIS. ¡Gracias!

Visite mi sitio web Prueba de software entrevista preguntas respuestas y aprenda el aseguramiento de la calidad del software

La prueba de humo y la prueba de cordura son las mismas en términos de estilo de prueba. En ambos estilos de prueba, solo se verifica la funcionalidad de alto nivel.

lo que los hace diferentes es su propósito de hacerlo

Prueba de humo :

Cuando llega la nueva compilación o se entrega la nueva versión del software al equipo de prueba, el control de calidad verifica la compilación / software y se asegura de que todas las funciones básicas funcionen y se pueda entregar al equipo de prueba para realizar pruebas detalladas. De la misma manera, cuando se identifica una nueva plataforma para la prueba de software, se realiza la prueba de humo antes de comenzar la Prueba de detalle real.

Test de sanidad :

La prueba de cordura se realiza antes del lanzamiento del software para asegurarse de que todos los funcionales básicos funcionen y que no se rompa ningún nivel alto por ningún motivo. Es una verificación previa de alto nivel antes del lanzamiento.

La prueba de humo se realiza en una compilación dada para verificar o verificar que las funciones principales de la compilación dada funcionan correctamente o no para garantizar si la compilación dada es elegible para más pruebas de software. El propósito de la prueba de humo es verificar la elegibilidad o estable de compilación para realizar pruebas negativas y positivas, en caso de que la compilación dada no funcione correctamente, es decir, las funcionalidades principales, entonces tiene derecho a rechazar la compilación dada.

Sanity Testing no es más que verificar la aplicación cuando hay cambios en las funcionalidades o la corrección de errores en el código, luego todos los módulos dependientes deben ejecutarse para verificar si los errores reparados no están causando nuevos defectos en la aplicación o el flujo del usuario final. la Prueba de cordura es para verificar que el flujo de extremo a extremo ya funciona como se esperaba debido a los nuevos cambios en el código o las funcionalidades de las aplicaciones.

por favor lea más detalles aquí

Diferencia entre pruebas de humo y pruebas de cordura – WikiShows

PRUEBA DE HUMO:

• Las pruebas de humo se originaron en la práctica de pruebas de hardware de encender una nueva pieza de hardware por primera vez y considerarla un éxito si no se prende fuego ni humo. En la industria del software, la prueba de humo es un enfoque superficial y amplio mediante el cual se prueban todas las áreas de la aplicación sin profundizar demasiado.
• Una prueba de humo está programada, ya sea usando un conjunto de pruebas escritas o una prueba automatizada
• Una prueba de humo está diseñada para tocar cada parte de la aplicación de una manera superficial. Es poco profundo y ancho.
• Se realizan pruebas de humo para garantizar si las funciones más cruciales de un programa funcionan, pero no se molestan con detalles más precisos. (Como la verificación de compilación).
• La prueba de humo es un control de salud normal hasta la compilación de una aplicación antes de llevarla a prueba en profundidad.

PRUEBAS DE SANIDAD:

• Una prueba de cordura es una prueba de regresión estrecha que se enfoca en una o algunas áreas de funcionalidad. Las pruebas de cordura suelen ser estrechas y profundas.
• Una prueba de cordura generalmente no tiene guión.
• Se usa una prueba de Cordura para determinar que una pequeña sección de la aplicación aún funciona después de un cambio menor.
• La prueba de cordura es una prueba superficial, se realiza cada vez que una prueba superficial es suficiente para demostrar que la aplicación funciona de acuerdo con las especificaciones. Este nivel de prueba es un subconjunto de pruebas de regresión.
• La prueba de cordura consiste en verificar si se cumplen los requisitos o no, verificando primero todas las características.

Referencia – Pruebas de humo y pruebas de cordura – Diferencias rápidas y simples

Teóricamente, puede encontrar múltiples definiciones en Internet para las pruebas de humo frente a las pruebas de cordura, pero prácticamente estos términos se usan indistintamente en función de la terminología adoptada en cualquier organización.

Por lo tanto, no te preocupes demasiado por las definiciones, ya que seguirán confundiéndote. Vaya con la intención de ambos y eso es verificar el sistema / aplicación / hardware / software antes de comenzar cualquier regresión / nueva prueba, etc.

Prueba de humo es básicamente un término de hardware. Ej: si compra un dispositivo eléctrico, conéctelo a la red eléctrica y encienda el interruptor,

Observar si

Su dispositivo se convierte en humo. En cuyo caso ha fallado.

O

Sigue funcionando

Si continúa funcionando significa que podría ser comprobable.

Si tomamos una analogía con los sitios web. Me gustaría saber si la página web al menos se inicia y muestra la página de inicio.

Para una aplicación móvil, me gustaría ver si incluso se puede iniciar antes de ejecutar cualquier prueba.

Las pruebas de cordura son básicamente una mirada superficial a las características principales de una aplicación en un nivel superficial. Cualquier error importante podría conducir a la suspensión de las pruebas en esta etapa o también lo que se conoce como violación de los criterios de entrada. Sin embargo, hay otras cosas que puede recopilar información durante una prueba de cordura, vea mi video sobre esto

Hay muchas publicaciones que describen humo y cordura, y ninguna de ellas las describe claramente. Todos están repitiendo cosas. Solo unos pocos los describen claramente. Basado en eso, mi respuesta es la siguiente:
Tanto la prueba de humo como la prueba de cordura son intercambiables en gran medida. Incluso en la organización en la que trabajo, el humo y la cordura se usan indistintamente. Pero hay una pequeña diferencia entre ellos. Ambos tienen el mismo propósito: evitar que el tiempo de los evaluadores se desperdicie al probar la aplicación que no funciona correctamente incluso en sus niveles básicos. No tiene sentido probar una aplicación a escala completa cuando la aplicación no funciona en sus operaciones básicas.
La prueba de humo se realiza cuando recibe la compilación por primera vez. En esto probamos algunas cosas de alto nivel, como si la aplicación se está abriendo con éxito o no, si varios enlaces (enlaces de navegación, etc.) funcionan o no, si la base de datos está configurada correctamente o no, si hay otras configuraciones establecidas o no . Aquí nuestro motivo no es probar las cosas profundamente y la funcionalidad completa. Solo pruebe si las cosas funcionan en sentido general o no. Es como un chequeo general de salud.

La cordura también es como el humo, pero un poco más profundo. Hacemos la cordura después del humo y antes de las pruebas funcionales y de regresión. En la cordura vamos un paso más adelante y verificamos algunas funcionalidades básicas en mayor medida. En esto no se verifican todas las funcionalidades, pero solo algunas importantes. El motivo es verificar si el desarrollador ha aplicado alguna racionalidad o no. Por ejemplo, si hay una aplicación de calculadora científica, la cordura significa verificar si la función de suma o la de sustracción funcionan correctamente o no. Si no, por qué perder el tiempo en la comprobación de funciones de alto nivel como porcentaje, exponente, registro, etc. Simplemente rechace esta aplicación porque la aplicación no funciona en su funcionalidad básica de sumar y restar. Esto es cordura. Sanity es un chequeo de salud especializado solo para las funcionalidades principales. Ej: funcionalidad de inicio de sesión.

La cordura se hace cada vez que la construcción llega después de algún cambio. Cada vez que hay algún cambio en la aplicación, hacemos la cordura antes de la regresión completa para asegurarnos de que el cambio tenga cierta racionalidad. Si bien el humo se realiza solo la primera vez cuando recibimos una nueva construcción. No tiene sentido verificar las cosas generales (control de salud general de humo) una y otra vez porque cuando recibimos una acumulación después de algún cambio, estas cosas generales (para el humo) ya están funcionando.
Después de la cordura, cuando estamos seguros de que es factible probar la compilación aún más para obtener una funcionalidad completa, hacemos pruebas funcionales completas en las que verificamos todas las funcionalidades a escala completa y niveles más profundos.
Su orden se puede describir como:
La construcción llega por primera vez ——> Humo —–> Cordura ——-> Prueba funcional completa ——-> la construcción sufre cambios ——–> cordura ——-> funcional / regresión —-> la construcción sufre más cambios ——–> cordura ——-> funcional / regresión.

Pero, en general, la cordura posterior después de la primera generalmente se pierde y se realiza una regresión directa.
Espero que esto te ayude.