Good Mood

Explore las diferencias entre las pruebas de humo y las pruebas de Cordura en detalle con ejemplos:

en este tutorial, aprenderemos qué son las pruebas de cordura y las pruebas de humo en las pruebas de Software. También aprenderemos las diferencias clave entre la cordura y las pruebas de humo con ejemplos simples.

La mayoría de las veces nos confundimos entre el significado de la prueba de cordura y la prueba de humo. En primer lugar, estas dos pruebas son muy «diferentes» y se realizan durante diferentes etapas de un ciclo de pruebas.,

pruebas de Cordura

Las pruebas de Cordura se realizan cuando, como QA, no tenemos tiempo suficiente para ejecutar todos los casos de prueba, ya sea pruebas funcionales, de interfaz de usuario, de sistema operativo o pruebas de navegador.

Por lo tanto, definiría,

«pruebas de cordura como una ejecución de prueba que se realiza para tocar cada implementación y su impacto, pero no a fondo o en profundidad, puede incluir funcional, interfaz de usuario, Versión, etc. pruebas en función de la implementación y su impacto.»

¿no todos caemos en una situación en la que tenemos que firmar en un día o dos, pero la compilación para las pruebas aún no se ha lanzado?,

Ah sí, apuesto a que también debe haber enfrentado esta situación al menos una vez en su experiencia de prueba de Software. Bueno, me enfrenté mucho porque mi(s) proyecto (s) eran en su mayoría ágiles y a veces se nos pedía que lo entregáramos el mismo día. Oops, ¿cómo podría probar y liberar la compilación en un tramo de horas?

solía volverme loco a veces porque incluso si era una funcionalidad pequeña, la implicación podría ser tremenda. Y como guinda del pastel, los clientes a veces simplemente se niegan a dar tiempo extra., ¿Cómo podría completar toda la prueba en unas pocas horas, verificar cada funcionalidad, errores y liberarlo?

la respuesta a todos estos problemas fue muy simple, es decir, nada más que usar la estrategia de pruebas de Cordura.

Cuando hacemos esta prueba para un módulo o funcionalidad o un sistema completo, los casos de prueba para la ejecución se seleccionan de tal manera que tocarán todos los bits y piezas importantes de la misma, es decir, pruebas anchas pero poco profundas.

a veces la prueba se hace incluso aleatoriamente sin casos de prueba., Pero recuerde, la prueba de Cordura debe hacerse solo cuando se está quedando corto de tiempo, nunca use esto para sus lanzamientos regulares. Teóricamente, esta prueba es un subconjunto de la prueba de regresión.

mi experiencia

de mis más de 8 años de carrera en pruebas de Software, durante 3 años estuve trabajando en metodología ágil y ese fue el momento en que mayormente usé una prueba de cordura.

todas las versiones grandes se planificaron y ejecutaron de manera sistemática, pero a veces se pidió que las versiones pequeñas se entregaran lo antes posible., No tuvimos mucho tiempo para documentar los casos de prueba, ejecutar, hacer la documentación de errores, hacer la regresión y seguir todo el proceso.

por lo tanto, los siguientes son algunos de los indicadores clave que solía seguir en tales situaciones:

#1) sentarse con el gerente y el equipo de desarrollo cuando están discutiendo la implementación porque tienen que trabajar rápido y, por lo tanto, no podemos esperar que nos expliquen por separado.

esto también le ayudaría a tener una idea sobre lo que van a implementar, qué área va a afectar, etc.,, esto es algo muy importante porque a veces simplemente no nos damos cuenta de las implicaciones y si alguna funcionalidad existente va a verse obstaculizada (en el peor de los casos).

#2) Como tienes poco tiempo, para cuando el equipo de desarrollo esté trabajando en la implementación, puedes anotar los casos de prueba aproximadamente en herramientas como Evernote, etc. Pero asegúrese de escribirlos en algún lugar para que pueda agregarlos más tarde a la herramienta caso de prueba.,

