jueves, 17 de julio de 2014

9 tips para armar un buen plan de pruebas

Ya sea que debas crear un plan de pruebas por primera vez o seas un tester experto, nunca está de más recibir algunos consejos. A continuación, 9 consejos que nacen de la experiencia de haber hecho muchos planes de prueba en variados proyectos:


  • (1) Usar un template es bueno, pero ¡el template no está hecho en piedra!

Es muy útil usar un template de Plan de pruebas como guía pero no hay que aferrarse a rajatabla a la estructura propuesta. Los proyectos informáticos son muy variados y no existe el template universal. El template sirve como ayuda pero el índice lo determinará finalmente la información de la que necesitemos disponer para guiar el proceso de testing a lo largo del proyecto.

  • (2) El plan de pruebas no es el cronograma de tareas

Muchas personas confunden un plan de pruebas con dar un calendario de cuándo se ejecutarán las pruebas y de cuánto tiempo llevarán. El cronograma de las pruebas es una parte del plan pero el plan es mucho más que solo el calendario. El plan contiene adicionalmente información sobre qué actividades se realizarán como parte del proceso de testing, qué objetos serán ítems a testear, qué estrategias se aplicarán, que tipos de pruebas se harán, como así también deja explicitado qué aspectos quedarán fuera del proceso de testing y por qué. Esta información determina una estrategia general que guiará el proceso de pruebas a lo largo del proyecto y que no debería cambiar demasiado en el transcurso del mismo. El cronograma de las pruebas, por otro lado, muy probablemente sufrirá modificaciones durante el proyecto.

  •  (3) Listar explícitamente cuales son las actividades dentro del alcance del plan es tan importante como listar cuales estarán fuera del mismo.

Lo más probable es que las actividades clásicas de un proceso de pruebas, como ser el diseño de casos, la ejecución de pruebas funcionales, registración de su resultado, registración de los issues/bugs, su comunicación y seguimiento, estén dentro del alcance. Pero algunas actividades relacionadas al aseguramiento de la calidad, como ser la revisión de artefactos del proyecto (casos de uso, especificaciones, documentos de arquitectura, etc.) podría o no estar contemplada. Así mismo como las actividades de automatizar la ejecución de las pruebas, o de actualizar/generar el material de soporte, o de participar del monitoreo de issues/bugs luego del despliegue en producción, por ejemplo. Indicar explícitamente en el documento de plan de pruebas cuales actividades formarán parte del alcance y enumerar cuáles no, provee un marco para dimensionar el esfuerzo que requerirá el proyecto y permite manejar correctamente las expectativas del cliente.

  •  (4) La naturaleza del proyecto guiará el diseño de las pruebas

Desde el punto de vista del alcance de los objetos a probar (¿qué se testeará?) y del alcance de las pruebas (¿qué tipos de pruebas se ejecutarán?) no es lo mismo un proyecto de migración/upgrade que un proyecto de mantenimiento o agregado de funcionalidades que un proyecto donde se construye un software de cero. Más aun, dos proyectos de la misma naturaleza no necesariamente se testearán de la misma forma. El plan de pruebas debe estar alineado al plan de proyecto: después de todo ¡estamos trabajando en el mismo proyecto! y muchos aspectos intrínsecos del proyecto determinan aspectos relacionados a la planificación de las pruebas. Este análisis es parte de la actividad de planificar las pruebas y sus justificaciones deben quedar escritas en el plan de pruebas.

  •  (5) Es importante conocer el landscape del proyecto y como se administrarán los despliegues al momento de planificar los ciclos de prueba

