A proposal is developed to get use case documentation according the second value of agilism. It complements a use case to be executable. Presentation given at "Regional Scrum Gathering Ecuador 2015"
Wodel-Test: A Model-Based Framework for Language-Independent Mutation Testing...Pablo Gómez Abajo
Las pruebas de mutación (MT) tienen como objetivo la evaluación de los casos de prueba midiendo su eficiencia para detectar fallos. Esta técnica implica modificar los programas bajo prueba para emular fallos comunes de programación y evaluar si los casos de prueba existentes detectan dichas mutaciones. Las pruebas de mutación se han estudiado de forma exhaustiva desde 1970, y se han propuesto muchas herramientas de pruebas de mutación para lenguajes utilizados ampliamente como C, Java, Fortran, Ada y SQL, y notaciones como redes de Petri. No obstante, crear herramientas de pruebas de mutación es costoso y propenso a errores, lo que puede obstaculizar su creación para nuevos lenguajes de programación y lenguajes de dominio-específico (de modelado).
En este trabajo, se propone un entorno llamado Wodel-Test que reduce el esfuerzo para crear herramientas de pruebas de mutación. Con este objetivo, se sigue un enfoque dirigido por modelos por medio del que se sintetizan las herramientas de pruebas de mutación a partir de una descripción de alto nivel. Esta descripción utiliza el lenguaje de dominio específico Wodel para definir y ejecutar las mutaciones de modelos. Wodel es independiente del dominio, es decir, permite la creación de operadores de mutación para cualquier lenguaje definido mediante un meta-modelo. Partiendo de la definición de los operadores de mutación, Wodel-Test genera un entorno de pruebas de mutación que transforma los programas bajo prueba en modelos, aplica los operadores de mutación, y evalúa el conjunto de pruebas contra los mutantes generados, proporcionando una rica colección de métricas de pruebas de mutación. En el trabajo, se proporciona una evaluación del enfoque basada en la creación de herramientas de pruebas de mutación para Java y el lenguaje de transformación de modelos ATL.
Wodel-Test: A Model-Based Framework for Language-Independent Mutation Testing...Pablo Gómez Abajo
Las pruebas de mutación (MT) tienen como objetivo la evaluación de los casos de prueba midiendo su eficiencia para detectar fallos. Esta técnica implica modificar los programas bajo prueba para emular fallos comunes de programación y evaluar si los casos de prueba existentes detectan dichas mutaciones. Las pruebas de mutación se han estudiado de forma exhaustiva desde 1970, y se han propuesto muchas herramientas de pruebas de mutación para lenguajes utilizados ampliamente como C, Java, Fortran, Ada y SQL, y notaciones como redes de Petri. No obstante, crear herramientas de pruebas de mutación es costoso y propenso a errores, lo que puede obstaculizar su creación para nuevos lenguajes de programación y lenguajes de dominio-específico (de modelado).
En este trabajo, se propone un entorno llamado Wodel-Test que reduce el esfuerzo para crear herramientas de pruebas de mutación. Con este objetivo, se sigue un enfoque dirigido por modelos por medio del que se sintetizan las herramientas de pruebas de mutación a partir de una descripción de alto nivel. Esta descripción utiliza el lenguaje de dominio específico Wodel para definir y ejecutar las mutaciones de modelos. Wodel es independiente del dominio, es decir, permite la creación de operadores de mutación para cualquier lenguaje definido mediante un meta-modelo. Partiendo de la definición de los operadores de mutación, Wodel-Test genera un entorno de pruebas de mutación que transforma los programas bajo prueba en modelos, aplica los operadores de mutación, y evalúa el conjunto de pruebas contra los mutantes generados, proporcionando una rica colección de métricas de pruebas de mutación. En el trabajo, se proporciona una evaluación del enfoque basada en la creación de herramientas de pruebas de mutación para Java y el lenguaje de transformación de modelos ATL.
Living with acceptance tests: Beyond Write-Once (XP NYC)Daniel Wellman
This presentation is from the XP NYC meetup. It was presented on February 10, 2015.
Acceptance tests have become a common part of building software for an agile process. However, I've observed a trend of growing build times - with teams saying "Our build is 15 minutes... well, actually it's 45 minutes because our Cucumbers took so long, so we parallelized the cukes." One reason for this may be that teams treat their acceptance tests as "Write-Once": create for a new story, get them to pass, and leave them be. In this talk we'll explore the technical and social forces that cause an acceptance test suite to grow, and discuss some ways to refactor and improve these tests. We'll touch on hexagonal architecture, declarative vs. imperative style, and alternate Cucumber step implementations.
Agile Testing: The Role Of The Agile TesterDeclan Whelan
This presentation provides an overview of the role of testers on agile teams.
In essence, the differences between testers and developers should blur so that focus is the whole team completing stories and delivering value.
Testers can add more value on agile teams by contributing earlier and moving from defect detection to defect prevention.
Introduction to Agile software testing - The 5th seminar in public seminar series from KMS Technology which have been delivering from 2011 in every two months
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 3 - Tema 2
Contenido: concepto, tipos, escenarios, casos de uso vs casos de prueba, atributos e importancia.
Mejores prácticas para testing de aplicacionesSoftware Guru
http://sg.com.mx/sgce/2013/sessions/mejores-pr%C3%A1cticas-para-testing-aplicaciones
Se mostrarán las mejores prácticas para la generación de las diferentes tipos de pruebas que existen para las aplicaciones antes de salir a producción.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Living with acceptance tests: Beyond Write-Once (XP NYC)Daniel Wellman
This presentation is from the XP NYC meetup. It was presented on February 10, 2015.
Acceptance tests have become a common part of building software for an agile process. However, I've observed a trend of growing build times - with teams saying "Our build is 15 minutes... well, actually it's 45 minutes because our Cucumbers took so long, so we parallelized the cukes." One reason for this may be that teams treat their acceptance tests as "Write-Once": create for a new story, get them to pass, and leave them be. In this talk we'll explore the technical and social forces that cause an acceptance test suite to grow, and discuss some ways to refactor and improve these tests. We'll touch on hexagonal architecture, declarative vs. imperative style, and alternate Cucumber step implementations.
Agile Testing: The Role Of The Agile TesterDeclan Whelan
This presentation provides an overview of the role of testers on agile teams.
In essence, the differences between testers and developers should blur so that focus is the whole team completing stories and delivering value.
Testers can add more value on agile teams by contributing earlier and moving from defect detection to defect prevention.
Introduction to Agile software testing - The 5th seminar in public seminar series from KMS Technology which have been delivering from 2011 in every two months
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 3 - Tema 2
Contenido: concepto, tipos, escenarios, casos de uso vs casos de prueba, atributos e importancia.
Mejores prácticas para testing de aplicacionesSoftware Guru
http://sg.com.mx/sgce/2013/sessions/mejores-pr%C3%A1cticas-para-testing-aplicaciones
Se mostrarán las mejores prácticas para la generación de las diferentes tipos de pruebas que existen para las aplicaciones antes de salir a producción.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Meetup TestingUy 2019 - ¿Test cases? ¿Son siempre necesarios?TestingUy
Expositor: Edgardo Crovetto
Resumen: ¿Cuántas veces pasa que hay que hacer tests cases por el hecho de hacerlos y además hechos para ayer porque no hay tiempo?¿Qué podemos hacer para mantener el máximo cubrimiento de prueba y mínima documentación?
El objetivo es realmente enfocarnos en hacer entrega de un producto de calidad, sin la obligación de crear documentación innecesaria por el hecho de hacerlo. Al mismo tiempo, poder mostrar cubrimiento de pruebas apropiado y hacer los informes necesarios para poder estar confiados que se está entregando con calidad.
En esta charla trataremos de dar un enfoque para poder elegir una buena estrategía en base a algún caso práctico.
Charla presentada en #ISA15
Descarga del framework para trabajar:
http://www.slideshare.net/gusoto/framework-storyboard-como-herramienta-de-validacin-interaction-south-america-2015
PC-04-DISEÑOS DE PITS Y STOPES DE UNA MINA A TAJO ABIERTO.pdf
Giving an agile flavor to Use Case documentation
1. Giving an agile flavor to
Use Case documentation
Regional Scrum Gathering Ecuador 2015
(Universidad de Las Américas)
José Cahuana Turpo
jcahuana@ucsm.edu.pe
Walter A. Carpio
wcarpiom@ucsm.edu.pe
@wcarpiom
1
2. Agenda
● Introducción
○ Estado del arte
○ Terminología
○ Formatos
● Desarrollo
○ Formalización
○ Algunos números
○ Caso de estudio
○ Aplicación de la propuesta
○ Demostración
● Conclusiones y trabajos futuros
2
5. Pruebas de aceptación (AT)
5
● Son las pruebas que configuran los criterios de aceptación por parte del
usuario. El enfoque está basado en pruebas de caja negra, donde el
usuario en base a lo que ve en la interfaz, prueba la funcionalidad y
demás atributos del software.
6. Desarrollo basado en pruebas (TDD)
6
● En un desarrollo basado en pruebas, las pruebas son el proceso inicial de
todo el desarrollo del software. Luego se produce el código mínimo
necesario para superar las pruebas.
Extraído de http://crowdsourcetesting.com/test-driven-development/
7. Desarrollo basado en pruebas de aceptación (ATDD)
7
● Es un tipo particular de TDD, donde cada prueba representa un requerimiento que pueda ser
probado, entonces la prueba de aceptación se va a dar por el comportamiento que muestre el
sistema, respecto de la funcionalidad solicitada.
● Algo importante de este desarrollo es que fomenta la comunicación entre el cliente y el
desarrollador.
9. User Story
9
● Una user story es la descripción de la funcionalidad solicitada que tiene un
valor intrínseco.
● Previo a dicha descripción, se conversa con el usuario respecto de su
situación, y de sus necesidades.
14. Algunos números
User stories
Use cases
Customer Oriented
Main success scenario
Story points
Faster and shorter
Model interaction
Many scenarios
Use case points
More time for analysis and writing
14Fuente: Ambysoft, url: http://www.ambysoft.com/surveys/howAgileAreYou2013.html
15. Formalización de un Caso de Uso
15
Sea un UC un caso de uso representado por la tupla
(A, d, F), donde:
-A es el conjunto de actores.
-d es la descripción de la funcionalidad requerida.
-F es un conjunto de flujos básico y alternativos.
16. Formalización de una Historia de Usuario
16
Sea una US una User Story representada por la tupla
(A, s, F, O), donde:
-A es quien necesita la funcionalidad.
-s es la historia del usuario que provocó la necesidad.
-F es la expresión de la necesidad.
-V es el valor que tiene la necesidad para el usuario.
17. Caso estudio
17
● Se desea especificar las necesidades de una biblioteca.
● El usuario puede buscar en el inventario de publicaciones.
● La información de cada publicación será mostrada en una ficha individual.
● Se deben poder administrar préstamos de las publicaciones.
20. Formalización de un test de aceptación
20
Sea un AT (Test de aceptación) una tupla formada por (F,
S, d, A), donde
-F es un feature a comprobar.
-S es el conjunto de steps que componen el feature.
-d es el conjunto de funciones de implementación para cada
step, donde una de esas funciones di es la que comprueba
si se alcanza el estado de aceptación.
-A es el estado de aceptación para la prueba.
21. Formalización: Resultado
21
Sea un UC-S (satisfiable use case) una tupla formada por
(A, d, F, ATs), donde
-A, d y F corresponden a la definición habitual de un UC, y
-ATs es un conjunto de funciones booleanas, que luego de su
ejecución, todas dan true. En caso alguna de false producto
de un test de regresión, se realiza una verificación del
sistema, hasta que sea totalmente satisfecha.
23. Conclusiones
23
1. Uno de los inconvenientes de los casos de uso es que no son ejecutables.
2. Los criterios de aceptación agregados a la especificación de casos de uso
sí se pueden automatizar.
3. La propuesta se ajusta al segundo valor del agilismo: se prefiere software
funcionando a la documentación exhaustiva.
4. Las especificaciones de los flujos principal o alternos en los casos de uso,
generan procesos de pruebas manuales.
5. Se automatizan las pruebas que protegen contra daños colaterales.
6. Los tests de aceptación facilitan las pruebas de regresión
24. Trabajos a futuro
24
● UC-S para requerimientos no funcionales.
● Generación automática de informe de pruebas.