#3) Mantenga su banco de pruebas listo según la implementación y si siente que hay banderas rojas como alguna creación de datos específicos si un banco de pruebas tomará tiempo (y es una prueba importante para la liberación), luego levante esas banderas inmediatamente e informe a su gerente o PO sobre el obstáculo.

solo porque el cliente quiera lo antes posible, no significa que un QA se liberará incluso si está medio probado.,

#4) haga un acuerdo con su equipo y gerente que debido a la crisis de tiempo solo comunicará los errores al equipo de desarrollo y el proceso formal de agregar, marcando los errores para diferentes etapas en la herramienta de seguimiento de errores se hará más tarde con el fin de ahorrar tiempo.

#5) cuando el equipo de desarrollo está probando al final, intente emparejarse con ellos (llamado emparejamiento dev-QA) y haga una ronda básica en su configuración, esto ayudará a evitar el ir y venir de la compilación si la implementación básica falla.,

#6) Ahora que tiene la compilación, pruebe primero las reglas de negocio y todos los casos de uso. Puede mantener pruebas como una validación de un campo, navegación, etc. para más adelante.

#7) Cualquier error que encuentres, toma nota de todos ellos e intenta reportarlos juntos a los desarrolladores en lugar de reportarlos individualmente porque será fácil para ellos trabajar en un montón.

#8) Si tiene un requisito para la prueba de rendimiento general o la prueba de esfuerzo o carga, asegúrese de tener un marco de automatización adecuado para el mismo., Porque es casi imposible probar manualmente estos con una prueba de cordura.

#9) Esta es la parte más importante, y de hecho el último paso de su estrategia de prueba de cordura: «cuando redacte el correo electrónico de publicación o el documento, mencione todos los casos de prueba que ejecutó, los errores encontrados con un marcador de estado y si algo no se probó, menciónelo con las razones» intente escribir una historia nítida sobre sus pruebas que transmita a todos lo que se ha probado, verificado y lo que no se ha probado.

seguí esto religiosamente cuando estaba usando esta prueba.,

Déjame compartir mi propia experiencia:

#1) estábamos trabajando en un sitio web y solía aparecer anuncios basados en las palabras clave. Los anunciantes solían colocar la oferta para palabras clave particulares que tenían una pantalla diseñada para la misma. El valor predeterminado de la puja solía mostrarse como 0 0.25, que el postor incluso podría cambiar.

había un lugar más donde esta oferta predeterminada solía aparecer y también se podía cambiar a otro valor. El cliente vino con una solicitud para cambiar el valor predeterminado de $0.25 a 0 0.5, pero mencionó solo la pantalla obvia.,

durante nuestra discusión de lluvia de ideas, nos olvidamos (?) sobre esta otra pantalla porque no se usó mucho para ese propósito. Pero mientras probaba cuando ejecuté el caso básico de la oferta de being 0.5 y comprobé de extremo a extremo, descubrí que el cronjob para el mismo estaba fallando porque en un lugar estaba encontrando $0.25.

informé de esto a mi equipo e hicimos el cambio y lo entregamos con éxito el mismo día.

#2) bajo el mismo proyecto (mencionado anteriormente), se nos pidió que agregáramos un pequeño campo de texto para notas/comentarios para pujar., Fue una implementación muy simple y nos comprometimos a entregar el mismo día.

Por lo tanto, como se mencionó anteriormente, probé todas las reglas de negocio y casos de uso a su alrededor y cuando hice algunas pruebas de validación, descubrí que cuando ingresé una combinación de caracteres especiales como </>, la página se bloqueó.

lo pensamos y descubrimos que los licitadores reales no usarán tales combinaciones en ningún caso. Por lo tanto, lo publicamos con una nota bien redactada sobre el tema., El cliente aceptó que como un error, pero acordó con nosotros para implementarlo más tarde porque era un error grave, pero no uno anterior.

