Prueba de humo versus prueba de cordura: diferencia con ejemplos

smoke testing vs sanity testing

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 las pruebas de cordura y humo con ejemplos simples.

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

Lo que vas a aprender:

• Pruebas de cordura
• Mi experiencia
• Pruebas de cordura frente a pruebas de regresión
• Estrategia para pruebas de aplicaciones móviles
• Medidas de precaución
• Prueba de humo
• Ejemplos de pruebas de humo
  • # 1) Prueba de aceptación
  • # 2) Prueba de integración
  • # 3) Prueba del sistema
• Importancia en la metodología SCRUM
• Prueba de humo vs prueba de aceptación de construcción
• Ciclo de prueba de humo
• ¿Quién debe realizar la prueba de humo?
• ¿Por qué debemos automatizar las pruebas de humo?
• Ventajas y desventajas
• Diferencia entre pruebas de humo y cordura
  • PRUEBAS DE HUMO
  • PRUEBAS DE SANIDAD
• Lectura recomendada

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 , UI, SO o pruebas de navegador.

Por lo tanto, yo definiría,

'Sanity Testing es una ejecución de prueba que se realiza para tocar cada implementación y su impacto, pero no de manera exhaustiva o en profundidad, puede incluir pruebas funcionales, de interfaz de usuario, de versión, etc., según la implementación y su impacto'.

¿No caemos todos en una situación en la que tenemos que cerrar la sesión en uno o dos días, pero la compilación para las pruebas aún no se ha publicado?

preguntas y respuestas de la entrevista de ingeniería de software pdf

Ah, sí, te apuesto a que también debes haber enfrentado esta situación al menos una vez en tu experiencia de pruebas de software. Bueno, lo enfrenté mucho porque mi (s) proyecto (s) eran en su mayoría ágiles y en ocasiones nos pedían que lo entregáramos el mismo día. Vaya, ¿cómo podría probar y lanzar la compilación en un lapso 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 más tiempo. ¿Cómo podría completar todas las pruebas en unas pocas horas, verificar todas las funciones, Insectos y soltarlo?

La respuesta a todos estos problemas fue muy simple, es decir, nada más que usar Estrategia de Sanity Testing.

Cuando hacemos esta prueba para un módulo o funcionalidad o un sistema completo, el Casos de prueba para ejecución se seleccionan de modo que toquen todas las partes importantes de la misma, es decir, pruebas amplias pero poco profundas.

A veces, las pruebas se realizan incluso de forma aleatoria sin casos de prueba. Pero recuerda, La prueba de cordura debe realizarse solo cuando se está quedando sin tiempo, nunca use esto para sus lanzamientos regulares. Teóricamente, esta prueba es un subconjunto de Pruebas 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 usé principalmente una prueba de cordura.

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

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

#1) Siéntese con el gerente y el equipo de desarrollo cuando discutan 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, a qué área 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 obstaculizado (en el peor de los casos).

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

#3) Mantenga su banco de pruebas listo según la implementación y si cree que hay señales de alerta, como la creación de datos específicos, si un banco de pruebas llevará tiempo (y es una prueba importante para el lanzamiento), levante esas banderas de inmediato e informe a su gerente o PO sobre la barricada.

El hecho de que el cliente quiera lo antes posible, no significa que se lanzará un control de calidad incluso si está medio probado.

#4) Llegue a un acuerdo con su equipo y gerente de que, debido a la escasez de tiempo, solo comunicará los errores al equipo de desarrollo y el proceso formal de agregar y marcar los errores para las diferentes etapas en la herramienta de seguimiento de errores se realizará más adelante para 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, primero pruebe las reglas comerciales y todos los casos de uso. Puede guardar pruebas como la validación de un campo, navegación, etc. para más adelante.

#7) Independientemente de los errores que encuentre, tome nota de todos ellos e intente informarlos juntos a los desarrolladores en lugar de informarlos individualmente porque será fácil para ellos trabajar en un grupo.

#8) Si tiene un requisito para la general Pruebas de rendimiento o Stress o Load Testing, luego asegúrese de tener un marco de automatización adecuado para el mismo. Porque es casi imposible probarlos manualmente 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 lanzamiento o el documento, mencione todos los casos de prueba que ejecutó, los errores encontrados con un marcador de estado y si quedó algo no probado mencionarlo con las razones ” Trate de escribir una historia clara sobre sus pruebas que les transmita a todos lo que se ha probado, verificado y lo que no.

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 mostrar anuncios emergentes basados ​​en las palabras clave. Los anunciantes solían realizar la oferta para determinadas palabras clave que tenían una pantalla diseñada para las mismas. El valor de oferta predeterminado solía mostrarse como $ 0.25, que el postor incluso podría cambiar.

