Automatización basada en tipos de pruebas

Pruebas funcionales y no funcionales

• Funcionales: Nos permiten analizar los requisitos comerciales (lo que el cliente va a ver, etc)
• No funcionales: Nos permiten probar las cosas que son necesarias para que el cliente vea y tenga una experiencia agradable. (Rendimiento, seguridad, alacenamiento de datos … etc)

La automatización de pruebas nos permitirá automatizar ambos tipos de pruebas.

Tipos de pruebas (funcionales y no funcionales)

• Pruebas unitarias: pequeños bloques de tu software que puedes ir automatizando y probando una funcionalidad pequeña concreta. Son las más baratas y las hacen los mismos desarrolladores.
• Pruebas de integración: nos permite probar bloques en conjunto.
• Pruebas de humo: son pruebas que se corren después de una liberación o compilación para asegurar que nada se haya “incendiado” y que todo funciona correctamente.
• Pruebas de regresión: Nos va a servir para garantizar que todo sigue funcionando correctamente cuando incluimos nuevas funcionalidades.
• Pruebas de APIs: puedes automatizar pruebas a los endPoints de una API para garantizar que funciona como debe.
• Pruebas de seguridad: su proposito es identificar las vulnerabilidades de seguridad de un sistema (también conocidas como pruebas de Pentesting)
• Pruebas de rendimiento: son un tipo de pruebas no funcionales, por que nos permiten evaluar la estabilidad y aseguran que el software funcione adecuadamente.
• Pruebas de aceptación: Intentan determinar cual es el resultado esperado del cliente
• Pruebas de UI: Son las pruebas de interfaz y nos permiten garantizar que el proyecto interacture como debería. Se pueden hacer por bloques, por funcionalidad o pruebas end-to-end.

Todas pueden ser agrupadas en tres grupos:

• Pruebas unitarias ( como desarrollador )
• Pruebas de API ( desarrollador backend, test automation o QA)
• Pruebas de UI ( pruebas end-to-end )

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.

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.

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.

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”

• Pruebas Unitarias
• Pruebas de Humo
• Pruebas de Integración
• Pruebas de Regresión
• Pruebas de Aceptación

2.Pruebas No Funcionales: El objetivo de esta es probar “Como funciona el sistema”

• Pruebas de estrés
• Pruebas de carga
• Pruebas de rendimiento
• Pruebas de seguridad

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.

Las Pruebas de aceptación también conocidas como UAT (User Acceptance Testing)

Definitivamente, mi equipo se beneficiaría
de todos estos tipos de pruebas.

Solo falta que logre convencer al jefe.

En los procesos de automatización, como se recaudan las evidencias?

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.

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

• Nos permiten analizar los requisitos comerciales
  (Lo que el cliente ve a ver)

PRUEBAS NO FUNCIONALES

• Nos permite ver lo que es necesario para que el usuario tenga una experiencia agradable.
  (Rendimiento, seguridad, almacenamiento de datos)

La automatización de pruebas, nos permite automatizar ambas.

• Pruebas unitarias
  Pequeños bloques de tu software que puedes ir automatizando y probando una funcionalidad pequeña concreta. Son las más baratas y las hacen los mismos desarrolladores.
• Pruebas de integración
  Nos permite probar bloques en conjunto
• Pruebas de humo
  Son pruebas que se corren después de una liberación o compilación para asegurar que nada se haya “incendiado” y que todo funciona correctamente.
• Pruebas de regresión
  Nos va a servir para garantizar que todo sigue funcionando correctamente cuando incluimos nuevas funcionalidades.
• Pruebas de APIs
  Puedes automatizar pruebas a los endPoints de una API para garantizar que funciona como debe.
• Pruebas de seguridad
  Su proposito es identificar las vulnerabilidades de seguridad de un sistema (también conocidas como pruebas de Pentesting)
• Pruebas de rendimiento
  Son un tipo de pruebas no funcionales, por que nos permiten evaluar la estabilidad y aseguran que el software funcione adecuadamente.
• Pruebas de aceptación
  Intentan determinar cual es el resultado esperado del cliente
• Pruebas de UI
  Son las pruebas de interfaz y nos permiten garantizar que el proyecto interacture como debería. Se pueden hacer por bloques, por funcionalidad o pruebas end-to-end.