#3) recientemente, estaba trabajando en un proyecto de aplicación móvil, y teníamos el requisito de actualizar la hora de entrega que se muestra en la aplicación según la zona horaria. No solo iba a ser probado en la aplicación, sino también para el servicio web.

mientras el equipo de desarrollo estaba trabajando en la implementación, creé los scripts de automatización para las pruebas del servicio web y los scripts de base de datos para cambiar la zona horaria del elemento de entrega., Esto ahorró mis esfuerzos y pudimos lograr mejores resultados en un corto período de tiempo.

la Cordura Pruebas Vs Pruebas de Regresión

a continuación se presentan algunas diferencias entre los dos:

Estrategia Para el Testing de aplicaciones Móviles

Usted debe estar preguntándose por qué estoy mencionando específicamente sobre aplicaciones móviles aquí?

la razón es que el sistema operativo y la versión del navegador para aplicaciones web o de escritorio no varían mucho y, especialmente, los tamaños de pantalla son estándar. Pero con las aplicaciones móviles, el tamaño de la pantalla, la red móvil, las versiones del sistema operativo, etc afectan la estabilidad, la apariencia y, en resumen, el éxito de su aplicación móvil.,

Por lo tanto, una formulación de estrategia se vuelve crítica cuando realiza estas pruebas en una aplicación móvil porque un fallo puede causarle grandes problemas. Las pruebas deben realizarse de manera inteligente y con precaución.

los siguientes son algunos consejos para ayudarlo a realizar esta prueba con éxito en una ‘aplicación móvil’:

#1) en primer lugar, analice el impacto de la versión del sistema operativo en la implementación con su equipo.

Trate de encontrar respuestas a preguntas como, ¿el comportamiento será diferente entre las versiones? ¿Funcionará la implementación en la versión soportada más baja o no?, ¿Habrá problemas de rendimiento para la implementación de versiones? ¿Hay alguna característica específica del sistema operativo que pueda afectar el comportamiento de la implementación? sucesivamente.

#2) en la nota anterior, analizar para los modelos de teléfono también es decir, ¿hay alguna característica del teléfono que afectará la implementación? ¿Es la implementación de cambios de comportamiento con GPS? ¿Está cambiando el comportamiento de implementación con la cámara del teléfono? sucesivamente. Si descubre que no hay impacto, evite probar en diferentes modelos de teléfonos.,

#3) a menos que haya cambios en la interfaz de usuario para la implementación, recomendaría mantener las pruebas de interfaz de usuario con la menor prioridad, puede informar al equipo (si lo desea) que la interfaz de usuario no se probará.

#4) para ahorrar tiempo, evite probar en buenas redes porque es obvio que la implementación va a funcionar como se espera en una red fuerte. Recomendaría comenzar con las pruebas en una red 4G o 3G.

#5) Esta prueba debe hacerse en menos tiempo, pero asegúrese de hacer al menos una prueba de campo a menos que sea un simple cambio de interfaz de usuario.,

#6) si debe probar una matriz de diferentes sistemas operativos y su versión, le sugeriría que lo haga de una manera inteligente. Por ejemplo, elija los pares más bajos, medios y más recientes de la versión del sistema operativo para las pruebas. Puede mencionar en el documento de lanzamiento que no todas las combinaciones se prueban.

#7) en una línea similar, para la prueba de cordura de implementación de interfaz de usuario, use tamaños de pantalla pequeños, medianos y grandes para ahorrar tiempo. También puede utilizar un simulador y emulador.,

medidas de precaución

Las pruebas de Cordura se realizan cuando se está quedando corto de tiempo y, por lo tanto, no es posible ejecutar todos y cada uno de los casos de prueba y, lo que es más importante, no se le da suficiente tiempo para planificar sus pruebas. Para evitar los juegos de culpa, es mejor tomar medidas de precaución.

en tales casos, la falta de comunicación escrita, la documentación de las pruebas y la falta de salidas son bastante comunes.,