Había un lugar más donde solía aparecer esta oferta predeterminada 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.5, pero mencionó solo la pantalla obvia.

Durante nuestra discusión de lluvia de ideas, nos olvidamos (?) De 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 $ 0.5 y verifiqué de un extremo a otro, encontré que el cronjob para el mismo estaba fallando porque en un lugar estaba encontrando $ 0.25.

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

#2) En el mismo proyecto (mencionado anteriormente), se nos pidió que agreguemos un pequeño campo de texto para notas / comentarios para la licitación. Fue una implementación muy simple y nos comprometimos a entregarla el mismo día.

Por lo tanto, como se mencionó anteriormente, probé todas las reglas comerciales y los casos de uso a su alrededor y cuando hice algunas pruebas de validación, descubrí que cuando ingresaba una combinación de caracteres especiales como, la página se bloqueaba.

Lo pensamos y nos dimos cuenta de que los postores reales no utilizarán en ningún caso esas combinaciones. Por lo tanto, lo publicamos con una nota bien redactada sobre el tema. El cliente lo aceptó como un error, pero acordó con nosotros implementarlo más tarde porque era un error grave pero no 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 debía probarse en la aplicación, sino también para el servicio web.

Mientras el equipo de desarrollo trabajaba en la implementación, creé los scripts de automatización para las pruebas del servicio web y los scripts de la base de datos para cambiar la zona horaria del elemento de entrega. Esto salvó mis esfuerzos y pudimos lograr mejores resultados en poco tiempo.

Pruebas de cordura frente a pruebas de regresión

A continuación se muestran algunas diferencias entre los dos:

Estrategia para pruebas de aplicaciones móviles

Debes preguntarte por qué menciono 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, el aspecto y, en definitiva, el éxito de su aplicación móvil.

Por lo tanto, la formulación de una estrategia se vuelve crítica cuando realiza esta prueba en una aplicación móvil porque una falla puede causarle un gran problema. La prueba debe realizarse de manera inteligente y con precaución también.

A continuación, se incluyen algunos consejos que le ayudarán 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 en las versiones? ¿La implementación funcionará en la versión compatible más baja o no? ¿Habrá problemas de rendimiento para la implementación de versiones? ¿Existe alguna característica específica del sistema operativo que pueda afectar el comportamiento de la implementación? etc.

#2) En la nota anterior, analice también los modelos de teléfono, es decir, ¿hay alguna característica del teléfono que afectará la implementación? ¿La implementación del comportamiento cambia con GPS? ¿Está cambiando el comportamiento de implementación con la cámara del teléfono? etc. Si encuentra que no hay ningún impacto, evite probar en diferentes modelos de teléfono.

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

#4) Para ahorrar tiempo, evite realizar pruebas en buenas redes porque es obvio que la implementación funcionará como se espera en una red sólida. Recomendaría comenzar con la prueba en una red 4G o 3G.

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

#6) Si debe probar una matriz de diferentes sistemas operativos y su versión, le sugiero que lo haga de una manera inteligente. Por ejemplo, elija los pares de versión de SO más baja, media y más reciente para realizar la prueba. Puede mencionar en el documento de lanzamiento que no se prueban todas las combinaciones.

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

Medidas de precaución

Las pruebas de cordura se realizan cuando se está quedando sin 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 prueba y las pérdidas son bastante comunes.

Para asegurarse de no ser víctima de esto, asegúrese de que:

• Nunca acepte una compilación para probarla hasta que no reciba un requisito escrito compartido por el cliente. Sucede que los clientes comunican los cambios o las nuevas implementaciones verbalmente o en el chat o con un simple 1 línea en un correo electrónico y esperan que lo tratemos 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 de manera ordenada. Nunca dejes a estos indocumentados. Si hay algo de tiempo, compártelo con tu 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. Mantenga siempre la pelota en la cancha del otro.
• Si usted tiene Marco de automatización listo, úsalo y evita hacer ManualTesting , de esa forma en menos tiempo podrás 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, redacte un correo electrónico de lanzamiento detallado que comunique lo que se prueba, lo que se omite, las razones, los riesgos, los errores que se resuelven, lo que está 'actualizado', 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 quiere hacerlo y podrá lograr lo mejor en el período de tiempo dado.

Prueba de humo

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 esperaba o no. Esta es y siempre debe ser la primera prueba que se debe realizar en cualquier compilación 'nueva'.

cómo abrir archivos .jar con java

Cuando el equipo de desarrollo lanza una compilación al control de calidad para su prueba, obviamente no es posible probar toda la compilación y verificar de inmediato si alguna de las implementaciones tiene errores o si alguna de las funciones de trabajo está rota.

