Automatización de pruebas

OK con la teoria… ahora falta un curso 100% practico

A Platzi le falta la escuela de Testing donde podamos ver todos los niveles, metodologías y enfoques como el de Devops aplicados para Web UI, Api y Mobile etc

Nos urge la Escuela de Testing, Platzi.

¿Habrán ms cursos enfocados en este aspecto? Sería genial uno por cada uno de los aspectos mencionados: unitarios, integración, funcionales, tdd y bdd, entre otros que se me haya escapado

Que interesante el TDD nunca me había planteado escribir las pruebas antes del código.

Por fin, automatización de pruebas 😃

opino lo mismo que los demás, necesitamos un curso practico. para poder aplicar toda la teoría!

¿Que podemos automatizar?

• Pruebas unitarias

• Pruebas de integración

• Pruebas Funcionales o de Aceptación

Había escuchado que las pruebas de regresión también conviene automatizarlas, ya que solo queremos probar que los cambios hechos para corregir un defecto no impacten de manera negativa en otros partes del sistema.

Para ser honestos me gusto mucho el TDD pero no entendí muy bien el BDD

Muy buen curso! muy completo, bien detallado.

Pruebas unitarias
Tienen que ver con un pedazo de código que el desarrollador esta codificando, pero no tienen que ver con todo el flujo de negocio y proceso del software.
Pruebas de integración
Cómo hacemos que el conjunto del equipo que libera pedacitos de software funcionen juntos y no hagan defectos adicionales.
Pruebas funcionales o de aceptación
Estas pruebas no necesariamente forman parte de los requerimientos especificados por el cliente, una recomendación para automatizar estas pruebas es que deban cumplir con los requerimientos dados por el cliente.
Test Driven Development (TDD)
Es una tecnica de diseño e implementacion de software incluida dentro de la tetodologia XP (Extreme Programming).
Esta tecnica nos permite obtener una cobertura de prueba muy alta, aunque es importante destacar que este indice no indica que tengamos una calidad de test. Por lo tanto, no debe de ser un valor en el que fijarse unicamente
El desarrollo va a estar enfocado haciendo primera las pruebas y después el código. Haciendo que el desarollo sea muy específico con la mayor cobertura y no pongamos líneas de código que no van a funcionar o no se usan.
Escribimos una prueba
Ejecutamos la prueba: Falla
Se escribe el código
Ejecutamos la prueba: Pasa
Behavior Driven Development (BDD)
Es el desarrollo guiado por el comportamiento. Es un proceso que proviene de la evolucion del TDD.
En BDD tambien se escriben pruebas antes del codigo, pero en vez de ser pruebas unitarias son priebas que van a verificar que el comportamiento del codigo es correcto desde el punto de vista del negocio.
Si primeros vamos a escribir las pruebas, debemos hacerlo bien y usando un lenguaje sencillo, simple para que la sirva al equipo para entender qué es lo que queremos hacer.
Entre mas claros los casos de prueba, mas eficiente la cobertura de pruebas. Entre menos errores o ambiguedad tenga los casos de pruebas, son mas facil de ejecutar o automatizar.

Les recomiendo este libro para seguir aprendiendo Frontend Testing

Sobre este libro
Los tests automáticos no son nada nuevo en el mundo del software y aunque cada vez más desarrolladores están convencidos de su utilidad, pocos escriben tests en su día a día.

Las excusas son siempre las mismas: no sé hacer tests, no tengo tiempo, es algo que tengo pendiente…

Este libro pretende acabar con todas esas excusas y enseñar a los programadores a mejorar la calidad de su código explicando mediante ejemplos qué tipos de tests existen, qué características tienen y cuándo deben de utilizarse .

¿Cuándo estamos listos para automatizar?

• Tenemos pruebas repetitivas pero no están identificadas
• Buscamos optimizar la ejecución de pruebas pero solo escribimos scripts sin agrupar
• Hemos definido un framework pero no se estandarizan las pruebas

Podemos automatizar:

• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales o de aceptación