para asegurarse de que no es víctima de esto, asegúrese de que:

• nunca acepte una compilación para probar hasta que no se le dé un requisito escrito compartido por el cliente. Sucede que los clientes comunican cambios o nuevas implementaciones verbalmente o en chat o un simple 1 liner en un correo electrónico y esperan que tratemos eso como un requisito. Obligue a su cliente a proporcionar algunos puntos básicos de funcionalidad y criterios de aceptación.
• Siempre tome notas aproximadas de sus casos de prueba y errores si no tiene tiempo suficiente para escribirlos cuidadosamente. Nunca dejes a estos indocumentados., Si hay algo de tiempo, compártalo con su líder o equipo para que si falta algo puedan señalarlo fácilmente.
• Si usted y su equipo tienen poco tiempo, asegúrese de que los errores están marcados en el estado apropiado en un correo electrónico? Puede enviar por correo electrónico la lista completa de errores al equipo y hacer que los desarrolladores los marquen adecuadamente. Siempre mantenga la pelota en la cancha del otro.
• Si tiene Automation Framework listo, use eso y evite hacer pruebas manuales, de esa manera en menos tiempo puede cubrir más.,
• Evite el escenario de» lanzamiento en 1 hora » a menos que esté 100% seguro de que podrá entregar.
• Por último, pero no menos importante, como se mencionó anteriormente, redactar un correo electrónico de liberación detallada comunicando lo que se prueba, lo que se deja fuera, razones, riesgos, qué errores se resuelven, lo que se ‘más tarde’, etc.

como QA, debe juzgar cuál es la parte más importante de la implementación que debe probarse y cuáles son las partes que se pueden omitir o probar de forma básica.,

incluso en poco tiempo, planifique una estrategia sobre cómo desea hacerlo y podrá lograr lo mejor en el marco de tiempo dado.

Smoke Testing

Smoke Testing no es una prueba exhaustiva, pero es un grupo de pruebas que se ejecutan para verificar si las funcionalidades básicas de esa compilación en particular funcionan bien como se espera o no. Esta es y siempre debe ser la primera prueba que se haga en cualquier ‘nueva’ construcción.,

Cuando el equipo de desarrollo lanza una compilación al QA para pruebas, obviamente no es posible probar toda la compilación y verificar inmediatamente si alguna de las implementaciones tiene errores o si alguna de las funcionalidades de trabajo está rota.

a la luz de esto, ¿cómo se asegurará un QA de que las funcionalidades básicas funcionen correctamente?

la respuesta a esto será realizar una prueba de humo.

una vez que las pruebas se marcan como pruebas de humo (en el conjunto de pruebas) pasan, solo entonces la compilación es aceptada por el QA para pruebas en profundidad y/o regresión., Si alguna de las pruebas de smoke falla, la compilación se rechaza y el equipo de desarrollo necesita solucionar el problema y lanzar una nueva compilación para pruebas.

teóricamente, la prueba de humo se define como una prueba a nivel de superficie para certificar que la compilación proporcionada por el equipo de desarrollo al equipo de control de calidad está lista para pruebas adicionales. Esta prueba también es realizada por el equipo de desarrollo antes de lanzar la compilación al equipo de control de calidad.

esta prueba se utiliza normalmente en pruebas de integración, pruebas de sistema y pruebas de nivel de aceptación. Nunca trate esto como un sustituto de la prueba completa de extremo a extremo real., Se compone de pruebas positivas y negativas dependiendo de la implementación de la construcción.

ejemplos de pruebas de humo

esta prueba se utiliza normalmente para la integración, la aceptación y las pruebas del sistema.

en mi carrera como QA, siempre acepté una construcción solo después de haber realizado una prueba de humo. Por lo tanto, vamos a entender lo que es una prueba de humo desde la perspectiva de todas estas tres pruebas, con algunos ejemplos.

#1) Pruebas de aceptación