A la luz de esto, ¿cómo se asegurará un control de calidad de que las funcionalidades básicas funcionan bien?

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), solo entonces el control de calidad acepta la compilación para realizar pruebas en profundidad y / o regresión. Si alguna de las pruebas de humo falla, la compilación se rechaza y el equipo de desarrollo debe solucionar el problema y lanzar una nueva compilación para probar.

Teóricamente, la prueba de humo se define como una prueba a nivel de superficie para certificar que la construcción proporcionada por el equipo de desarrollo al equipo de control de calidad está lista para más pruebas. Esta prueba también la realiza el equipo de desarrollo antes de entregar la compilación al equipo de control de calidad.

Esta prueba se usa normalmente en pruebas de integración, pruebas de sistemas y pruebas de nivel de aceptación. Nunca trate esto como un sustituto de la prueba completa de un extremo a otro. . Se compone de pruebas positivas y negativas según la implementación de la compilación.

Ejemplos de pruebas de humo

Esta prueba se utiliza normalmente para integración, aceptación y Prueba del sistema .

En mi carrera como QA, siempre acepté una construcción solo después de haber realizado una prueba de humo. Entonces, entendamos qué es una prueba de humo desde la perspectiva de estas tres pruebas, con algunos ejemplos.

# 1) Prueba de aceptación

Siempre que se envíe una compilación al control de calidad, realice una prueba de humo en forma de Test de aceptación debería estar hecho.

En esta prueba, la primera y más importante prueba de humo es verificar la funcionalidad básica esperada de la implementación. De esta manera, debe 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 esos:

• Se implementó la funcionalidad de inicio de sesión para permitir que los controladores registrados inicien sesión correctamente.
• Implementó la funcionalidad del tablero para mostrar las rutas que un conductor debe ejecutar hoy.
• Se implementó la funcionalidad para mostrar un mensaje apropiado si no existen rutas para un día determinado.

En la versión anterior, en el nivel de aceptación, la prueba de humo significará verificar que las tres implementaciones básicas funcionan bien. Si alguno de estos tres está roto, el control de calidad debería rechazar la compilación.

# 2) Prueba de integración

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

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á según el nivel de integración.

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

• Implementé la integración de módulos de ruta y paradas.
• Se implementó la integración de la actualización del estado de llegada y se refleja la misma 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 descubrir los problemas que se introducen en la integración y los que pasaron desapercibidos para el equipo de desarrollo.

# 3) Prueba del sistema

Como sugiere su propio nombre, para el nivel del sistema, la prueba de humo incluye pruebas para los flujos de trabajo más importantes y más utilizados del sistema. Esto se hace solo después de que el sistema completo está listo y probado, y esta prueba a nivel del sistema también se puede denominar prueba de humo antes de prueba de regresión.

Antes de comenzar 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 comprende los casos de prueba de extremo a extremo que los usuarios finales utilizarán 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 MELÉ solamente. En comparación con el método tradicional en cascada, Smoke Testing tiene un gran respeto en SCRUM y Agile.

Trabajé 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 estas pruebas, para que las compilaciones fallidas se puedan informar de inmediato al equipo de desarrollo y corregirlas también.

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

• Fuera del sprint de quince días, el medio tiempo se asigna al control de calidad, pero a veces se retrasa la construcción del control de calidad.
• En los 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 falla un solo criterio.
• Solo imagina lo que sucederá si transcurren 2 días desde que el equipo de desarrollo te entrega la compilación y solo quedan 3 días para la demostración y te encuentras con una falla de funcionalidad básica.
• En promedio, un sprint tiene historias que van de 5 a 10, por lo tanto, cuando se proporciona la compilación, es importante asegurarse de que cada historia se implemente como se espera antes de aceptar la compilación en la prueba.
• Cuando se va a probar y retroceder el sistema completo, se dedica un sprint a la actividad. Una quincena tal vez 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

Las pruebas de humo están directamente relacionadas con las pruebas de aceptación de edificios (BAT).

En BAT, hacemos las mismas pruebas, para verificar si la compilación no ha fallado y si 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 prueba de humo porque si el sistema falla, ¿cómo puede usted, como QA, aceptar la compilación para probarla? 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 se implementa una compilación en un control de calidad, el ciclo básico que se sigue es que si pasa la prueba de humo, el equipo de control de calidad acepta la compilación para realizar más pruebas, pero si falla, la compilación se rechaza hasta que se solucionen los problemas informados.

Ciclo de prueba

¿Quién debe realizar la prueba de humo?

No todo el equipo está involucrado en este tipo de pruebas para evitar la pérdida de tiempo de todos los controles de calidad.

La prueba de humo la realiza idealmente el líder de control de calidad, quien decide en función del resultado si pasar la compilación al equipo para realizar más pruebas o rechazarla. O en ausencia del cliente potencial, los mismos QA también pueden realizar esta prueba.