Estas pruebas se pueden agrupar en tres grupos principales:

• Pruebas unitarias (Como desarrollador)
• Pruebas de API (Desarrollador backend, test automation o QA)
• Pruebas de UI (Pruebas end-to-end)

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.

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.

Donde estoy trabajando actualmente creo que las pruebas de integración y las de aceptacióm

Sin duda automatizar las regresiones seria lo mejor jejeje
aunque tambien automatizar las API´s

En mi equipo de trabajo además de las pruebas funcionales también es necesario automatizar las pruebas de regresión y rendimiento esto ahorraría tiempo en la ejecución de pruebas manuales y por otra parte garantizaría la estabilidad de las aplicaciones y la prestación del servicio.

En mi proyecto, automatizar las pruebas integradas y de aceptación sería lo que más ayudaría.

Considero que las Pruebas de Regresión son fundamentales para garantizar el funcionamiento y confiabilidad de un software.

Las que ahorrarían mucho tiempo en mi caso seria auto. las pruebas de regresión y las mas dificil de implementar seria las de seguridad

Para mi equipo de trabajo y lo que desarrollamos a diario, serían las pruebas unitarias, es el tipo e prueba que más usamos

las pruebas de humo muchas empresas las olvidan y pasan pruebas de regression.

AUTOMATIZACIÓN BASADA EN TIPOS DE PRUEBAS
.
Pruebas funcionales
Permite analizar los requisitos comerciales las cosas que el cliente podrá ver.
.
Pruebas no funcionales
Permitir probar las cosas que son necesarias para que el cliente tenga une buena UX.

• Rendimiento.
• Seguridad.
• Almacenamiento de datos.
• etc.
  .

Pruebas unitarias
Son pequeños bloques de pruebas unitarias del software que se pueden ir automatizando, probando pequeñas funcionalidades son mas accesibles de desarrollar en la practica son hechas por los mismos desarrolladores.
.
Pruebas de integración
Permite unir parte de pruebas unitarias probando estos bloques en conjunto.
.
Pruebas de humo
También conocidas como smooke test. Son pruebas que se ejecutan después de la compilación. Para asegurar que nada se ella “incendiado” que nada se halla dañado en el proceso.
.
Pruebas de regresión
Permiten probar todo lo probado anteriormente garantizando el control de los Bugs.
.
Pruebas de API
Una API (Aplication Programming Interface) o endpoint puede ser automatizada para garantizar que funcionen como deberian.
.
Pruebas de seguridad
Permite identificar las vulnerabilidades de seguridad un sistema conocidas como pruebas de Pentesting.
.
Pruebas de rendimiento
Son pruebas no funcionales, porque permiten evaluar la estabilidad y asegurar que el software funcione adecuadamente.
.
Pruebas de aceptación
Permiten determinar cual es el criterio de aceptación para el cliente.
.
Pruebas de UI
Permiten garantizar que el producto interactúa de la forma en que debería. Estas pruebas se pueden hacer por bloques, funcionalidad, end to end.
.
.
Todas estos tipos de pruebas pueden ser agrupados en 3 grupos

• Pruebas unitarias.
• Pruebas de API.
• Pruebas de UI.

gaaaaaaa

En mi caso, las pruebas de API me ahorrarían bastante tiempo, puesto que podría validar si los diferentes servicios están operando con normalidad.

Tipos de Pruebas - Automatización

Soy educador y realizo pruebas.

Nunca he trabajado como Desarrollador. Pero, puedo mencionar varias que usamos y que son muy similares.

Prueba de humo
Prueba de Regresión
Pruebas unitarias
Pruebas de aceptación

creo que las pruebas que me ahorrarían mas tiempo es la IU, porque si se automatizan, ya no gastaría el mismo tiempo que hacerlas manualmente.

Bueno acá se contradice, porque indica que las pruebas de UI, no se pueden automatizar.

Me ayudarian mucho la automatización de pruenas de Regresión, ya que es muy común en la integración de nuevos modulos o funcionalidades el desenfoque de los modulo anteriores al trabajar sistemas ERP

En mi caso lo que siempre profeso es que todo se puede automatizar y la gran limitante es la inversion de tiempo que dedicaras a automatizar esa caracteristica y si realmente esa inversion te va a retornar un valor significativo como para que haya valido la pena la inversion.