cada vez que se lanza una compilación al QA, se debe realizar una prueba de humo en forma de prueba de aceptación.,

en esta prueba, la primera y más importante prueba de humo es verificar la funcionalidad básica esperada de la implementación. Así, debes verificar todas las implementaciones para esa compilación en particular.

tomemos los siguientes ejemplos como implementaciones realizadas en una compilación para comprender las pruebas de humo para ellas:

• implementamos la funcionalidad de inicio de sesión para permitir que los controladores registrados inicien sesión con éxito.
• implementó la funcionalidad del panel de control para mostrar las rutas que un controlador debe ejecutar hoy.,
• implementó la funcionalidad para mostrar un mensaje apropiado si no existen rutas para un día determinado.

en la compilación anterior, a nivel de aceptación, la prueba de humo significará verificar que las tres implementaciones básicas están funcionando bien. Si alguno de estos tres está roto, entonces el QA debe rechazar la compilación.

#2) pruebas de integración

esta prueba se realiza generalmente cuando se implementan y prueban los módulos individuales., En el nivel de prueba de integración, esta prueba se realiza para asegurarse de que toda la integración básica y las funcionalidades de extremo a extremo funcionen correctamente como se espera.

Puede ser la integración de dos módulos o todos los módulos juntos, por lo tanto, la complejidad de la prueba de humo variará dependiendo del nivel de integración.

consideremos los siguientes ejemplos de implementación de integración para esta prueba:

• implementó la integración de los módulos route y stops.
• implementó la integración de la actualización de estado de llegada y reflejará lo mismo en la pantalla de paradas.,
• implementó la integración de los módulos de funcionalidad de recogida completa hasta la entrega.

en esta compilación, la prueba de humo no solo verificará estas tres implementaciones básicas, sino que para la tercera implementación, algunos casos también verificarán la integración completa. Ayuda mucho averiguar los problemas que se introducen en la integración y los que pasaron desapercibidos por el equipo de desarrollo.

#3) pruebas del sistema

como su propio nombre indica, para el nivel del sistema, las pruebas de humo incluyen pruebas para los flujos de trabajo más importantes y comúnmente utilizados del sistema., Esto se hace solo después de que el sistema completo esté listo & probado, y esta prueba para el nivel del sistema también se puede denominar prueba de humo antes de la prueba de regresión.

antes de iniciar la regresión del sistema completo, las características básicas de extremo a extremo se prueban como parte de la prueba de humo. El conjunto de pruebas de humo para el sistema completo se compone de los casos de prueba de extremo a extremo que los usuarios finales van a usar con mucha frecuencia.

esto generalmente se hace con la ayuda de herramientas de automatización.,

importancia en la metodología SCRUM

hoy en día, los proyectos apenas siguen la metodología Waterfall en la implementación de proyectos, en su mayoría todos los proyectos siguen Agile y SCRUM solamente. En comparación con el método tradicional de cascada, las pruebas de humo son muy apreciadas en SCRUM y Agile.

trabajé durante 4 años en SCRUM. Y como sabemos que en SCRUM, los sprints son de menor duración y, por lo tanto, es de extrema importancia hacer esta prueba, para que las compilaciones fallidas puedan ser reportadas inmediatamente al equipo de desarrollo y corregidas también.,

Los siguientes son algunos consejos sobre la importancia de esta prueba en SCRUM:

• fuera del sprint de quince días, el medio tiempo se asigna al QA, pero a veces las compilaciones al QA se retrasan.
• en sprints, es mejor para el equipo que los problemas se informen en una etapa temprana.
• Cada historia tiene un conjunto de criterios de aceptación, por lo tanto, probar los primeros 2-3 criterios de aceptación es igual a la prueba de humo de esa funcionalidad. Los clientes rechazan la entrega si un único criterio está fallando.,
• imagínese lo que sucederá si son 2 días que el equipo de desarrollo le entregó la compilación y solo quedan 3 días para la demostración y se encuentra con un fallo de funcionalidad básica.
• En promedio, un sprint tiene historias que van de 5 a 10, por lo tanto, cuando se da la compilación, es importante asegurarse de que cada historia se implementa como se espera antes de aceptar la compilación en las pruebas.
• cuando se va a probar y retroceder el sistema completo, se dedica un sprint a la actividad., Una quincena quizás un poco menos para probar todo el sistema, de ahí que sea muy importante verificar las funcionalidades más básicas antes de iniciar la regresión.

