lecciones aprendidas

El proceso de test en el desarrollo de software

jmartinmateo, , , , , Leave a comment

La calidad del software que generamos para nuestras organizaciones es muy dependiente del esfuerzo y tiempo dedicados a su testeo.

No obstante, ese esfuerzo debe ser objeto de un análisis crítico que asegure que los resultados obtenidos compensan el coste dedicado. Por otra parte se debe ser consciente de los riesgos asumidos al limitar el esfuerzo de test. Como en muchas otras situaciones de la vida, se trata de buscar el equilibrio.

De acuerdo con el ISTQB el proceso de test debe seguir las siguientes fases:

  • Planificación y control
  • Análisis y diseño
  • Implementación y ejecución
  • Evaluación y reporte
  • Cierre

 

Estas fases se suceden secuencialmente, si bien el control debe seguirse durante todas las fases del proceso, no sólo en la planificación inicial.

1. Planificación y control

Debe iniciarse, idealmente, lo antes posible dentro del ciclo de desarrollo del software. Es preciso completar un plan de test que incluya:

  • recursos necesarios,
  • tiempo estimado,
  • servicios, medios adicionales,
  • herramientas, …

El testeo exhaustivo es, por lo general, imposible. Es preciso, por tanto, definir prioridades y analizar los riesgos de omitir determinados tests o de limitar su intensidad o alcance.

2. Análisis y diseño

En esta fase se determinan las técnicas de test a seguir, alineadas con la estrategia definida en el paso anterior, se definen los casos de test y el calendario o secuencia. En paralelo se deberá poner en marcha la infraestructura necesaria para realizar los tests.

3. Implementación y ejecución

A partir de los casos de test definidos de forma lógica en la fase anterior se derivarán y ejecutarán casos de test concretos.

En esta fase es preciso seguir un protocolo de test que incluya las partes a testear, las personas asignadas, los tiempos y calendarios, la extensión de cada test a realizar y los resultados esperados.

Además, es fundamental realizar un registro de los resultados.  Éstos nos pueden llevar a plantearnos si los posibles errores encontrados están dentro o fuera del objeto del test y, consecuentemente, a replantearnos el protocolo diseñado y seguido.

Al mismo tiempo, los errores encontrados deben ser documentados, priorizados y asignados a los desarrolladores para solucionarlos.

En otra entrada entraré en mayor detalle pero aquí quiero comentar la importancia de agrupar los casos de test en secuencias y/o escenarios y de realizar primero los llamados “smoke tests” que permitan verificar la bondad de las funciones principales antes de entrar en  casos más detallados y completos (que no tienen sentido si los tests básicos no han sido superados).

4. Evaluación y reporte

En esta fase empezaremos por evaluar si los criterios de finalización de los tests han sido alcanzados.

En caso negativo será preciso analizar si se ha debido a que algunos casos de tests han tenido que ser bloqueados o si es preciso añadir más casos de test.

Para tomar una decisión razonada, como siempre, habrá que tener en cuenta tanto los riesgos asociados con no añadir más casos de test como los costes (dinero y tiempo) de hacerlo.

En cualquier caso, finalizaremos esta fase con un informe que incluya todos los resultados y las conclusiones y decisiones tomadas.

5. Cierre

Esta fase, desgraciadamente, suele ser olvidada en, muchos proyectos.

La experiencia obtenida durante el proceso de test debe ser analizada y puesta a disposición de otros proyectos. En otro post de este mismo blog ya he hablado sobre ello dentro del contexto de la gestión de proyectos en general.

La documentación y aplicación de los resultados de una evaluación crítica de las actividades realizadas durante el proceso de test, considerando esfuerzo en relación a resultados, nos llevará a la mejora continua.

Para acabar, otro punto a tener en cuenta en esta fase final es la necesaria conservación del “testware” (casos de test, protocolos, infraestructura, herramientas) para su uso posterior cuando nuestro cliente nos pida cambios o cuando encontremos nuevos errores ocultos en nuestra aplicación.

El proceso de test en el desarrollo de software

The importance of the lessons learnt

jmartinmateo, 2 Comments

During this month (july 2012) I am going to finish a software development project that I have been leading as a project manager since its beginning in february. It has been hard, physically and mentally, and with very challenging deadlines.

Also in these weeks I am reading an interesting book from Peter Taylor, “The lazy project manager”. I have taken notes of two important ideas from the book that I can apply in this final phase of my project:

The shape of the projects.

Projects are thick in the beginning, thinner in the middle and thick again in the end.

It means that we must dedicate a lot of time and effort to bring the project inside the road at its initial phase (planning) in order to be able to “rest” a little bit during its execution and  monitoring phases. Finally we have to notice the importance of the closing phase and dedicate the necessary time and effort to finish our projects properly.

This final effort must be shared with the rest of the team, the sponsor, the client and also the other stakeholders. A part from obtaining acceptance of all the deliverables and closing contracts a very important activity in this phase is to register the lessons learnt during the project.

