057 Testing Y Pensar Que Me Habian Dicho
•Descargar como PPT, PDF•
0 recomendaciones•301 vistas
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a 057 Testing Y Pensar Que Me Habian Dicho
Similar a 057 Testing Y Pensar Que Me Habian Dicho (20)
Más de GeneXus
Más de GeneXus (20)
Último
Último (20)
057 Testing Y Pensar Que Me Habian Dicho
- 1. Ing. Natalia Dimu, PMP Genexus Consulting A/P Rita Praderio Genexus Consulting
- 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
- 5. GeneXus Consulting Development Framework
- 25. Lic. Soledad Graña [email_address] Tecnologías de la Información - Desarrollo de Soluciones Testimonio de un Proyecto Reciente
- 30. ¿Preguntas?
Notas del editor
- 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.