A veces, cuando el proyecto es a gran escala, un grupo de QA también puede realizar estas pruebas para verificar si hay algún problema. Pero esto no es así en el caso de SCRUM porque SCRUM es una estructura plana sin Leads ni Managers y cada tester tiene sus propias responsabilidades con respecto a sus historias.

Por lo tanto, los QA individuales realizan estas pruebas para las historias que poseen.

¿Por qué debemos automatizar las pruebas de humo?

Esta prueba es la primera prueba que se realiza en una compilación lanzada por los equipos de desarrollo. Según los resultados de esta prueba, se realizan más pruebas (o se rechaza la compilación).

La mejor manera de hacer esta prueba es usar una herramienta de automatización y programar la suite de humo para que se ejecute cuando se cree una nueva construcción. Puede que estés pensando por qué debería “Automatizar la suite de pruebas de humo”?

Veamos el siguiente caso:

Supongamos que está a una semana de su lanzamiento y del total de 500 casos de prueba, su conjunto de pruebas de humo consta de 80-90. Si comienza a ejecutar todos estos 80-90 casos de prueba manualmente, imagínese 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 80-90 casos de prueba, idealmente, estos se ejecutarán en 2-3 horas y tendrá los resultados con usted al instante. ¿No le ahorró su valioso tiempo y le dio los resultados sobre la construcción mucho menos tiempo?

Hace 5 años, estaba probando una aplicación de proyección financiera, que tomaba datos sobre su salario, ahorros, etc., y proyectaba sus impuestos, ahorros y ganancias según las reglas financieras. Junto con esto, tuvimos personalización para países que dependen del país y sus reglas tributarias que solían 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 Selenium, podríamos automatizar fácilmente y obtener los resultados de esos 250 casos de prueba en 3-4 horas. No solo nos ahorró tiempo, sino que nos mostró lo antes posible acerca de los eventos destacados.

Por lo tanto, a menos que sea imposible de 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.
• Funciona rápidamente si está automatizado.
• Menos riesgos y problemas de integración.
• Mejora la calidad general del sistema.

Desventajas:

• Esta prueba no es igual ni sustituye a la prueba funcional completa.
• Incluso después de que pase la prueba de humo, es posible que encuentre errores sorprendentes.
• Este tipo de prueba es más adecuado si puede automatizar; de lo contrario, se dedica mucho tiempo a ejecutar manualmente los casos de prueba, especialmente en proyectos a gran escala que tienen alrededor de 700-800 casos de prueba.

Definitivamente, las pruebas de humo deben realizarse en cada compilación, ya que señala las principales fallas y los aspectos más destacados 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 sencillo 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 el sistema (en su conjunto). Pero antes de eso, El equipo de garantía de calidad debe tener muy claro qué pruebas se realizarán como pruebas de humo. . Esta prueba puede 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 realizar tanto manualmente como con la ayuda de herramientas de automatización. Pero la forma mejor y preferida es utilizar herramientas de automatización para ahorrar tiempo.

Diferencia entre pruebas de humo y cordura

La mayoría de las veces nos confundimos entre el significado de las pruebas de cordura y las pruebas de humo. En primer lugar, estas dos pruebas son ' diferente ”Y se realiza durante las diferentes etapas de un ciclo de prueba.

A continuación se muestra una representación esquemática de sus diferencias:

PRUEBAS DE HUMO

• Esta prueba se originó en el hardware probar la práctica de encender una nueva pieza de hardware por primera vez y considerarla un éxito si no se incendia ni humea. En la industria del software, esta prueba es un enfoque poco profundo 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 mediante 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.
• Esta prueba se realiza para garantizar que las funciones más importantes de un programa estén funcionando, pero sin preocuparse por los detalles más finos. (Como verificación de compilación).
• Esta prueba es un chequeo de salud normal para 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 centra en una o unas pocas áreas de funcionalidad. Las pruebas de cordura suelen ser estrechas y profundas.
• Esta prueba generalmente no está escrita.
• Esta prueba se utiliza para determinar que una pequeña sección de la aplicación aún funciona 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 prueba es un subconjunto de las pruebas de regresión.
• Esto es para verificar si se cumplen los requisitos o no, verificando todas las características en primer lugar.

Espero que tenga claras las diferencias entre estos dos tipos de pruebas de software vastos e importantes. ¡Siéntete libre de compartir tus pensamientos en la sección de comentarios a continuación!

Lectura recomendada

• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Diferencia entre Desktop, Client Server Testing y Web Testing
• Pruebas funcionales versus pruebas no funcionales
• Descarga del libro electrónico Testing Primer
• Pruebas alfa y beta (una guía completa)
• Guía de pruebas de portabilidad con ejemplos prácticos
• Tipos de pruebas de software: diferentes tipos de pruebas con detalles
• Pruebas funcionales frente a pruebas de rendimiento: ¿deben realizarse simultáneamente?