This is something that many times is forgotten or understimated.

What we know we know, what we know we don’t know  and what we don’t know we don’t know.

At the end of the book Peter Taylor quotes Mr. Donald Rumsfeld (12 February, 2002, US Dept. of Defense news briefing): ‘As we know, there are known knows. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know‘.

I have enjoyed specially this part of the book.

When we work on the registry of the lessons learnt during the chapter we must consider:

  1. What we didn’t know at the beginning of the project and we have learnt during its development. That is to know what we know.
  2. To know what we don’t know. The gaps in our experience of the project that we can fill up by asking our team.
  3. The unknown unknowns. This must be unveiled through a project retrospective where all the stakeholders should participate. It is a healthy habbit to plan for this in the final phase of the project.
Would he repeat it ?
Horse stumbles after the jump, would he repeat it ?

And why do we have to dedicate so many time and effort to all these lessons learnt if our project is almost closed and the deliverables have already been accepted?

In order to avoid that the sentece that says that ‘the man is the only animal capable to trip twice over the same stone‘ continues being true in the future. At least I think we should try it. Don’t you?

The importance of the lessons learnt

Una reunión ineficiente

jmartinmateo, , , , 2 Comments

Esta semana he participado en una multiconferencia con el objeto de resolver un problema.

La eficacia de la reunión está por ver. Tras la reunión se decidió la realización de una serie de acciones con objeto de resolver el problema. Si hemos acertado en diagnosticar la causa (raíz) del problema probablemente éste desaparecerá. En caso contrario, volveremos a tener la misma reunión dentro de 3 o 4 meses …

Sin embargo el título de esta entrada no era “una reunión ineficaz” sino una “reunión ineficiente”. ¿Causas? Probablemente estaba convocada demasiada gente (13 o 14 personas), en 4 ubicaciones diferentes y con una agenda poco definida.

La multiconferencia acabó durando 2 horas. Problemas:

  • Tiempo excesivo para mantener la atención de todo el mundo. No hubo ni un descanso.
  • Nadie ha calculado el coste de toda esa gente durante 2 horas, pero sería muy positivo calcularlo.

¿Qué nos falló? Hay varias fases en una reunión. En nuestro caso probablemente falló la ejecución de la reunión, aunque la preparación también sería mejorable.

Fotografía de noii's con licencia Creative Commons

Preparación

En una reunión con tantos participantes, creo que el convocante debería haber mantenido reuniones exploratorias previas para conocer las posiciones de cada grupo, de forma que en la multiconferencia final hubiesemos podido ir al grano sobre una propuesta ya consensuada.

Por otra parte, en lugar de partir de una duración preestablecida probablemente habría sido más efectivo un enfoque bottom-up, en el que se asigna un tiempo (más o menos agresivo) a cada punto y por agregación se obtiene la duración prevista de la reunión.

Ejecución

Como consecuencia de la mala preparación, los diferentes puntos del orden del día se iban sucediendo tal y como estaba previsto en  la agenda, pero sin límite de tiempo definido. Al cabo de una hora, los asistentes que estaban en mi misma ubicación llevaban ya un buen rato resoplando. Tras una hora de reunión, nos estábamos entreteniendo en temas menores y aún no habíamos llegado a tratar el problema central.

Finalmente llegamos a él, al cabo de 80 minutos. Todo el mundo estaba ya cansado y con más ganas de acabar la reunión que de resolver la cuestión. Hubo gente presente las 2 horas que duró la reunión y que, en realidad, sólo tenía que haber participado durante 5 minutos concretos en la parte final. Nuevamente, con una buena agenda y tiempos acotados para cada punto se les podría haber hecho participar sólo el tiempo preciso, cuando su aportación era necesaria.

Conclusión

Esta experiencia debe pasar a formar parte de nuestras lecciones aprendidas.

Ante una reunión, debemos primero plantearnos si es o no necesaria, si es el mejor medio para conseguir muestro propósito. En caso afirmativo, hay que prepararla bien, no sólo enviando la convocatoria sino discutiendo previamente los puntos a tratar, el orden y el tiempo a dedicarles. También hay que hacer participar sólo a aquella gente que es necesaria y durante el tiempo preciso.

Durante la ejecución se debe seguir el guión de forma estricta y, al acabar, no debemos olvidar el seguimiento. Si no se sale de la reunión con acciones concretas, con responsables concretos de ejecutarlas y con fechas límite para ello la reunión no habrá servido de nada.

Además, luego se debe verificar el cumplimiento del plan de acciones y, finalmente, comprobar si el plan ha sido efectivo y ha servido para solucionar el problema.

Y tú, ¿te enfrentas con frecuencia a reuniones inefectivas y/o ineficientes? Puedes explicar tus experiencias en un comentario. Compartiendo aprendemos todos.

Una reunión ineficiente