Excelente explicación el profe Javier, muchas gracias.

Esto me hace recordar a las pruebas de caja blanca, que se centran en la estructura interna, las pruebas de caja negra se centran en el comportamiento funcional, y las pruebas de caja gris son una combinación de las pruebas de caja blanca y negra,

La pruebas de Humo: Son de las mas importantes ya que se aplican cuando tenemos pasos de emergencia en producción , los cuales solucionan una falla y debemos garantizar que realmente la solucionen, y que no nos afecte las operaciones básicas de nuestro sistema.

Siento que las pruebas que mas ahorraria tiempo son las e2e, ya que podria englobar las unitarias y las de las api, la ventaja tambien seria que al momento de refactorizar porque no tenemos una buena arquitectura, podriamos ampararnos en estas para dividir de mejor manera la app y que en caso de que no tengamos pruebas unitarias poder aplicarlas y refactorizar a modo completo. Basicamente caí aquí por comentarios de Miguel Angel Duran y Alan Buscaglia para mejorar las aplicaciones que hago y mejorar la calidad me mi codigo

Para mi las pruebas que ahorran tiempo a un equipo de trabajo son las unitarias porque son la unidad mínima den la cadena de desarrollo del software

En mi empresa creo que ahorraríamos muchísimo tiempo al momento de entregar productos si comenzáramos a implementar pruebas de UI, en todos los sistemas que ofrece.

Pruebas funcionales y no funcionales Funcionales: Nos permiten analizar los requisitos comerciales (lo que el cliente va a ver, etc) No funcionales: Nos permiten probar las cosas que son necesarias para que el cliente vea y tenga una experiencia agradable. (Rendimiento, seguridad, alacenamiento de datos … etc) La automatización de pruebas nos permitirá automatizar ambos tipos de pruebas. Tipos de pruebas (funcionales y no funcionales) Pruebas unitarias, Pruebas de API, Pruebas de UI

Considero que las pruebas unitarias le ayudarían mucho al desarrollador, para que se enfoque en la solución y no en los posibles errores de sintaxis que puede generar.

La mejor manera para reducir el tiempo a la hora de elaborar las pruebas serian pruebas automatizadas donde no se presenten limitaciones y sean pruebas repetitivas e igualmente tener una suite de pruebas ayudaria a ejecutar de maneara más rapida las pruebas

Considero que todas la pruebas son importantes, aunque las pruebas unitarias siempre es importante tenerlas en consideración ya que son rápidas de implementar y lo puede realizar el mismo desarrollador.

Como desarrollador siempre diré que las Pruebas Unitarias de lejos son las mejores, son rápidas de hacer y van a la par cuando se crea el código y se va integrando poco a poco, además que permiten corregir problemas en ese mismo momento.

Los test de regresión para que se ejecuten automáticamente en cada incremento de producto, esto ahorraría mucho tiempo al equipo.

Buena tarde, las pruebas unitarias y de integración creo que son las que más beneficiaria a mi equipo de trabajo para ahorrar tiempo.

Pruebas de API : puedes automatizar pruebas a los endPoints de una API para garantizar que funciona como debe.

Las pruebas de integracion o las de e2e serían para mi las que ahorren mas tiempo, ya que se aseguran que la aplicacion como un todo esta funcionando

Pruebas de UI puede ser el mas lento pero también el mas beneficioso a la hora de trabajar.

Las pruebas unitarias, de regresion e integración y las end to end son las que me servirían

Personalmente las pruebas de regresion automatizadas me ahorrarian alrededor de 1 hora a la semana, ya que tengo que correrla manualmente antes de cada release

Donde me ahorraría mucho trabajo es en las pruebas de API y las pruebas de UI. Creo que me ayudaría a detectar bugs mucho más rápidamente que de forma manual

uff imagina el trabajos que nos podemos ahorrar en puebas de APi’s y pruebas de UI, sin duda automatizarlos nos ahorraria mucho mucho tiempo

Pruebas de regresión, para probar todo lo que se había probado anteriormente y que las nuevas funcionalidades no hayan introducido nuevos bugs

Pruebas de humo, generalmente se corres después de una liberación o compilación para asegurar que nada se haya prendido en llamas

Pruebas de Humo, probar bloques de prueba unitaria en conjunto