El documento describe las 10 competencias clave necesarias para implementar Behavior Driven Development (BDD) en un equipo ágil. Estas competencias incluyen: 1) Integrar las pruebas en el equipo de desarrollo, 2) Tener un buen control de versiones y entorno de pruebas, 3) Definir una buena estrategia de pruebas.
Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.
- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil
Presenta las diferentes entre Desarrollo Cascada versus Desarrollo Agile-Scrum, mostrando la manera en la que participa el Testing, más algunos de los procedimientos, prácticas y conceptos principales.
Para mayor información, visitar: http://testingbaires.com/
A continuación, parte del contenido de la presentación.
#Planteo formulado dentro de un grupo de discusión
Generalidades
¿Qué tipo de actividades llevas a cabo bajo este modelo?
¿Qué ceremonias: Daily Scrum Meetings, Sprint Reviews, Retrospectives?
¿Participan con el Product Owner en la User Story?
¿Qué tratamiento le dan al Product Backlog y Sprint Backlog?
¿Participan del Sprint Planning?
¿Tienen un Scrum Master que lo elabora?
¿Estiman el esfuerzo de trabajo?
¿Qué documentan?
¿Elaboran Indicadores y Métricas?
Herramientas
¿Usan herramientas aranceladas? JIRA Agile, JIRA Bamboo, JIRA Zephyt, TFS
¿Usan herramientas open source? Redmine, Testlink, Mantis, Selenium WebDriver, Cucumber, SonarQube
Automatización
¿Ejecutan Automation Testing?
¿Bajo qué tipo de modelo: BDD y/o ATDD, pej?
¿Ejecutan Testing contra Código?
¿Ejecutan Testing contra Servicios?
¿Ejecutan Testing contra Front End?
¿Estiman, documentan, elaboran Indicadores y Métricas?
Planteo por parte de un miembro
En mi trabajo es difícil aún introducir los procesos de Testing en Scrum.
Acá se practica la metodología estrictamente, los sprint son de dos semanas y la documentación es casi nula (no existen los casos de uso, y los documentos de requerimientos son escasos), el tiempo para crear casos de prueba es muy poco por lo que decidimos solo crear los de regresión y dedicar mas tiempo a los Criterios de Aceptación (Definition of Done). Utilizamos Jira pero no solo como bugtracker sino también como pizarra de Scrum donde se encuentran las Historias de Usuario (User Story) creadas entre todo el equipo de Scrum en el Sprint Planning. Por el momento las estimaciones de los desarrolladores para bugfixing nunca alcanzaron, y la verificación de bugs de un Sprint se realizan en el próximo. Para nuevos proyectos vamos a probar con Sprints de 3 semanas: 2 de desarrollo, 1 de Testing y bugfixing, así los desarrolladores podrían liberar funcionalidades mas completas (y testeables), estimar mejor el tiempo de testing (somos abiertos al testing exploratorio) y quedaría tiempo para realizar bugfixing. La verificación de bugs seguiría quedando para el próximo sprint.
Devolución ofrecida
No están siendo ágiles.
Si están realizando el testing fuera de la sprint, no están entregando un producto de calidad.
La idea es entregar un incremento TERMINADO: diseñado, desarrollado, probado.
Lamentablemente, así funcionan muchos equipos actualmente.
Es necesario incorporar el Testing dentro de las iteraciones.
SEMINARIO WEB EN VIVO: INTRODUCCIÓN AL AGILE TESTINGtbaires
En la actualidad, el concepto de Agilidad sigue evolucionando y con él las prácticas de desarrollo de software que adoptan como base un marco de trabajo ágil.
Durante el seminario se tratarán algunos conceptos básicos:
· ¿Por qué Testing Ágil?
· Los Principios Ágiles
· Esquema de Desarrollo Ágil
· Beneficios de las Prácticas Ágiles
· Los Valores del Testing Ágil
· Descripción del curso de Testing Ágil
Duración
1 hora
Fecha
27 de Julio de 2016
Horario
de 19 a 20 hs
Expositora:
Lic Miriam Alsogaray
https://ar.linkedin.com/in/miriam-alsogaray-2851348
Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.
- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil
Presenta las diferentes entre Desarrollo Cascada versus Desarrollo Agile-Scrum, mostrando la manera en la que participa el Testing, más algunos de los procedimientos, prácticas y conceptos principales.
Para mayor información, visitar: http://testingbaires.com/
A continuación, parte del contenido de la presentación.
#Planteo formulado dentro de un grupo de discusión
Generalidades
¿Qué tipo de actividades llevas a cabo bajo este modelo?
¿Qué ceremonias: Daily Scrum Meetings, Sprint Reviews, Retrospectives?
¿Participan con el Product Owner en la User Story?
¿Qué tratamiento le dan al Product Backlog y Sprint Backlog?
¿Participan del Sprint Planning?
¿Tienen un Scrum Master que lo elabora?
¿Estiman el esfuerzo de trabajo?
¿Qué documentan?
¿Elaboran Indicadores y Métricas?
Herramientas
¿Usan herramientas aranceladas? JIRA Agile, JIRA Bamboo, JIRA Zephyt, TFS
¿Usan herramientas open source? Redmine, Testlink, Mantis, Selenium WebDriver, Cucumber, SonarQube
Automatización
¿Ejecutan Automation Testing?
¿Bajo qué tipo de modelo: BDD y/o ATDD, pej?
¿Ejecutan Testing contra Código?
¿Ejecutan Testing contra Servicios?
¿Ejecutan Testing contra Front End?
¿Estiman, documentan, elaboran Indicadores y Métricas?
Planteo por parte de un miembro
En mi trabajo es difícil aún introducir los procesos de Testing en Scrum.
Acá se practica la metodología estrictamente, los sprint son de dos semanas y la documentación es casi nula (no existen los casos de uso, y los documentos de requerimientos son escasos), el tiempo para crear casos de prueba es muy poco por lo que decidimos solo crear los de regresión y dedicar mas tiempo a los Criterios de Aceptación (Definition of Done). Utilizamos Jira pero no solo como bugtracker sino también como pizarra de Scrum donde se encuentran las Historias de Usuario (User Story) creadas entre todo el equipo de Scrum en el Sprint Planning. Por el momento las estimaciones de los desarrolladores para bugfixing nunca alcanzaron, y la verificación de bugs de un Sprint se realizan en el próximo. Para nuevos proyectos vamos a probar con Sprints de 3 semanas: 2 de desarrollo, 1 de Testing y bugfixing, así los desarrolladores podrían liberar funcionalidades mas completas (y testeables), estimar mejor el tiempo de testing (somos abiertos al testing exploratorio) y quedaría tiempo para realizar bugfixing. La verificación de bugs seguiría quedando para el próximo sprint.
Devolución ofrecida
No están siendo ágiles.
Si están realizando el testing fuera de la sprint, no están entregando un producto de calidad.
La idea es entregar un incremento TERMINADO: diseñado, desarrollado, probado.
Lamentablemente, así funcionan muchos equipos actualmente.
Es necesario incorporar el Testing dentro de las iteraciones.
SEMINARIO WEB EN VIVO: INTRODUCCIÓN AL AGILE TESTINGtbaires
En la actualidad, el concepto de Agilidad sigue evolucionando y con él las prácticas de desarrollo de software que adoptan como base un marco de trabajo ágil.
Durante el seminario se tratarán algunos conceptos básicos:
· ¿Por qué Testing Ágil?
· Los Principios Ágiles
· Esquema de Desarrollo Ágil
· Beneficios de las Prácticas Ágiles
· Los Valores del Testing Ágil
· Descripción del curso de Testing Ágil
Duración
1 hora
Fecha
27 de Julio de 2016
Horario
de 19 a 20 hs
Expositora:
Lic Miriam Alsogaray
https://ar.linkedin.com/in/miriam-alsogaray-2851348
1º Caso Practico Lubricacion Rodamiento Motor 10CVCarlosAroeira1
Caso pratico análise analise de vibrações em rolamento de HVAC para resolver problema de lubrificação apresentado durante a 1ª reuniao do Vibration Institute em Lisboa em 24 de maio de 2024
libro conabilidad financiera, 5ta edicion.pdfMiriamAquino27
LIBRO DE CONTABILIDAD FINANCIERA, ESTE TE AYUDARA PARA EL AVANCE DE TU CARRERA EN LA CONTABILIDAD FINANCIERA.
SI ERES INGENIERO EN GESTION ESTE LIBRO TE AYUDARA A COMPRENDER MEJOR EL FUNCIONAMIENTO DE LA CONTABLIDAD FINANCIERA, EN AREAS ADMINISTRATIVAS ENLA CARREARA DE INGENERIA EN GESTION EMPRESARIAL, ESTE LIBRO FUE UTILIZADO PARA ALUMNOS DE SEGUNDO SEMESTRE
11. Título (una línea describiendo la historia)
Narrativa:
Como un [rol]
Yo quiero [característica]
Para [beneficio]
Criterio de aceptación (presentado como escenarios)
Escenario 1: Título
Dado [contexto]
Y [algo más del contexto]…
Cuando [evento]
Entonces [resultado]
Y [otro resultado]…
Escenario 2: …
…
Estructura de una historia BDD
35. Product Owner
y
cliente
tienen una conversación
sobre lo que se necesita
Tester,
desarrollador
y
Product Owner
elaboran los
requerimientos juntos
definidos como
“escenarios”
El escenario guía a los
desarrolladores
y actúa como prueba
automatizada
5. Las pruebas
automatizadas brindan
información y ayudan a
documentar la
aplicación para
todo el equipo
Testers
utilizan esos
escenarios para
realizar las
pruebas