jueves, 22 de marzo de 2012
Reparto de tareas
Fernando
Cussó
|
David
Agudo
|
Pablo
Delgado
|
Pablo
Niñoles
| |
Busqueda de informacion
|
x
|
x
|
x
|
x
|
Repartir tareas
|
x
|
x
|
x
|
x
|
Descripción herramienta
| x | |||
Prueba de la herramienta
| x | x | ||
Manual de usuario
| x |
x
| ||
Conclusión
| x |
x
| ||
Plantilla del documento
| x | |||
Aprobado final
| x | x | x |
x
|
miércoles, 21 de marzo de 2012
Scrumban
Scrumban
Como podemos ver en la siguiente tabla, Kanban presenta grandes diferencias respecto a Scrum:
Podemos usar las mejores prácticas ágiles de cada una. De esta forma tiene origen el Scrum-ban.
La esencia de Scrum-ban reside en llevar a cabo una secuencia de mejoras evolutivas, incorporando prácticas ágiles gradualmente. Por lo que los equipos pueden mejorar sus procesos de acuerdo a sus necesidades y capacidad.
Básicamente sigue el flujo de trabajo contínuo como lo define Kanban, pero se incluyen elementos de Scrum como, por ejemplo, las reuniones diarias de 15 minutos y pequeñas retrospectivas con el afán de mejorar el proceso. De esta manera Scrum-ban supone una vía para introducir a los equipos de desarrollo al mundo de las metodologías ágiles. Esto permite tener un periodo de transición, con el afán de que los desarrolladores y demás partes interesadas se sientan cómodos con la nueva metodología.
Puede servir, además, a las organizaciones donde ya se ha adoptado Scrum pueden conseguir una mejora de eficiencia gracias al sistema de flujo continuo propio de Kanban, limitando el número de trabajos en curso (WIP), cambios en el Sprint Backlog, etc. sin renunciar a sus técnicas habituales.
Básicamente un tablero Scrumban es una extensión del tablero Kanban (el cual sólo tiene las columnas To Do, Doing y Done) para usarlo como apoyo a la gestión de un sprint de Scrum. Sin entrar en debates respecto de las diferencias entre Scrum y Kanban , o los inconvenientes de mezclarlos, nos quedamos con la idea de sacar lo mejor de ambos. La idea Scrumban es utilizar, en el contexto de Scrum, una variante de tablero Kanban, específicamente para la visualización del trabajo, sin necesariamente seguir todas las reglas del método Kanban.
Así, en el contexto de Scrum, cada actividad realizada dentro del sprint podría ponerse como una columna cuyas sub-columnas corresponden a To Do, Doing y Done. Las columnas To Do o Done (una de ellas) puede no utilizarse pues la idea es representar un encadenamiento de actividades, es decir, el Done de la actividad previa puede interpretarse como el To Do de la actividad siguiente. Como en todo Kanban de pared, los post-it que representan a los ítems de trabajo fluyen de izquierda a derecha hasta alcanzar el estado Done de la última actividad. Las actividades incluidas en el Scrumban dependen del interés del equipo por tener un seguimiento y visualización de mayor o menor detalle respecto de cada ítem en el sprint.
Un tablero de pared para apoyar Scrumban y usando post-it es un excelente medio para ilustrar y aprender la mecánica de trabajo durante un sprint. Además, para el equipo que se inicia en Scrum es un mecanismo muy socializador e incluso entretenido. En internet abundan ejemplos de Scrumban manuales y asociado a su utilización en desarrollo de productos industriales se transmite triunfalismo en cuanto a los resultados conseguidos con esta técnica. A continuación expongo mis razones para ser escéptico en cuanto a dicho triunfalismo, llegando a la conclusión que para hacer efectiva la técnica Scrumban ésta debe estar soportada por una herramienta software.
Video
Enlaces
Preguntas
1. Scrumban es el resultado de la fusión entre:
a) Scrum y Bankan
b) Scrum y Kanban
c) Scrum y Crystal Clear
d) Ninguna de las anteriores
2. Scrumban es ideal para hacer...
a) Proyectos complejos.
b) Proyectos de mantenimiento
c) Proyectos nuevos a corto plazo.
d) Ninguna de las anteriores.
3. Scrumban...
a) Básicamente sigue el flujo de trabajo contínuo como lo define Scrum, pero se incluyen elementos de Kanban
b) Está alejado del mundo de las metodologías ágiles
c) Básicamente sigue el flujo de trabajo contínuo como lo define Kanban, pero se incluyen elementos de Surca
d) Es una actualización del metodo Kanban
4. Un tablero Scrumban:
a) Es una extensión del tablero Srum
b) Es un tablero própio que no está basado en ningún otro
c) Ninguna de las respuestas es correcta
d) Es una extensión del tablero Kanban
5. La idea Scrumban es:
a) Es utilizar, en el contexto de Kanban, una variante de tablero Scrum
b) Visualización del trabajo, sin necesariamente seguir todas las reglas del método Kanban.
c) Visualización del trabajo, siguiendo todas las reglas del método Kanban
d) Visualización del trabajo, siguiendo todas las reglas del método Scum
6. Los post-it que representan los items de trabajo fluyen:
a) De izquierda a derecha
b) De arriba a abajo
c) De derecha a izquierda hasta alcanzar el estado Done
d) No fluyen son estaticos, una vez finalizado el item se tira el post-it a la papelera
7. Indica cúal es cierta
a) El tiempo por iteración en Scrum es fijo
b) El tiempo por iteración en Scrum es variable
c) El tiempo por iteración en Scrum es opcional
d) El tamaño de equipo en Scrum es mínimo 10 personas (aprox)
8. En el Scrumban incorpora..
a) Muchas desventajas frente a Kamban
b) Muchas desventajas frente a Scrum
c) Un sistema de flujo continuo propio de Scrum, ilimitando el número de trabajos en curso (WIP)
d) Un sistema de flujo continuo propio de Kanban, limitando el número de trabajos en curso (WIP)
lunes, 19 de marzo de 2012
Lectura recomendada: “Las pruebas en metodologías ágiles y convencionales: papeles diferentes”
Introducción
El término “Prueba” se ha utilizado a lo largo de los años como referencia a diferentes conceptos: haciendo mención a técnicas para realizar pruebas (pruebas de caja blanca y de caja negra) o dando nombre a diferentes estrategias y objetivos en la forma de aplicar las pruebas (unitarias, integración, aceptación o sistema) o presentando diferentes enfoques en la realización de las pruebas (TDD ,ATDD,STDD) o, finalmente, para dar soporte a nuevas metodologías relacionadas con los proyectos de pruebas como TMAP.
Las pruebas tienen objetivos diferentes: en las metodologías convencionales se utilizan como validación del producto desarrollado, mientras que en las metodologías ágiles se utilizan en sustitución de las especificaciones de requisitos y como guía para el desarrollo de software. Por lo tanto, se puede afirmar que las pruebas del software están evolucionando para desempeñar nuevos papeles en el desarrollo de software y sistemas. Este nuevo papel de las pruebas, como sustitución de los requisitos convencionales, es importante para subsanar algunos problemas que tienen las metodologías ágiles en relación con la identificación de requisitos.
Técnicas básicas de pruebas
Se han considerado dos categorías: caja blanca y caja negra.
Por un lado, las técnicas de caja blanca (caminos básicos, control de flujo, control de datos o pruebas de ramificación) están basadas en código fuente y se utilizan, principalmente, desde una perspectiva interna en el desarrollo de software. Como están basadas en el estado actual del código fuente, si se realizan cambios en la implementación, en la mayoría de los casos, también habrá que realizar cambios en los casos de pruebas. Esto requiere una alta cualificación en el equipo de desarrollo, tanto para la identificación de los casos de pruebas como para su implementación. Incluso, aunque las pruebas de caja blanca se pueden aplicar en diferentes estrategias de pruebas (unitarias, integración y sistema) fundamentalmente se aplican en el ámbito de las pruebas unitarias. En la actualidad herramientas como Clover o Cobertura permiten conocer la cobertura de código de las pruebas diseñadas.
En oposición a las pruebas de caja blanca, las pruebas de caja negra (particiones de equivalencia, análisis de valores límite, pruebas transversales, etc.) tienen una visión externa del producto software y no están centradas en el código fuente. Los casos de prueba se basan en las diferentes entradas que puede recibir el software y sus correspondientes valores de salida. Por lo tanto, están centradas en realizar pruebas del software a través de la funcionalidad. Estas técnicas se pueden aplicar a cualquiera de los niveles de pruebas (unitarias, integración, aceptación).
Fundamentalmente, en las metodologías convencionales las pruebas de caja negra las llevan a cabo los probadores. Sin embargo, en las metodologías ágiles se presentan dos perspectivas: por un lado los desarrolladores, que conocen los tipos de datos de cada uno de los parámetros, ejecutan las pruebas de caja negra a nivel de pruebas unitarias. Por otro lado, los del resto del equipo, que aunque no están directamente involucrados en el desarrollo, también participan en el diseño y ejecución de las pruebas. Aunque estos aspectos dependen claramente de los equipos de trabajo.
Dado que las técnicas básicas están directamente relacionadas con la cualificación de las personas que llevan a cabo el desarrollo y de las herramientas disponibles para el diseño de casos de prueba, no se puede considerar que las técnicas básicas tengan un papel diferente en las metodologías convencionales y en ágiles. En ambas metodologías, es muy importante la existencia de herramientas que, de forma automática, tomen medidas sobre la calidad del código o sobre el grado de cobertura que alcanzan los test diseñados.
Las pruebas en los enfoques convencionales
Cuando se habla de las pruebas en los enfoques convencionales, fundamentalmente se identifican cuatro actividades relacionadas: pruebas unitarias, pruebas de integración, pruebas de aceptación y pruebas de sistema. En estas metodologías se presta especial atención a la elaboración de la especificación de requisitos software. Dicha especificación se refina dentro del proceso de identificación de los requisitos del software mediante iteraciones. En este enfoque, el proceso de desarrollo se dirige desde la especificación de requisitos hacia el código y posteriormente desde el código hasta las pruebas.
En consecuencia, aunque en las metodologías convencionales las pruebas son importantes, éstas dependen directamente del resto de actividades del proceso de desarrollo. Y por lo tanto, en estos casos, el proceso de validación se entiende como un complemento del proceso de desarrollo.
El enfoque de las pruebas en las metodologías convencionales se basa en la definición de los casos de prueba correspondientes a las estrategias de prueba que se van a aplicar y su representación mediante los lenguajes adecuados del nivel en el que se realicen. Por ejemplo, en el caso del desarrollo de una aplicación utilizando el lenguaje Java, las pruebas unitarias y de integración se podrían realizar utilizando jUnit, y las pruebas de aceptación y de sistema utilizando, por ejemplo FIT.
Las pruebas en las metodologías ágiles
Ágile en general, y una particularmente Extreme Programming (XP), son de alguna manera los responsables del aumento de popularidad de las pruebas del software. En XP las necesidades de los usuarios se representan mediante “historias de usuario” que representan los requisitos del sistema. Cada historia de usuario lleva asociada criterios de aceptación y para cada criterio de aceptación se definen casos de prueba. Las pruebas de aceptación se escriben en las fases tempranas del desarrollo, y antes de que el sistema se implemente, para validar las necesidades de los usuarios y para dirigir la implementación. Se puede considerar que las historias de usuario y, por extensión, las pruebas asociadas juegan el papel de especificaciones del sistema.
En los enfoques ágiles las pruebas son el centro de la metodología y, por lo tanto son ellas las dirigen el proceso de desarrollo.
Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más, sino que abogan porque las prácticas y el desarrollo estén completamente integradas, lo que puede llevar a modificar las estructuras organizativas de las empresas. Las metodologías ágiles no consideran las pruebas como un conjunto de niveles que hay que ir superando para alcanzar la validación final del sistema que se está desarrollando. Las metodologías ágiles presentan distintos enfoques del proceso de desarrollo que vienen determinados por los tipos de pruebas que se realizan.
Conclusión
Las pruebas desempeñan un papel importante en los diferentes modelos de procesos que van desde los modelos convencionales a los ágiles. Mientras en las metodologías convencionales, las pruebas no se ejecutarán hasta que el código esté terminado, aunque puedan diseñarse antes de la codificación, en las ágiles las pruebas se escriben antes comenzar la codificación y sólo se escribe el código necesario para superar las pruebas y guían el proceso de desarrollo. El hecho de que las pruebas se hacen tan pronto como es posible, está alineado con la reducción del impacto del coste de la detección de errores en las fases de pruebas.
Con respecto a las actividades de diseño de las pruebas, éstas son de alguna forma distintas en las metodologías ágiles y convencionales. Las últimas tendencias dan más relevancia a las pruebas unitarias y de aceptación. En las metodologías ágiles, no se distinguen de forma específica las pruebas de integración sino que éstas se incorporan en las pruebas que se definen ya sea en la aplicación de TDD o de ATDD. Para lograr la integración en cada una de las iteraciones, se aplican entornos de integración continua. Estos entornos además permiten la realización automatizada de las pruebas de regresión del sistema desarrollado.
Desde el punto de vista de las técnicas básicas de pruebas, ambas metodologías aplican las mismas técnicas básicas de pruebas: caja blanca y caja negra. Aunque los actores y el papel que desempeñan las técnicas de pruebas son algo diferentes; aunque las prácticas puedan parecer semejantes a nivel práctico, no lo son a nivel semántico.
Finalmente, este papel cambiante de las pruebas también tiene una fuerte implicación en la definición general del proceso de desarrollo y que debe ser tenido en cuenta por los estándares de desarrollo.
Preguntas
1. ¿Cual de las siguientes afirmaciones sobre las pruebas es cierta?
a) En las metodologías convencionales se utilizan como validación del producto desarrollado
b) En las metodologías ágiles se utilizan como sustitución de las especificaciones de requisitos y como guia para el desarrollo de software.
c) El papel de las pruebas, como sustitución de los requisitos convencionales, es importante para subsanar algunos problemas que tienen las metodologías ágiles
d) Todas las respuestas son ciertas
2. Indica la afirmación correcta:
a) Las técnicas de caja negra se utilizan principalmente desde una perspectiva interna del desarrollo software
b) Las técnicas de caja blanca están basadas en código fuente
c) Las técnicas de caja negra están basadas en código fuente
d) Todas las afirmaciones son correctas
3. Fundamentalmente, en las metodologías convencionales las pruebas de caja negra las llevan a cabo los....
a) ninguna de las respuestas es correcta
b) los clientes
c) desarrolladores
d) probadores
4. Indica cual no es correcta
a) En las metodologias de caja blanca y negra es importante la automatización mediante herramientas de medidas de calidad del código o la cobertura que alcanzan los test
b) En los enfoques convencionales, se identifican cuatro actividades relacionadas: pruebas unitarias, pruebas de integración, pruebas de aceptación y pruebas de sistema.
c) En las técnicas de caja blanca se requiere una alta cualificación en el equipo de desarrollo
d) En oposición a las pruebas de caja blanca, las pruebas de caja negra están centradas en el código fuente.
5. En las metodologías convencionales las pruebas dependen del resto de actividades del proceso de desarrollo
a) Si
b) Depende el caso
c) No siempre
d) No
6. En las metodologías ágiles para lograr la integración en cada una de las iteraciones, se aplican:
a) entornos de integración fase a fase
b) entornos de integración continua
c) entornos de integración discontinua
d) entornos de integración discontinua y además permiten las realización automatizada de las pruebas de regresión del sistema desarrollado
7. Indica cual es correcta
a) Las pruebas de caja negra tienen una visión externa del producto software
b) Las pruebas de caja blanca tienen una visión externa del producto software
c) Las pruebas de caja negra están centradas en el código fuente
d) Las actividades de diseño de las pruebas son igueles en metodologías ágiles y convencionales
8. Cuan de las siguientes no es correcta
a) Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más
b) Las metodologías ágiles consideran las pruebas como un conjunto de niveles que hay que ir superando para alcanzar la validación final del sistema que se está desarrollando
c) Las metodologías ágiles abogan porque las prácticas y el desarrollo estén completamente integradas
d) Las metodologías ágiles presentan distintos enfoques del proceso de desarrollo que vienen determinados por los tipos de pruebas que se realizan
El término “Prueba” se ha utilizado a lo largo de los años como referencia a diferentes conceptos: haciendo mención a técnicas para realizar pruebas (pruebas de caja blanca y de caja negra) o dando nombre a diferentes estrategias y objetivos en la forma de aplicar las pruebas (unitarias, integración, aceptación o sistema) o presentando diferentes enfoques en la realización de las pruebas (TDD ,ATDD,STDD) o, finalmente, para dar soporte a nuevas metodologías relacionadas con los proyectos de pruebas como TMAP.
Las pruebas tienen objetivos diferentes: en las metodologías convencionales se utilizan como validación del producto desarrollado, mientras que en las metodologías ágiles se utilizan en sustitución de las especificaciones de requisitos y como guía para el desarrollo de software. Por lo tanto, se puede afirmar que las pruebas del software están evolucionando para desempeñar nuevos papeles en el desarrollo de software y sistemas. Este nuevo papel de las pruebas, como sustitución de los requisitos convencionales, es importante para subsanar algunos problemas que tienen las metodologías ágiles en relación con la identificación de requisitos.
Técnicas básicas de pruebas
Se han considerado dos categorías: caja blanca y caja negra.
Por un lado, las técnicas de caja blanca (caminos básicos, control de flujo, control de datos o pruebas de ramificación) están basadas en código fuente y se utilizan, principalmente, desde una perspectiva interna en el desarrollo de software. Como están basadas en el estado actual del código fuente, si se realizan cambios en la implementación, en la mayoría de los casos, también habrá que realizar cambios en los casos de pruebas. Esto requiere una alta cualificación en el equipo de desarrollo, tanto para la identificación de los casos de pruebas como para su implementación. Incluso, aunque las pruebas de caja blanca se pueden aplicar en diferentes estrategias de pruebas (unitarias, integración y sistema) fundamentalmente se aplican en el ámbito de las pruebas unitarias. En la actualidad herramientas como Clover o Cobertura permiten conocer la cobertura de código de las pruebas diseñadas.
En oposición a las pruebas de caja blanca, las pruebas de caja negra (particiones de equivalencia, análisis de valores límite, pruebas transversales, etc.) tienen una visión externa del producto software y no están centradas en el código fuente. Los casos de prueba se basan en las diferentes entradas que puede recibir el software y sus correspondientes valores de salida. Por lo tanto, están centradas en realizar pruebas del software a través de la funcionalidad. Estas técnicas se pueden aplicar a cualquiera de los niveles de pruebas (unitarias, integración, aceptación).
Fundamentalmente, en las metodologías convencionales las pruebas de caja negra las llevan a cabo los probadores. Sin embargo, en las metodologías ágiles se presentan dos perspectivas: por un lado los desarrolladores, que conocen los tipos de datos de cada uno de los parámetros, ejecutan las pruebas de caja negra a nivel de pruebas unitarias. Por otro lado, los del resto del equipo, que aunque no están directamente involucrados en el desarrollo, también participan en el diseño y ejecución de las pruebas. Aunque estos aspectos dependen claramente de los equipos de trabajo.
Dado que las técnicas básicas están directamente relacionadas con la cualificación de las personas que llevan a cabo el desarrollo y de las herramientas disponibles para el diseño de casos de prueba, no se puede considerar que las técnicas básicas tengan un papel diferente en las metodologías convencionales y en ágiles. En ambas metodologías, es muy importante la existencia de herramientas que, de forma automática, tomen medidas sobre la calidad del código o sobre el grado de cobertura que alcanzan los test diseñados.
Las pruebas en los enfoques convencionales
Cuando se habla de las pruebas en los enfoques convencionales, fundamentalmente se identifican cuatro actividades relacionadas: pruebas unitarias, pruebas de integración, pruebas de aceptación y pruebas de sistema. En estas metodologías se presta especial atención a la elaboración de la especificación de requisitos software. Dicha especificación se refina dentro del proceso de identificación de los requisitos del software mediante iteraciones. En este enfoque, el proceso de desarrollo se dirige desde la especificación de requisitos hacia el código y posteriormente desde el código hasta las pruebas.
En consecuencia, aunque en las metodologías convencionales las pruebas son importantes, éstas dependen directamente del resto de actividades del proceso de desarrollo. Y por lo tanto, en estos casos, el proceso de validación se entiende como un complemento del proceso de desarrollo.
El enfoque de las pruebas en las metodologías convencionales se basa en la definición de los casos de prueba correspondientes a las estrategias de prueba que se van a aplicar y su representación mediante los lenguajes adecuados del nivel en el que se realicen. Por ejemplo, en el caso del desarrollo de una aplicación utilizando el lenguaje Java, las pruebas unitarias y de integración se podrían realizar utilizando jUnit, y las pruebas de aceptación y de sistema utilizando, por ejemplo FIT.
Las pruebas en las metodologías ágiles
Ágile en general, y una particularmente Extreme Programming (XP), son de alguna manera los responsables del aumento de popularidad de las pruebas del software. En XP las necesidades de los usuarios se representan mediante “historias de usuario” que representan los requisitos del sistema. Cada historia de usuario lleva asociada criterios de aceptación y para cada criterio de aceptación se definen casos de prueba. Las pruebas de aceptación se escriben en las fases tempranas del desarrollo, y antes de que el sistema se implemente, para validar las necesidades de los usuarios y para dirigir la implementación. Se puede considerar que las historias de usuario y, por extensión, las pruebas asociadas juegan el papel de especificaciones del sistema.
En los enfoques ágiles las pruebas son el centro de la metodología y, por lo tanto son ellas las dirigen el proceso de desarrollo.
Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más, sino que abogan porque las prácticas y el desarrollo estén completamente integradas, lo que puede llevar a modificar las estructuras organizativas de las empresas. Las metodologías ágiles no consideran las pruebas como un conjunto de niveles que hay que ir superando para alcanzar la validación final del sistema que se está desarrollando. Las metodologías ágiles presentan distintos enfoques del proceso de desarrollo que vienen determinados por los tipos de pruebas que se realizan.
Conclusión
Las pruebas desempeñan un papel importante en los diferentes modelos de procesos que van desde los modelos convencionales a los ágiles. Mientras en las metodologías convencionales, las pruebas no se ejecutarán hasta que el código esté terminado, aunque puedan diseñarse antes de la codificación, en las ágiles las pruebas se escriben antes comenzar la codificación y sólo se escribe el código necesario para superar las pruebas y guían el proceso de desarrollo. El hecho de que las pruebas se hacen tan pronto como es posible, está alineado con la reducción del impacto del coste de la detección de errores en las fases de pruebas.
Con respecto a las actividades de diseño de las pruebas, éstas son de alguna forma distintas en las metodologías ágiles y convencionales. Las últimas tendencias dan más relevancia a las pruebas unitarias y de aceptación. En las metodologías ágiles, no se distinguen de forma específica las pruebas de integración sino que éstas se incorporan en las pruebas que se definen ya sea en la aplicación de TDD o de ATDD. Para lograr la integración en cada una de las iteraciones, se aplican entornos de integración continua. Estos entornos además permiten la realización automatizada de las pruebas de regresión del sistema desarrollado.
Desde el punto de vista de las técnicas básicas de pruebas, ambas metodologías aplican las mismas técnicas básicas de pruebas: caja blanca y caja negra. Aunque los actores y el papel que desempeñan las técnicas de pruebas son algo diferentes; aunque las prácticas puedan parecer semejantes a nivel práctico, no lo son a nivel semántico.
Finalmente, este papel cambiante de las pruebas también tiene una fuerte implicación en la definición general del proceso de desarrollo y que debe ser tenido en cuenta por los estándares de desarrollo.
Preguntas
1. ¿Cual de las siguientes afirmaciones sobre las pruebas es cierta?
a) En las metodologías convencionales se utilizan como validación del producto desarrollado
b) En las metodologías ágiles se utilizan como sustitución de las especificaciones de requisitos y como guia para el desarrollo de software.
c) El papel de las pruebas, como sustitución de los requisitos convencionales, es importante para subsanar algunos problemas que tienen las metodologías ágiles
d) Todas las respuestas son ciertas
2. Indica la afirmación correcta:
a) Las técnicas de caja negra se utilizan principalmente desde una perspectiva interna del desarrollo software
b) Las técnicas de caja blanca están basadas en código fuente
c) Las técnicas de caja negra están basadas en código fuente
d) Todas las afirmaciones son correctas
3. Fundamentalmente, en las metodologías convencionales las pruebas de caja negra las llevan a cabo los....
a) ninguna de las respuestas es correcta
b) los clientes
c) desarrolladores
d) probadores
4. Indica cual no es correcta
a) En las metodologias de caja blanca y negra es importante la automatización mediante herramientas de medidas de calidad del código o la cobertura que alcanzan los test
b) En los enfoques convencionales, se identifican cuatro actividades relacionadas: pruebas unitarias, pruebas de integración, pruebas de aceptación y pruebas de sistema.
c) En las técnicas de caja blanca se requiere una alta cualificación en el equipo de desarrollo
d) En oposición a las pruebas de caja blanca, las pruebas de caja negra están centradas en el código fuente.
a) Si
b) Depende el caso
c) No siempre
d) No
6. En las metodologías ágiles para lograr la integración en cada una de las iteraciones, se aplican:
a) entornos de integración fase a fase
b) entornos de integración continua
c) entornos de integración discontinua
d) entornos de integración discontinua y además permiten las realización automatizada de las pruebas de regresión del sistema desarrollado
7. Indica cual es correcta
a) Las pruebas de caja negra tienen una visión externa del producto software
b) Las pruebas de caja blanca tienen una visión externa del producto software
c) Las pruebas de caja negra están centradas en el código fuente
d) Las actividades de diseño de las pruebas son igueles en metodologías ágiles y convencionales
8. Cuan de las siguientes no es correcta
a) Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más
b) Las metodologías ágiles consideran las pruebas como un conjunto de niveles que hay que ir superando para alcanzar la validación final del sistema que se está desarrollando
c) Las metodologías ágiles abogan porque las prácticas y el desarrollo estén completamente integradas
d) Las metodologías ágiles presentan distintos enfoques del proceso de desarrollo que vienen determinados por los tipos de pruebas que se realizan
lunes, 12 de marzo de 2012
Acepptance Test Driven Development (ATDD)
ATDD
Introducción: ¿Qué es ATDD?.
Acepptance Test Driven Development o Pruebas de aceptación del software o desarrollo, son un conjunto de pruebas funcionales basadas en metodologías ágiles que se realizan sobre el sistema completo, todos los programas tienen errores y la ATDD los descubre.
El objetivo principal de estas pruebas es encontrar el mayor numero de errores y defectos.
Se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase correctamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio y robusto que funcione. La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.
Estas pruebas no se realizan durante el desarrollo, sino que se realizan sobre el producto terminado e integrado o sobre una versión del producto o una iteración funcional pactada previamente con el cliente.
La experiencia muestra que aún después del más cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que sólo aparecen cuando el cliente comienza a usarlo.
Una prueba de aceptación puede ir desde un informal caso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas. De hecho, las pruebas de aceptación pueden tener lugar a lo largo de semanas o meses, descubriendo así errores escondidos que pueden ir degradando el funcionamiento del sistema.
Pruebas de Aceptación.
Se emplean dos técnicas para las pruebas de aceptación:
1. La prueba alfa:
Se lleva a cabo por un cliente en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador. Para que tengan validez, se debe primero crear un ambiente con las mismas condiciones que se encontrarán en las instalaciones del cliente. Una vez logrado esto, se procede a realizar las pruebas y a documentar los resultados.
2. La prueba beta:
Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no esta presente normalmente. Así, la prueba beta es una aplicación "en vivo" del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa al desarrollador.
Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y así prepara una versión del producto de software.
Descripción del proceso.
a) Cumplir los objetivos del cliente en el menor tiempo posible.
Introducción: ¿Qué es ATDD?.
Acepptance Test Driven Development o Pruebas de aceptación del software o desarrollo, son un conjunto de pruebas funcionales basadas en metodologías ágiles que se realizan sobre el sistema completo, todos los programas tienen errores y la ATDD los descubre.
El objetivo principal de estas pruebas es encontrar el mayor numero de errores y defectos.
Se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase correctamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio y robusto que funcione. La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.
Estas pruebas no se realizan durante el desarrollo, sino que se realizan sobre el producto terminado e integrado o sobre una versión del producto o una iteración funcional pactada previamente con el cliente.
La experiencia muestra que aún después del más cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que sólo aparecen cuando el cliente comienza a usarlo.
Una prueba de aceptación puede ir desde un informal caso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas. De hecho, las pruebas de aceptación pueden tener lugar a lo largo de semanas o meses, descubriendo así errores escondidos que pueden ir degradando el funcionamiento del sistema.
Pruebas de Aceptación.
Se emplean dos técnicas para las pruebas de aceptación:
1. La prueba alfa:
Se lleva a cabo por un cliente en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador. Para que tengan validez, se debe primero crear un ambiente con las mismas condiciones que se encontrarán en las instalaciones del cliente. Una vez logrado esto, se procede a realizar las pruebas y a documentar los resultados.
2. La prueba beta:
Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no esta presente normalmente. Así, la prueba beta es una aplicación "en vivo" del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa al desarrollador.
Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y así prepara una versión del producto de software.
Descripción del proceso.
Las pruebas de aceptación tienen como fin validar que el sistema cumple los requisitos básicos de funcionamiento esperado y permitir que el usuario determine la aceptación del sistema. Por este motivo, estas pruebas son realizadas por el usuario final que, durante este periodo de tiempo, debe plantear todas las deficiencias o errores que encuentre antes de dar por aprobado el sistema definitivamente.
Los directores de los usuarios revisan los criterios de aceptación, especificados previamente en el plan de pruebas del sistema, y dirigen las pruebas de aceptación final que llevan a cabo los usuarios expertos. A su vez, éstos últimos deben elaborar un informe que los directores analizan y evalúan para determinar la aceptación o rechazo del sistema.
Se analizan los criterios de aceptación establecidos por el usuario y recogidos en las verificaciones del plan de pruebas, por si fuera necesario incorporar algún caso de prueba adicional, y se comunica el plan de pruebas de aceptación una vez actualizado a los usuarios implicados.
Después se llevan a cabo las pruebas de aceptación final del sistema para asegurar que todos los componentes responden a los criterios de aceptación especificados.
Si es un software complejo y esta compuesto por varios módulos que se unen al final para lograr el producto, se probaran primero por separado y luego se diseñara un caso de prueba de integración para probar el software como un todo, el equipo de desarrollo deberá entregar con el expediente del producto un documento donde exponga como los datos manejados de un modulo afectan a otros. En caso de productos menos complejos esto no es necesario.
Se registra la realización de las pruebas, incluyendo un informe que recoja la desviación de los requisitos establecidos y los problemas que quedan sin resolver, para que mediante retroalimentación se puedan subsanar.
Por último se evalúan los resultados de las pruebas, analizando las incidencias recibidas y comprobando que se han llevado a cabo todos los casos de pruebas establecidos en el plan de pruebas. Dicha evaluación consiste en:
- Comparar los resultados obtenidos con los esperados.
- Identificar el origen de cada problema y determinar qué acciones o medidas correctoras es preciso llevar a cabo para resolverlo de forma satisfactoria.
- Indicar qué pruebas se debe volver a realizar, o si será necesario contemplar nuevos casos de prueba.
Una vez realizadas las medidas correctoras necesarias, y comprobado que su comportamiento es adecuado, se documenta el resultado global de la evaluación de las pruebas de aceptación que incluye la aprobación del sistema por parte del usuario final.
Preguntas
1. ¿Qué dos nombres adoptan las técnicas de pruebas de aceptación?
a) Alfa y Beta
b) Cliente y final
c) Depuración y refactorización
d) Beta y gamma
a) Alfa y Beta
b) Cliente y final
c) Depuración y refactorización
d) Beta y gamma
2. ¿Cual es el objetivo principal de ATTD?
a) Cumplir los objetivos del cliente en el menor tiempo posible.
b) Desarrollar un producto se calidad basándose en un documento como referente.
c) El objetivo principal de estas pruebas es desarrollar un producto iterativamente y que el cliente lo pruebe en su lugar de trabajo indicando se está conorme o no.
d) El objetivo principal de estas pruebas es encontrar el mayor numero de errores y defectos.
c) El objetivo principal de estas pruebas es desarrollar un producto iterativamente y que el cliente lo pruebe en su lugar de trabajo indicando se está conorme o no.
d) El objetivo principal de estas pruebas es encontrar el mayor numero de errores y defectos.
3. Cual de las siguientes afirmaciones es cierta:
a) El desarrollador está presente como observador en las pruebas alfa.
b) El desarrollador está presente como observador en las pruebas beta.
c) El desarrollador está presente como observador en las pruebas alfa y beta.
a) El desarrollador está presente como observador en las pruebas alfa.
b) El desarrollador está presente como observador en las pruebas beta.
c) El desarrollador está presente como observador en las pruebas alfa y beta.
d) Ninguna de las anteriores es correcta.
4. Las pruebas de aceptación NO se realizan:
a) Con el producto terminado.
b) Durante el desarrollo.
b) Durante el desarrollo.
c) En una iteración funcional pactada previamente con el cliente
d) Ninguna de las anteriores es correcta.
5. Si tenemos un software complejo que está compuesto por varios módulos...
a) no se probarán por separado, habrá que esperar a que todos los módulos estén terminados y unidos como un todo.
b) se probaran primero por separado y luego se diseñara un caso de prueba de integración para probar el software como un todo.
a) no se probarán por separado, habrá que esperar a que todos los módulos estén terminados y unidos como un todo.
b) se probaran primero por separado y luego se diseñara un caso de prueba de integración para probar el software como un todo.
c) es indiferente si lo probamos por separado o si esperamos a que estén unidos
como un todo.
como un todo.
d) Ninguna de las anteriores es correcta.
6. Las pruebas de aceptación son desarrolladas por:
a) el cliente.
b) el desarrollador.
c) los dos anteriores.
d) ninguno de los anteriores.
7. La evaluación de los resultados de las pruebas consiste en:
a) Comparar los resultados obtenidos con los esperados.
b) Identificar el origen de cada problema y determinar qué acciones o medidas correctoras es preciso llevar a cabo para resolverlo de forma satisfactoria.
c) Indicar qué pruebas se debe volver a realizar, o si será necesario contemplar nuevos casos de prueba.
d) Todas las anteriores son ciertas.
a) Comparar los resultados obtenidos con los esperados.
b) Identificar el origen de cada problema y determinar qué acciones o medidas correctoras es preciso llevar a cabo para resolverlo de forma satisfactoria.
c) Indicar qué pruebas se debe volver a realizar, o si será necesario contemplar nuevos casos de prueba.
d) Todas las anteriores son ciertas.
8. ¿Qué es ATDD?
a) Una metodología ágil.
b) Pruebas de aceptación del hardware.
c) Pruebas de aceptación del software
d) Es una metodología ágil basada en las pruebas de aceptación del software.
Suscribirse a:
Entradas (Atom)