Test Driven Development: Es una técnica de diseño e implementación de software incluido dentro de la metodología XP (Extreme Programming).

Esta técnica nos permite obtener una cobertura de pruebas muy alta, aunque es importante destacar que este índice no indica que tengamos una buena calidad de test. Por lo tanto, no debe ser un valor en el que fijarse únicamente.

Proceso TDD:

1. Escribimos una prueba
2. Ejecutamos la prueba: Falla
3. Se escribe el código
4. Ejecutamos la prueba: Pasa

Behavior Driven Development: BDD es el desarrollo guiado por el comportamiento. Es un proceso que proviene de la evolución del TDD.

En BDD también se escriben pruebas antes del código, pero en vez de ser pruebas unitarias son pruebas que van a verificar que el comportamiento del código es correcto desde el punto de vista del negocio.

Entre más claros los casos de prueba, más eficiente la cobertura de pruebas. Entre menos errores o ambigüedad tengan los casos de pruebas, son más fácil de ejecutar o automatizar.

Consideren que antes de automatizar las pruebas, el software debe ser maduro y pasar por todo el testing manual, para que después se haga el checking repetitivo

AUTOMATIZACIÓN DE PRUEBAS

Cuando estamos listos para Automatizar? CUANDO SI / CUANDO NO

• Tenemos pruebas repetitivas / No cuando no estan identificadas.
• Buscamos optimizar la ejecución de pruebas / No cuando solo escribimos scripts sin agrupar
• Hemos definido un framework / No cuando no se estandarizan las pruebas.

Qué pruebas son las que podemos automatizar?

• Pruebas unitarias: Tienen que ver con un pedazo de código que el desarrollador esta codificando, pero no tienen que ver con todo el flujo de negocio y proceso del software.
• Pruebas de integración: Cómo hacemos que el conjunto del equipo que libera pedacitos de software funcionen juntos y no hagan defectos adicionales.
• Pruebas funcionales o de aceptación: Estas pruebas no necesariamente forman parte de los requerimientos especificados por el cliente, una recomendación para automatizar estas pruebas es que deban cumplir con los requerimientos dados por el cliente.

Test Driven Development: Es una técnica de diseño e implementación de software incluida dentro de la metodología XP (Extreme Programming). El desarrollo va a estar enfocado haciendo primera las pruebas y después el código. Haciendo que el desarollo sea muy específico con la mayor cobertura y no pongamos líneas de código que no van a funcionar o no se usan.

• Escribimos una prueba
• Ejecutamos la prueba: Falla
• Se escribe el código
• Ejecutamos la prueba: Pasa

Behavior Driven Development: Si primeros vamos a escribir las pruebas, debemos hacerlo bien y usando un lenguaje sencillo, simple para que la sirva al equipo para entender qué es lo que queremos hacer. BDD es el desarrollo guiado por el comportamiento.

“Entre más claros los casos de prueba, más eficiente la cobertura de pruebas.
Entre menos errores o ambigüedad tengan los casos de pruebas, son más fácil de ejecutar o automatizar.”

Es posible revisar la redacción de cada una de las descripciones de este curso, están mal redactadas… en su gran mayoría. Gracias!

Test plan components:

• Testing approach/strategy
• Scope
• Schedule
• Resources / Test Environment
• Entry and Exit Criteria
• Requirements Matrix )For Traceability)
• What is NOT Tested
• Test cases and scripts (separate documents)

Test Plan Activities:

• Use a test template or design one
• List what cannot be tested
• Write only what you need
• Have the test plan reviewed
• Make it a “living” document

No estaría mal un curso de programas de automatización en selenium

Me hubiera gustado otro diagrama de flujo en esta clase aunque reconozco que se entiende bien de bien.

¿Cuando estamos listos para automatizar?

Tenemos pruebas repetitivas -> pero no están identificadas
Buscamos optimizar las ejecución de pruebas -> Tenemos scripts sin agrupar
**Hemos definido un framework **-> Aún no hemos estandarizado.

