Ing. Natalia Dimu, PMP  Genexus Consulting A/P Rita Praderio  Genexus Consulting
 
¿Por qué  el software falla? <ul><li>Mayor complejidad </li></ul><ul><li>Condiciones ambientales </li></ul><ul><li>Los des...
¿Por qué  el software falla? NO SI Ponemos a funcionar el sistema ¿Se ejecuta código defectuoso? Somos todos felices FALLA...
GeneXus Consulting  Development Framework
¿Quién no escuchó…? <ul><li>“ ¿Y eso cuánto te puede llevar probarlo…?” </li></ul><ul><li>“ Pero eso, con una “pasadita” p...
¿Qué es el testing? <ul><li>“ Proceso de operar un sistema o componente bajo condiciones especificadas, observando o regis...
Hablemos de testing
Hablemos de testing
Equipo <ul><li>Debe ser especializado e independiente del desarrollo </li></ul><ul><li>Debe tener roles definidos: </li></...
Hablemos de testing
Hablemos de testing
Requisitos <ul><li>Brindan conocimiento del negocio </li></ul><ul><li>Deben ser claros </li></ul><ul><li>Deben ser estable...
Hablemos de testing
Hablemos de testing
Planificación <ul><li>Establecer riesgos comerciales y del negocio </li></ul><ul><li>Definir el alcance y entregables </li...
Hablemos de testing
Hablemos de testing
Casos de Prueba  y Ejecución <ul><li>Elaborar los casos de prueba una vez que los requisitos están aprobados </li></ul><ul...
Casos de Prueba  y Ejecución <ul><li>No comenzar a ejecutar si el software no pasó por alfa-test </li></ul><ul><li>No come...
Hablemos de testing
Métricas <ul><li>Miden el avance del testeo </li></ul><ul><li>Permiten encontrar puntos débiles en el sistema </li></ul><u...
Aporte al Proyecto <ul><li>A los desarrolladores: </li></ul><ul><ul><li>Les permite concentrarse en la tarea del desarroll...
Aporte al Proyecto <ul><li>Al gerente del proyecto y al cliente: </li></ul><ul><ul><li>Información del estado de la aplica...
Lic. Soledad Graña [email_address]   Tecnologías de la Información - Desarrollo de Soluciones Testimonio de un Proyecto Re...
Incorporando Metodología <ul><li>Definición de roles </li></ul><ul><li>Un recurso múltiples roles </li></ul><ul><li>Casos ...
Siguiente paso ... <ul><li>Enfoque en  todos  los productos del proyecto </li></ul><ul><li>Metodología formal </li></ul><u...
Incorporando Testing <ul><li>Casos de Uso del Negocio </li></ul><ul><li>Casos de Uso de la Solución </li></ul><ul><ul><ul>...
Resultado ... <ul><li>Proyecto exigente </li></ul><ul><li>Rediseño de sistema crítico </li></ul>EXITO Roles  –  Genexus Co...
¿Preguntas?
Más información <ul><li>http://www.istqb.org/download.htm </li></ul><ul><li>Conferencias relacionadas </li></ul><ul><ul><u...
Upcoming SlideShare
Loading in …5
×

057 Testing Y Pensar Que Me Habian Dicho

