++Pruebas funcionales y no funcionales++
La automatización de pruebas nos permitirá automatizar ambos tipos de pruebas.
++Tipos de pruebas (funcionales y no funcionales)++
Todas pueden ser agrupadas en tres grupos:
excelente resumen! gracias man +
Muy buen resumen
Al principio las pruebas de UI suelen ser más lentas para un ROI, pero a medida que avanza el proyecto ahorran mucho tiempo y esfuerzo y permiten que nos enfoquemos más en las nuevas funcionabilidades.
completamente de acuerdo !
Buen aporte manu!
Yo trabajo en Game Testing y creo que una automatización que nos ahorraría mucho tiempo es referente a las alertas que nos genera el juego al momento de alcanzar determinado objetivo. Ejemplo si eliminas a X enemigos te aparece un premio, se puede automatizar que aparezcan esos enemigos de forma constante y que tu arma este disparando de forma automatizada a ese punto, también sería ideal que la velocidad del juego se pueda incrementar para que el objetivo se alcance en una velocidad significativa.
Una vez vi un documental de DOOM, donde los desarrolladores crearon códigos/trucos para saltarse parte de los niveles o ponerse en los contextos justamente para testear cosas como la que indicas, comportamientos, logros de objetivos, etc.
No me quedo muy claro en esta clase lo de las pruebas de humo y pues en el examen obviamente que falle, asi que aclaro: Las Pruebas de Humo: son una revisión rápida de un producto de software para comprobar que funciona y no tiene defectos evidentes que interrumpan la operación básica del mismo.
Gracias por la información.
Las clasificaría de las siguiente manera Pruebas de Caja Negra
1.Pruebas Funcionales: Se entiende como las funcionalidades del sistemas “Lo que el sistema hace”
2.Pruebas No Funcionales: El objetivo de esta es probar “Como funciona el sistema”
Pruebas de Caja Blanca
3.Pruebas Estructurales: Para poder llevar a cabo estas pruebas, normalmente el tester de tener conocimiento acerca de la tecnología y el stack que se esta empleado
4.Pruebas de Manejo de Cambios: Es probar nuevamente un componente ya aprobado para verificar que no ha sido impacto por actualizaciones.
Excelente aporte, suma mucho a la compresión de las características y clasificaciones de las pruebas.
En las no funcionales agregaría las pruebas de APIs
Definitivamente, mi equipo se beneficiaría de todos estos tipos de pruebas.
Solo falta que logre convencer al jefe.
Las Pruebas de aceptación también conocidas como UAT (User Acceptance Testing)
Automatización Basada en Tipos de Pruebas
La automatización de pruebas es un proceso fundamental en el desarrollo de software para garantizar calidad, eficiencia y rapidez en la entrega de productos. Dependiendo del objetivo y alcance de las pruebas, estas se pueden dividir en dos grandes categorías: pruebas funcionales y pruebas no funcionales. La automatización en cada una de estas tiene enfoques específicos que optimizan su efectividad.
1. Pruebas Funcionales
Las pruebas funcionales se enfocan en validar que la aplicación cumple con los requisitos comerciales y las funcionalidades esperadas por el usuario. Son esenciales para asegurar que el software se comporte de manera correcta y predecible.
1.1 Pruebas Unitarias
1.2 Pruebas de Integración
1.3 Pruebas de Humo (Smoke Tests)
1.4 Pruebas de Regresión
1.5 Pruebas de APIs
1.6 Pruebas de Aceptación
1.7 Pruebas de Interfaz Gráfica de Usuario (UI)
2. Pruebas No Funcionales
Las pruebas no funcionales evalúan aspectos como rendimiento, seguridad y usabilidad, garantizando que la aplicación sea eficiente y confiable.
2.1 Pruebas de Rendimiento
2.2 Pruebas de Seguridad
3. Consideraciones en la Automatización
La combinación de pruebas funcionales y no funcionales automatizadas mejora significativamente la calidad y fiabilidad del software, asegurando un desarrollo ágil y eficiente.
En los procesos de automatización, como se recaudan las evidencias?
Muy buenas pregunta, me surgió la misma duda
Depende de la herramienta. por ejemplo, si automatizas con Selenium tu le puedes indicar directamente mediante código en que momento quieres que se tome el screenshot, mientras que con Playwright las evidencias se toman sin que se lo indiques.
Para automatización las pruebas de regresión son una inversión de tiempo inmediato pero a largo plazo son provechosos al momento de generar cambios en las aplicaciones y necesitar probar todo nuevamente, ahorra mucho tiempo.
Tengo una duda muy puntual, si las smoke test se corren cuando se sale a prod para ver que no falló nada, las de regresión también no? Osea en mi empresa se corren son las de regresión luego de una liberación.
Hola, si en muchos casos es así , dependerá en verdad mucho de la estrategia de pruebas que la empresa determine y que le otorgué mayor valor
Creo que estamos confundiendo TIPOS DE PRUEBA y técnicas de prueba. Entiendo que el smoke test es una técnica e incluyen las pruebas de componente y regresión, para validar que nada se haya roto por si algún componente interactua con la nueva feature.
por lo menos en mi trabajo lo hacemos asi
creo que las pruebas de API son las pruebas que mejor ayudarían en el proceso de mi empresa, ya que la gran mayoría de proyectos se trabajan con API y servicios.
Automatización basada en tipos de pruebas
Hay dos tipos de pruebas que podemos automatizar, las funciones y las no funcionales.
PRUEBAS FUNCIONALES
PRUEBAS NO FUNCIONALES
La automatización de pruebas, nos permite automatizar ambas.
**TIPOS DE PRUEBAS: **
Estas pruebas se pueden agrupar en tres grupos principales:
Las pruebas que podría automatizar son las APIs, porque con ellas puedo evitar esos reprocesos que siempre se presentan, al incluir una nueva feature, o corregir un bug. El hacer el retesting manual nos lleva mucho tiempo y poder automatizarlo, nos podría bajar los costos.
Ojalá Platzi agregue cursos sobre Pruebas de Rendimiento, son muy interesantes.
Pruebas de UI, pruebas end to end
Pruebas de seguridad o pentesting
Sin lugar a dudas las pruebas de Regresión son las que podrían generar mayor utilidad en mi equipo. Optimizan el tiempo y me pueden garantizar la mantenibilidad de un nuevo Release, estoy convencido que para que esto funcione será necesario integrar otro tipo de pruebas.
Respondiendo a la pregunta planteada, definitivamente la automatización de pruebas es útil cuando se ejecutan pruebas de regresión. Yo lo vivo continuamente ya que trabajo como Manual Tester y ocupo horas para probar una funcionalidad, de las muchas que un Sistema pueda tener.