prueba de humo Vs prueba de aceptación de construcción

la prueba de humo está directamente relacionada con la prueba de aceptación de construcción (BAT).

en BAT, hacemos las mismas pruebas-para verificar si la compilación no ha fallado y que el sistema está funcionando bien o no. A veces, sucede que cuando se crea una compilación, se introducen algunos problemas y cuando se entrega, la compilación no funciona para el control de calidad.,

yo diría que BAT es parte de una comprobación de humo porque si el sistema está fallando, ¿cómo puede usted como QA aceptar la compilación para pruebas? No solo las funcionalidades, el sistema en sí tiene que funcionar antes de que el control de calidad proceda con las pruebas en profundidad.

ciclo de prueba de humo

el siguiente diagrama de flujo explica el ciclo de prueba de humo.

una vez que una compilación se implementa en un QA, el ciclo básico seguido es que si la prueba de smoke pasa, la compilación es aceptada por el equipo de QA para pruebas adicionales, pero si falla, la compilación es rechazada hasta que se corrijan los problemas reportados.,

ciclo de Prueba

¿quién debe realizar la prueba de humo?

no todo el equipo está involucrado en este tipo de pruebas para evitar el desperdicio de tiempo de todos los QAS.

Las pruebas de humo son idealmente realizadas por el líder de QA que decide en función del resultado si pasar la compilación al equipo para pruebas adicionales o rechazarla. O en ausencia del líder, los propios QA también pueden realizar esta prueba.

a veces, cuando el proyecto es a gran escala, un grupo de QA también puede realizar esta prueba para comprobar si hay algún showstoppers., Pero esto no es así en el caso de SCRUM porque SCRUM es una estructura plana sin clientes potenciales o gerentes y cada probador tiene sus propias responsabilidades hacia sus historias.

Por lo tanto, los QA individuales realizan esta prueba para las historias que poseen.

¿por qué debemos automatizar las pruebas de humo?

esta prueba es la primera que se realiza en una compilación publicada por el equipo de desarrollo. En base a los resultados de esta prueba, se realizan pruebas adicionales (o se rechaza la compilación).,

la mejor manera de hacer esta prueba es usar una herramienta de automatización y programar la suite smoke para que se ejecute cuando se cree una nueva compilación. Usted puede estar pensando Por qué debería «automatizar el conjunto de pruebas de humo»?

veamos el siguiente caso:

digamos que está a una semana de su lanzamiento y de los 500 casos de prueba totales, su conjunto de pruebas de humo consta de 80-90. Si comienza a ejecutar todos estos casos de prueba 80-90 manualmente, imagine cuánto tiempo tomará? Creo que 4-5 días (mínimo).,

pero si usa la automatización y crea scripts para ejecutar todos estos casos de prueba 80-90, lo ideal es que se ejecuten en 2-3 horas y tendrá los resultados al instante. ¿No le ahorró su precioso tiempo y le dio los resultados sobre el build-in mucho menos tiempo?

hace 5 años, estaba probando una aplicación de proyección financiera, que tomaba información sobre su salario,ahorros, etc., y proyectó sus impuestos, ahorros, ganancias dependiendo de las reglas financieras. Junto con esto, tuvimos personalización para los países que dependen del país y sus reglas fiscales utilizadas para cambiar (en el código).,