Cuando pensamos en las actividades del proceso de pruebas, pensamos por ejemplo en la de ejecutar las pruebas. Sin embargo tenemos que recordar que esta actividad se repetirá muchas veces a lo largo del tiempo. Potencialmente tendremos una ejecución con cada despliegue. Es por ello que para poder calendarizar las pruebas o dar un cronograma probable debemos conocer ¿cuántos ambientes componen el landscape del proyecto? ¿En cuáles se ejecutarán pruebas? ¿Cómo se administrará el despliegue de las correcciones que hagan falta hacer? No es lo mismo un proyecto con varios ambientes de desarrollo locales que deben mergearse (en otro ambiente) para luego pasar a un ambiente de calidad interno para luego pasar a uno de pre-producción del cliente para finalmente llegar a producción, que un proyecto con un ambiente de desarrollo, uno de pruebas y uno de producción. No es lo mismo que el desarrollador tenga acceso al ambiente de pruebas y pueda ir impactando correcciones individualmente a tener planificados una cierta cantidad de despliegues por ambiente. La motivación de las pruebas cambiará (¿focalizo la prueba en la corrección? ¿Será necesario contemplar una regresión con cada corrección? ¿Cuántos ciclos de prueba puedo planificar?), los tipos de prueba que aplicaré en cada ciclo pueden variar, y todo esto impacta en las dependencias de las tareas, en su cronología y en la estimación del esfuerzo.

  •  (6) Cuando el cliente participa de las pruebas, incluirlo en el plan de pruebas

¿El cliente participará de las pruebas? ¿Conviene involucrarlo de forma temprana? ¿Quiénes del lado del cliente harán pruebas? ¿En qué ambiente/s? ¿Debo contemplar horas de los recursos del proyecto para acompañar las pruebas del cliente? El conocimiento de los stakeholders, de qué tanta confianza nos tiene, de cuán firme o cambiante es en sus definiciones, de cuántas serán las personas que participen de la aceptación del producto, de si podrán hacer las pruebas por si mismos o requerirán guía/soporte del equipo del proyecto, de cómo se manejarán los potenciales bugs que puedan identificar, nos determinará aspectos que afectan la planificación de las pruebas. Las estrategias que se aplicarán deben indicarse en el plan de pruebas. Esto permite que la estimación resultante se asemeje a la realidad lo más posible respecto del esfuerzo que requerirá el proceso de pruebas.

  •  (7) Hablar un lenguaje común

¿Qué entendemos por objeto ítem de prueba? ¿Qué entendemos por caso de prueba? ¿Qué entendemos por ciclo de prueba? ¿Qué es una prueba de estrés, o de carga? No siempre todos los lectores del plan de pruebas le darán el significado que quiere transmitir quien escribe el plan de pruebas a las palabras y términos que usa el equipo de pruebas. Disponer de un glosario que acompañe el plan de pruebas es una buena práctica para que todas las personas que participan del proyecto entiendan lo mismo al momento de leer el plan de pruebas.

  •  (8) Comunicarlo

El plan de pruebas tiene como audiencia principal al equipo de pruebas porque es quien se compromete a llevarlo a cabo pero es importante comunicarlo al resto del equipo del proyecto. Debe ser revisado con el líder de proyecto quien tiene la visión del proyecto y de cómo lo administrará. Debe ser comunicado al equipo de desarrolladores, pues debemos estar todos de acuerdo en los objetos ítems de las pruebas (que deberían coincidir o serán un subconjunto de los que serán construidos). En algunos casos, a consideración del líder de proyecto, puede compartirse también con los stakeholders usuarios del proyecto, con quienes se podrán validar los criterios de aceptación y compartir la planificación de los ciclos de prueba de los usuarios.

  • (9) Mantenerlo actualizado o, dicho de otra manera: hacerlo para usarlo

Como todos los artefactos de la ingeniería de software, hacerlo para que quede perdido en una carpeta, desactualizado, sin haberse aplicado en el proyecto ninguna de las estrategias definidas es tirar el esfuerzo de haberlo hecho a la basura. El plan de pruebas se generará al inicio del proyecto, cuando aún no hay nada construido ni testeable. Muchas cosas pueden pasar hasta el momento en que efectivamente se ejecuta un ciclo de pruebas (¡ya conocemos el dinamismo de los proyectos!), estrategias del proyecto que determinaron aspectos del plan de pruebas pudieron verse afectados. Es por ello que el plan de pruebas debe ir siendo modificado según sucedan los acontecimientos. Mantenerlo actualizado sirve para poder identificar nuevos riesgos relacionados a lo comprometido originalmente, para poder definir nuevas estrategias o desestimar las que ya no apliquen. Para poder ir ajustando la estimación original del esfuerzo que será necesario para llevar a cabo las pruebas del proyecto de forma tal que se asemeje a la realidad lo mejor posible.

¡Gracias por tu contribución Cecilia Briozzo!