Estandarización de los procesos

• Pruebas unitarias: Pedazo de código. No relacionado al negocio.
• Pruebas de integración: Cómo lograr que las piezas de software funcionen juntas.
• Pruebas funcionales o de aceptación: Prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software

Excelente curso.

Escuela de Testing por fa 😦

Otros cursos de testing en la plataforma para continuar hasta hoy:
Posible ruta

• INTRODUCCIÓN A LA AUTOMATIZACIÓN DE PRUEBAS
• END TO END TESTING CON CYPRESS
• INTRODUCIÓN A SELENIUM CON PYTHON
• INTRODUCCIÓN AL TESTING DE PRUEBAS CON JAVASCRIPT
• TESTING CON VUE.JS

Entre más claros los casos de prueba, más eficiente la cobertura de pruebas. Entre menos errores o ambiguedad tengan los casos de pruebas, son más fácil de ejecutar o automatizar

En esta unidad vamos a conocer las bases para la automatización de pruebas y podemos automatizar las siguientes tipos de pruebas.

Pruebas unitarias: Tienen que ver con un pedazo de código que el desarrollador esta codificando, pero no tienen que ver con todo el flujo de negocio y proceso del software.

Pruebas de integración: Cómo hacemos que el conjunto del equipo que libera pedacitos de software funcionen juntos y no hagan defectos adicionales.

Pruebas funcionales o de aceptación: Estas pruebas no necesariamente forman parte de los requerimientos especificados por el cliente, una recomendación para automatizar estas pruebas es que deban cumplir con los requerimientos dados por el cliente.

Test Driven Development:
El desarrollo va a estar enfocado haciendo primera las pruebas y después el código. Haciendo que el desarollo sea muy específico con la mayor cobertura y no pongamos líneas de código que no van a funcionar o no se usan.

Escribimos una prueba

Ejecutamos la prueba: Falla

Se escribe el código

Ejecutamos la prueba: Pasa

Behavior Driven Development:

Si primero vamos a escribir las pruebas, debemos hacerlo bien y usando un lenguaje sencillo, simple para que la sirva al equipo para entender qué es lo que queremos hacer.

Bases de la automatización de pruebas

• Tenemos pruebas repetitivas, pero no están identificadas
• Buscamos optimizar la ejecución de pruebas, solo escribimos scripts sin agrupar
• Hemos definido un framework, No se estandarizan las pruebas
  Pruebas unitarias: sirven para probar los módulos independientemente
  Pruebas de integración: prueban la integración de varios módulos
  Pruebas funcionales o de aceptación: se prueban los criterios de aceptación del cliente
  TDD (Test Driven Development)
  Es una técnica de diseño e implementación de software incluida dentro de la metodología XP (Extreme Programming).
  Esta técnica nos permite obtener una cobertura de pruebas muy alta, aunque es importante destacar que el índice no indica que tengamos una buena calidad de test. Por lo tanto, no debe ser un valor en el que fijarse únicamente.

1. Escribimos una prueba
2. Ejecutamos la prueba: Falla
3. Se escribe el código
4. Ejecutamos la prueba: Pasa

BDD (Behavior Driven Development)
es el desarrollo guiado por el comportamiento. Proviene de la evolución de TDD.
También se escriben pruebas antes del código, pero se verificara que el comportamiento sea correcto desde el punto de vista de negocio.
"Entre más claros los casos de prueba, más eficiente la cobertura de pruebas. Entre menos ambigüedades tengan los casos, más fácil de ejecutar o automatizar.

TDD
Test driven-development quiere decir que primero se empieza por saber cuales son las pruebas que se realizaran y de ahí se basa todo para que se desarrolle el sistema

Me parece que hay un curso de RPA (Robot Process Automation) donde se puede hacer este tipo de automatizaciones

Para Java es bien bonito el ecosistema (con el que estoy familiarizado yo):
Repositorio + Jenkins + Docker + SonarQube + Junit + Artifactory + Nexus
Obviamente maven también, por si algún purista.