para este proyecto, tuve 800 casos de prueba y 250 fueron casos de prueba de humo. Con el uso de selenio, podríamos automatizar fácilmente y obtener los resultados de esos 250 casos de prueba en 3-4 horas. No solo nos salvó el tiempo, sino que nos mostró lo antes posible lo de los showstoppers.

Por lo tanto, a menos que sea imposible automatizar, tome la ayuda de la automatización para esta prueba.

ventajas y desventajas

primero echemos un vistazo a las ventajas, ya que tiene mucho que ofrecer en comparación con sus pocas desventajas.

Ventajas:

• Fácil de realizar.
• Reduce el riesgo.,
• Los defectos se identifican en una etapa muy temprana.
• Ahorra esfuerzos, tiempo y dinero.
• Se ejecuta rápidamente si está automatizado.
• menos riesgos y problemas de integración.
• Mejora la calidad general del sistema.

Desventajas:

• Esta prueba no es igual o un sustituto para completar las pruebas funcionales.
• incluso después de que pase la prueba de humo, puede encontrar errores de showstopper.,
• este tipo de pruebas es más adecuado si se puede automatizar de lo contrario se gasta mucho tiempo en la ejecución manual de los casos de prueba, especialmente en proyectos a gran escala que tienen alrededor de 700-800 casos de prueba.

las pruebas de humo definitivamente se deben hacer en cada compilación, ya que señalan los principales fallos y obstáculos en una etapa muy temprana. Esto se aplica no solo a las nuevas funcionalidades, sino también a la integración de Módulos, la solución de problemas y la improvisación. Es un proceso muy simple de realizar y obtener el resultado correcto.,

esta prueba se puede tratar como el punto de entrada para la prueba funcional completa de la funcionalidad o del sistema (como un todo). Pero antes de eso, el equipo de control de calidad debe tener muy claro qué pruebas se deben hacer como pruebas de humo. Estas pruebas pueden minimizar los esfuerzos, ahorrar tiempo y mejorar la calidad del sistema. Ocupa un lugar muy importante en los sprints, ya que el tiempo en los sprints es menor.

esta prueba se puede hacer tanto manualmente como con la ayuda de herramientas de automatización. Pero la mejor y preferida manera es utilizar herramientas de automatización para ahorrar tiempo.,

diferencia entre el humo y la prueba de la cordura

La mayoría de las veces nos confundimos entre el significado de la prueba de la cordura y la prueba del humo. En primer lugar, estas dos pruebas son muy «diferentes» y se realizan durante diferentes etapas de un ciclo de pruebas.

a continuación se muestra una representación diagramática de sus diferencias:

SMOKE TESTING

• Esta prueba se originó en la práctica de prueba de hardware de encender una nueva pieza de hardware por primera vez y considerarla un éxito si no se incendia y humea. En la industria del software, esta prueba es un enfoque superficial y amplio mediante el cual se prueban todas las áreas de la aplicación sin entrar demasiado en profundidad.,
• Una prueba de humo está programada, ya sea usando un conjunto escrito de pruebas 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.
• esta prueba se lleva a cabo para asegurar si las funciones más cruciales de un programa están funcionando, pero no molestando con los detalles más finos. (Como la verificación de compilación).
• esta prueba es una comprobación de estado normal de la compilación de una aplicación antes de llevarla a prueba en profundidad.,

prueba de cordura

• Una prueba de cordura es una prueba de regresión estrecha que se centra en una o algunas áreas de funcionalidad. Las pruebas de cordura suelen ser estrechas y profundas.
• esta prueba Generalmente no es programada.
• esta prueba se utiliza para determinar que una pequeña sección de la aplicación sigue funcionando después de un cambio menor.
• esta prueba es una prueba superficial, se realiza siempre que una prueba superficial sea suficiente para demostrar que la aplicación está funcionando de acuerdo con las especificaciones. Este nivel de pruebas es un subconjunto de pruebas de regresión.,
• Esto es para verificar si los requisitos se cumplen o no, verificando todas las características primero.