A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Automatizaci贸n de pruebas

27/29
Recursos

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 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.

Aportes 32

Preguntas 3

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

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.

鈥淓ntre 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 鈥渓iving鈥 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.