Enfoques de pruebas funcionales y consideraciones ágiles

Iniciado por Mr. Bones, Agosto 08, 2023, 11:24:34 AM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

8 de Agosto del 2023

Hola Hola comunidad, hoy vamos a ver una introduccion simpificada de las pruebas funcionales y su consideraciones ante un marco de trabajo Ágile (scrum o Kanban)

Enfoques de pruebas funcionales y consideraciones ágiles
La prueba de funcionalidad es el examen de la respuesta de un sistema codificado al uso esperado. Tenga en cuenta que no habla de apariencia cosmética, rendimiento, seguridad o cumplimiento de ningún tipo.



¿Qué es la prueba de funcionalidad?
La prueba funcional es un proceso de verificación de que un sistema funciona como se espera cuando sus características son ejercidas por otro sistema o directamente por un usuario. Esto significa que se presta muy bien a las definiciones de casos de prueba y casos de uso que pueden proporcionar una base estable y repetible para evaluar el progreso del desarrollo del sistema.
Toda la gama del proceso de desarrollo está bajo el control de la verificación de la funcionalidad.

Las pruebas unitarias deben comenzar desde el principio para garantizar que cada bloque de código realice la manipulación prevista de las entradas en las salidas deseadas para el siguiente módulo.
Las pruebas de integración aseguran que los módulos de la unidad se conectan entre sí como se esperaba y transmiten datos y comandos a través del sistema según las especificaciones para las que fue construido.
Las comprobaciones de cordura verifican que las modificaciones y correcciones aplicadas al cuerpo del código no tengan efectos secundarios inesperados en, aparentemente, partes no relacionadas del sistema.
Las pruebas de regresión verifican que las adiciones de características posteriores y las correcciones de errores no deshagan los esfuerzos anteriores ni interactúen con ellos para causar problemas completamente nuevos.
La aceptación de la usabilidad es la operación real del sistema en el contexto en el que fue diseñado para ser utilizado y es la puerta de entrada a la implementación.
Todos los anteriores son variedades de pruebas funcionales y todos contribuyen a la creación de un sistema de software que está listo para implementarse para el uso previsto.

Enfoques de pruebas funcionales

Tres enfoques se utilizan comúnmente para implementar pruebas funcionales.

Pruebas de caja negra
La prueba de caja negra toma una serie de entradas y busca la generación de salidas específicas. La idea detrás del nombre es que el contenido del código bajo prueba es desconocido para el caso de prueba y, por definición, para el probador que solo se preocupa por la verificación de funciones.

Pruebas de caja blanca
Las pruebas de caja blanca están en el otro extremo del espectro. Se basan en saber exactamente qué está pasando con el código bajo prueba y las pruebas se ejecutan principalmente para verificar la solidez del código en lugar de su funcionalidad absoluta.
Las pruebas de caja blanca se realizan al comienzo del proceso de desarrollo con pruebas unitarias y en las primeras partes de la fase de integración. El trabajo de prueba de caja negra es típico de las últimas fases donde la respuesta a escenarios operativos específicos es importante.

Pruebas de caja gris
El tercer tipo de prueba es una mezcla de caja blanca y negra. Esto sucede a medida que el desarrollo avanza hacia una zona de cruce hacia el final de la integración y el comienzo de la usabilidad.

Obviamente, las pruebas de caja negra se prestan a casos de prueba estrechamente definidos y resultados de prueba rigurosamente definidos. Estas son pruebas que pueden realizar los técnicos de prueba que son capaces de seguir cuidadosamente las instrucciones del plan de prueba y documentar meticulosamente los resultados.

Las pruebas de caja blanca las realizan mejor los ingenieros de software que entienden cómo se escribe el código y las permutaciones de cómo se espera que funcione.


Pruebas funcionales en un entorno ágil



El paso del SDLC en cascada al desarrollo Agile y de allí a la Integración Continua y luego a Dev/Ops ha impulsado con fuerza el paradigma de la calidad del software. Con el cambio a Agile en particular, el tiempo de prueba se consideró un lujo y, por lo tanto, algo prescindible. El retroceso en esto ha sido brutal.

Las aplicaciones lanzadas sin suficientes pruebas fueron atacadas por las reseñas de los clientes en Internet que hace que las malas noticias viajen como un avión supersónico. Una consecuencia lógica de esta situación ha sido el impulso hacia la automatización de pruebas y tiene mucho sentido en los entornos de desarrollo de alta velocidad de la actualidad. Desafortunadamente, esto ha llevado a una expectativa infundada de que todas las pruebas deben automatizarse y que curarán todos los males del desarrollo.

Automatización de pruebas funcionales
La automatización de pruebas funciona mejor cuando hay una prueba que está bien definida y debe realizarse muchas veces o requiere una configuración de sistema avanzada muy compleja. Las pruebas que varían de una versión a otra, requieren la cognición humana (piense en la validación de la interfaz de usuario intuitiva) o necesitan una variación ad hoc, como en las pruebas exploratorias, no son buenas candidatas para la automatización. Los scripts de prueba escritos para pruebas inadecuadas incurrirán en costos de mantenimiento de scripts que resultarán en su abandono final debido a fallas debido a errores de diseño de prueba.

Documentación de prueba funcional
La documentación de prueba es oro. Por mucho que la presión por el desarrollo rápido y los intervalos de lanzamiento cortos empujen la calidad a tomar atajos, la documentación es demasiado valiosa para ignorarla. La automatización de pruebas, cuando corresponda, ayudará a documentar los procesos de prueba, al igual que la finalización cuidadosa de los informes de defectos que documentan las pruebas de regresión.

Y reconozca que se necesita una combinación de talentos en todo el desarrollo de software. Agile exige la integración de la calidad y el desarrollo con la gestión de productos. Utilice esta motivación para hacer que los equipos sean cada vez más granulares y sembrarlos con ingenieros de prueba. Poner la calidad y el desarrollo en asientos adyacentes poliniza las dos disciplinas en beneficio de ambas.






Me despido y cualquier cosa me escriben.




Mr Bones

Mr. Bones