696 views
640 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
696
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Porqué es relevante tener testing en un proyecto?
  • En ANCAP, en el departamento de Desarrollo, proyecto a proyecto venimos haciendo el esfuerzo de incorporar una metodología cada vez más formal, porque estamos convencidos del beneficio que esto trae. En el proyecto anterior a Fenicia, teníamos un equipo con el rol de gerente de proyecto, responsable de construcción y analistas/desarrolladores. Todos (el que cumplía el rol de gerente, responsable de construcción, analista) participábamos del relevamiento y estábamos en las definiciones de diseño y en el “testing”. El mismo equipo que relevó, analizó, diseñó y desarrolló, era el que testeaba y daba el ok del producto para que luego se cumplieran las pruebas de usuario. Teníamos una mínima especificación de casos de uso, sin mucho formalismo y con un muy básico nivel de detalle. Lo que nos ayudaba en lo que respecta a lo que vendrían a ser las tareas de testing y nos permitía poner en producción algo que sabemos que va a funcionar, era que las personas que tenían mucho conocimiento del negocio estaban participando del testing (sin toda esta metodología de la que se comentó en esta charla). Esas personas cumplían a su vez otros roles (uno de ellos era el propio gerente del proyecto) que por supuesto, no podía cumplir con su rol al 100 %. Siempre que pusimos algo en producción, sabíamos que ese algo iba a funcionar, es decir el producto final funciona, pero el producto del proyecto no es solamente el software, es también la documentación que se genera durante el proyecto que se utiliza como soporte y herramienta durante el proyecto y como insumo en los posteriores y la calidad del producto final no es solamente que “funcione”.
  • Cuando estábamos por comenzar con Fenicia queríamos pasar a trabajar ya con una metodología formal, cumpliendo mejor las etapas, las tareas que debe llevar adelante cada rol, pero que a su vez fuese viable para nuestra situación. Allí cuando empezamos a tartar este tema con GX Consulting, lo fuimos discutiendo, dando forma y ahí fue que GXC vino con una propuesta. La idea era que la gerencia del proyecto y el responsable de construcción fuesen de ANCAP, y todo lo que respecta a la construcción fuese de GXC. En esa propuesta que nos trajo GXC el equipo propuesto estaba conformado por el gerente de proyecto de GXC, jefe de desarrollo y desarrolladores, hasta ahí estaba todo bien. Pero también habían 3 personas de testing, uno de los cuales era el responsable del equipo de testing. Para ser totalmente sinsera, cuando nos plantearon 3 recursos de testing en un equipo planteado con 4 desarrolladores (incluido jefe de desarrollo) la verdad es que pensamos “esto es mucho, estos nos quieren vender horas de testing”. Nosotros queríamos bajar la cantidad de recursos de testing, me acuerdo que Marcela Fernández comentó “no les va a alcanzar, mirá que el trabajo que tiene testing es enorme, para mi 3 puede quedar medio corto”. Yo confío en que si me dicen eso es real, pero la verdad es que como no estábamos convencidos, no podíamos dejar de pensar de esa manera. La cuestión es que arrancamos con 2 personas a full y otra part time.
  • Cuando comenzó el equipo de testing ya habíamos finalizado la etapa de definición del modelo del negocio es decir toda la definición de los procesos de negocio completos, y teníamos los CU del negocio definidos, con el nivel de especificidad como para validarlo con los usuarios, además tengamos en cuenta que normalmente un CU del negocio, se explota en varios casos de uso del sistema o de la solución. Cuando comenzó a trabajar el equipo de testing, necesitaba tener especificados los CU de la solución. Allí tuvimos nuestro principal problema porque eran muy pocos los CU de la solución que estaban definidos y ninguno con el nivel de especificación que necesitaba testing. Durante el transcurso de este tiempo en el que estábamos con las especificaciones de los CU, y testing que pedía que se completara esto o aquello, que faltaba algo, que no estaba este CU, a este le faltan las validaciones, a este además le faltan los campos y la especificación de los procesos internos, etc, fue el momento de mayores dificultades. Testing pedía llegar a un nivel determinado de especificación de CU necesario para elaborar correctamente los casos de prueba, y en ese momento no podíamos cumplir al 100 % lo que testing nos solicitaba. Ahí surgían cosas como: “hasta ahora no teníamos tanto nivel de especificación y hacíamos las cosas bien, o sea, poníamos las cosas en producción y funcionaban, que se arreglen con esto los de testing, no podemos más”, el tema es que ahora nos estamos planteando no solamente poner algo en producción y que ande y no cancele, sino que estamos pretendiendo ejecutar proyectos con los mejores resultados durante la ejecución del proyecto, y en la puesta en producción, y que los resultados de todo esto nos sirvan para los siguientes proyectos. Lo cierto es que estábamos en una situación tal que no podíamos llegar al 100% de lo que debíamos aportar a testing, y si bien surgían esas cosas de “cómo exigen estos de testing”, también éramos concientes, o mejor dicho fuimos madurando cada vez más ese convencimiento de que era necesario cumplir con todas esas tareas. Nos adaptamos a la realidad que teníamos en ese momento y lo que se buscó fue cumplir al máximo posible. Por ejemplo hubo un conjunto de casos de uso que no eran críticos y no se había cambiado esa funcionalidad y se decidió no especificarlos y que para esos casos se hiciera un testing exploratorio. De los que se especificaron que fueron alrededor de XXXX, algunos se especificaron más completamente, con mayor nivel de detalle que otros. Esto se puede decir que fue la parte más pesada para nosotros, requiere mucho esfuerzo. Para aportar a la elaboración de los CP la otra parte importante además de los CU completos, es el conocimiento del negocio. Como las personas que estaban en testing, eran totalmente nuevos en ANCAP, buscamos la manera de que se fuera adquiriendo parte de ese conocimiento principalmente en los procesos más críticos, con algunas reuniones con usuarios clave por ejemplo. Ya cuando el equipo de testing había avanzado un poco, me di cuenta de que el planteo original de que eran insuficientes esos tres recursos era certero, por eso cuando vi el título de esta charla me sentí muy identificada “… y pensar que me habían dicho…”. Al final pudimos incorporar a otra persona más para tener 3 personas a full y una en los picos de trabajo.
  • Este proyecto fue muy grande, involucró muchas gerencias de ANCAP, fue sobre un sistema crítico para la empresa porque es el que soporta la toma de pedidos, las entregas, distribución y facturación de la empresa. Un problema en el sistema en el proceso de entregas o facturación, pueden causar que se pare la operativa de la planta y que se generen problemas importantes. Los cambios que se hicieron fueron muy grandes, en todos los módulos del sistema incluido el núcleo, se rediseñaron casi por completo algunos y se incorporaron otros nuevos. Hace dos fines de semana que entramos en producción con muy buen éxito, por supuesto que siempre surgen ajustes que están dentro de lo esperado de un post-productivo, pero realmente fue un proyecto muy grande con muchos cambios y tuvimos un muy buen resultado Ahora ya estamos por dar comienzo al siguiente proyecto en el que por supuesto el equipo de testing va a estar incorporado desde su comienzo, y realmente ya no podemos plantearnos planificar y gerenciar un proyecto sin un equipo de testing, si queremos obtener resultados como este (y mejores por supuesto) durante todo el proyecto, no solamente en la puesta en producción.
  • 057 Testing Y Pensar Que Me Habian Dicho

    1. 1. Ing. Natalia Dimu, PMP Genexus Consulting A/P Rita Praderio Genexus Consulting
    2. 3. ¿Por qué el software falla? <ul><li>Mayor complejidad </li></ul><ul><li>Condiciones ambientales </li></ul><ul><li>Los desarrolladores cometen errores </li></ul><ul><ul><li>Que genera código defectuoso </li></ul></ul><ul><ul><ul><li>Que si se ejecuta puede provocar una falla en el sistema </li></ul></ul></ul>
    3. 4. ¿Por qué el software falla? NO SI Ponemos a funcionar el sistema ¿Se ejecuta código defectuoso? Somos todos felices FALLA EN EL SISTEMA
    4. 5. GeneXus Consulting Development Framework
    5. 6. ¿Quién no escuchó…? <ul><li>“ ¿Y eso cuánto te puede llevar probarlo…?” </li></ul><ul><li>“ Pero eso, con una “pasadita” por arriba alcanza…” </li></ul><ul><li>“ No lo pruebes porque modifiqué solo esta cosita...” </li></ul>
    6. 7. ¿Qué es el testing? <ul><li>“ Proceso de operar un sistema o componente bajo condiciones especificadas, observando o registrando los resultados, evaluando ciertos aspectos de ese sistema o componente” (IEEE 610) </li></ul>
    7. 8. Hablemos de testing
    8. 9. Hablemos de testing
    9. 10. Equipo <ul><li>Debe ser especializado e independiente del desarrollo </li></ul><ul><li>Debe tener roles definidos: </li></ul><ul><ul><li>Coordinador </li></ul></ul><ul><ul><li>Analista </li></ul></ul><ul><ul><li>Tester </li></ul></ul><ul><li>Es importante fomentar la colaboración entre los distintos equipos </li></ul>
    10. 11. Hablemos de testing
    11. 12. Hablemos de testing
    12. 13. Requisitos <ul><li>Brindan conocimiento del negocio </li></ul><ul><li>Deben ser claros </li></ul><ul><li>Deben ser estables y versionados </li></ul><ul><li>Funcionales y no funcionales </li></ul>
    13. 14. Hablemos de testing
    14. 15. Hablemos de testing
    15. 16. Planificación <ul><li>Establecer riesgos comerciales y del negocio </li></ul><ul><li>Definir el alcance y entregables </li></ul><ul><li>Armar el equipo de trabajo </li></ul><ul><li>Indicar tipos y niveles </li></ul><ul><li>Estimación </li></ul><ul><li>Herramientas y ambientes </li></ul>
    16. 17. Hablemos de testing
    17. 18. Hablemos de testing
    18. 19. Casos de Prueba y Ejecución <ul><li>Elaborar los casos de prueba una vez que los requisitos están aprobados </li></ul><ul><li>Hacer hincapié en los riesgos del negocio </li></ul><ul><li>Definir cuáles son los casos que se van a automatizar </li></ul><ul><li>Crear scripts con consultas comunes y otros que capturen datos para la ejecución </li></ul>
    19. 20. Casos de Prueba y Ejecución <ul><li>No comenzar a ejecutar si el software no pasó por alfa-test </li></ul><ul><li>No comenzar si la versión no es estable  Evitar el “andá probando” </li></ul><ul><li>Funcional primero, no funcional al final </li></ul><ul><li>Registrar los resultados </li></ul><ul><li>No seguir testeando si se alcanzó el criterio de fin del testeo </li></ul>
    20. 21. Hablemos de testing
    21. 22. Métricas <ul><li>Miden el avance del testeo </li></ul><ul><li>Permiten encontrar puntos débiles en el sistema </li></ul><ul><li>Brindan información que sirve a la toma de decisiones </li></ul><ul><li>Fuentes: </li></ul><ul><ul><li>Requisitos </li></ul></ul><ul><ul><li>Casos de prueba </li></ul></ul><ul><ul><li>Herramienta de gestión de incidentes </li></ul></ul>
    22. 23. Aporte al Proyecto <ul><li>A los desarrolladores: </li></ul><ul><ul><li>Les permite concentrarse en la tarea del desarrollo </li></ul></ul><ul><ul><li>Visión crítica del sistema </li></ul></ul><ul><ul><li>Brindar información exacta de cuándo es que el sistema falla </li></ul></ul><ul><ul><li>Confianza en el producto desarrollado </li></ul></ul>
    23. 24. Aporte al Proyecto <ul><li>Al gerente del proyecto y al cliente: </li></ul><ul><ul><li>Información del estado de la aplicación a través de las métricas </li></ul></ul><ul><ul><li>Apoyo en la toma de decisiones </li></ul></ul><ul><ul><li>Apoyo en la planificación de las actividades </li></ul></ul><ul><ul><li>Tranquilidad y confianza </li></ul></ul>
    24. 25. Lic. Soledad Graña [email_address] Tecnologías de la Información - Desarrollo de Soluciones Testimonio de un Proyecto Reciente
    25. 26. Incorporando Metodología <ul><li>Definición de roles </li></ul><ul><li>Un recurso múltiples roles </li></ul><ul><li>Casos de Uso </li></ul><ul><li>Conocimiento del negocio </li></ul><ul><li>Enfoque en el producto final </li></ul>
    26. 27. Siguiente paso ... <ul><li>Enfoque en todos los productos del proyecto </li></ul><ul><li>Metodología formal </li></ul><ul><li>Etapas, entregables </li></ul><ul><li>Roles </li></ul>
    27. 28. Incorporando Testing <ul><li>Casos de Uso del Negocio </li></ul><ul><li>Casos de Uso de la Solución </li></ul><ul><ul><ul><li>Pocos, detalle mínimo  muchos, espec. completa </li></ul></ul></ul><ul><li>“ Hasta ahora funcionábamos bien” vs. “Calidad en todo el proyecto” </li></ul><ul><li>Adaptarse para obtener el máximo </li></ul>
    28. 29. Resultado ... <ul><li>Proyecto exigente </li></ul><ul><li>Rediseño de sistema crítico </li></ul>EXITO Roles – Genexus Consulting Cant Director de Proyecto 1 Gerente de Proyecto 1 Jefe de Desarrollo 2 Desarrolladores 4 Coordinador de Testing 1 Analista de Testing 2 Roles - ANCAP Cant Gerente de Proyecto 1 Responsable de Construcci ó n 1 Desarrolladores SAP 2 T é cnico Seguridad 1 T é cnico Infraestructura 2 Responsables de Proceso 7 Usuarios Clave 35
    29. 30. ¿Preguntas?
    30. 31. Más información <ul><li>http://www.istqb.org/download.htm </li></ul><ul><li>Conferencias relacionadas </li></ul><ul><ul><ul><li>Testing Automatizado: ¡Hagamos que las máquinas trabajen por nosotros! – Sala Picasso, hora 09:45 </li></ul></ul></ul><ul><ul><ul><li>Todos los testings, el testing – Sala Picasso, hora 11:00 </li></ul></ul></ul><ul><ul><ul><li>GXC Dev. Framework: Análisis y desarrollo, buenas prácticas para la convivencia – Sala Picasso, hora 11:45 </li></ul></ul></ul><ul><ul><ul><li>Café con Testing Automatizado – Sala Torres García, hora 14:30 </li></ul></ul></ul><ul><li>Ing. Natalia Dimu, PMP, [email_address] </li></ul><ul><li>A/P Rita Praderio, [email_address] </li></ul>

    ×