Anteriormente he comentado sobre nuestra misión como testers, y en relación a cómo evaluar el producto, he escrito sobre cómo podemos pensar qué probar http://excelza.blogspot.com/2009/11/pensando-que-probar.html.
Recientemente he leído un libro muy interesante de Greg Fournier, sobre lo que el autor denomina Essential Testing, que está en línea en gran medida con muchos de los conceptos expresados en los dos artículos mencionados. Creo útil hacer un breve resumen de las principales ideas presentadas, y compartirlo en este blog.
“Essential Testing says test the right things
to the right level of detail
at the right time,
providing results in the proper context
to prove the system under test with the most efficient amount of effort.”
O sea:
Hacer lo necesario para probar lo que se debe,
al nivel adecuado de detalle,
en el momento adecuado,
proveyendo resultados en función al contexto,
de la manera más eficiente posible.
Sobre lo ágil y lo esencial
Fournier parte de la premisa de que se requiere ser “ágiles” para hacer “testing esencial”, definiendo “agile” como “lean & mean”, o sea, magro y escueto.
Ser ágiles es importante; ser eficientes implica ir más allá de lo ágil, ejecutando sólo las actividades que no malgastan esfuerzo. Para los testers, esto significa asegurar que el producto final satisface ciertos estándares de calidad, y presentar los resultados en una forma aceptable y entendible por todos los interesados del proyecto.
Probar en una forma ágil, implica:
· Entender qué se tiene que hacer (expectativas sobre el producto y sobre el proyecto).
· Entender qué significa probar al nivel adecuado de detalle, lo que en general estará en línea con la misión de los testers, y con los riesgos identificados, en función al tiempo disponible.
· Identificar las fronteras del proyecto y su contexto.
· Comunicarse y comunicarse y comunicarse con todos los interesados… para entender bien esas fronteras y límites.
· Anticipar los cambios, estar preparado para cuando ocurran, pero no planificar para cada cambio posible… algunos ocurrirán, otros no.
· Ser minimalista, si no se está seguro de incluir alguna actividad en el plan, en principio eliminarla; siempre habrá tiempo de volver a incluirla si es necesario.
· Estar preparado para explicar. Hacerse entender; ser persuasivo.
· No concluir que un proyecto es igual a otro porque tiene algunas similitudes; siempre considerar qué cambios puede requerir un proceso ya conocido en un proyecto nuevo.
· Ser proactivo, alertar sobre problemas tempranamente si se detectan; estar dispuesto a replanificar.
· Fomentar la retroalimentación de los distintos interesados y otros miembros del proyecto, acerca de las pruebas.
· Respetar a los demás y su trabajo. Esperar y lograr respeto de los demás hacia los testers y su trabajo.
Y todo esto, independientemente de los tipos de proyectos y de las metodologías de construcción de software en que nuestro proceso de testing esté desarrollándose (iterativos ágiles, iterativos pesados (orientados al plan), waterfall pesados, altamente regulados).
El proceso de testing esencial
Fournier propone aplicar siempre “la regla de oro”: construir el proceso de testing para cada proyecto en particular, siendo tan eficiente como sea posible, y focalizando lo que se debe testear.
Para ello:
1. Entender las necesidades y percepciones de los interesados.
2. Entender el tamaño y alcance del proyecto.
3. Identificar los “artefactos” del proyecto que el equipo de testing va a recibir (qué especificaciones y cuándo), y cuáles se espera que genere (plan de pruebas, casos de prueba automatizados y/o manuales, reportes, otros). Procesos más “pesados” implican en general más artefactos y eventualmente diferentes clases de inspecciones o revisiones para que los mismos sean aprobados.
4. Identificar las actividades del proyecto que hay que cumplir para generar esos artefactos.
5. Lograr sinergia con el resto del equipo de proyecto, tanto a nivel personas como a nivel artefactos y herramientas. Colaborar con el bienestar de todo el equipo.
6. Minimizar los artefactos a generar, tanto por el equipo de testing como por el resto del equipo de proyecto. Siempre considerar cuál es el conjunto mínimo de entregables que hará felices a los interesados, y cuáles aquéllos sin los que el proyecto no será exitoso. Considerar cuáles son intermedios y no se justifica mantener, y cuáles de largo plazo, por lo que deberán ser actualizados y mantenidos.
7. Entender cuándo y cómo se harán las entregas de software para las pruebas. Esto depende en gran medida de la metodología aplicada en el proyecto.
Algunos conceptos básicos
Fournier detalla como conceptos fundamentales que son herramientas esenciales para el tester:
1. Pruebas de caja negra, basadas en requerimientos.
2. Pruebas de caja blanca, basadas en estructura interna y diseño.
3. Pruebas unitarias, que están en el ámbito del desarrollador (es esencial que se hagan).
4. Requerimientos, que son la base del trabajo del tester, expresan las condiciones o restricciones que el software tiene que cumplir, y se dividen en funcionales y no funcionales.
5. Expectativas de los interesados que el tester tiene que poder relevar o conocer, y que en general son de más alto nivel que los requerimientos.
6. Trazabilidad desde los requerimientos hasta los componentes y casos de prueba, en especial cuando los productos tienen condiciones regulatorias que cumplir (por ejemplo, productos que deban ser certificados por organismos relacionados con la Fuerza Aérea, la Sanidad Pública, etc.).
7. Cobertura, en particular cuando hay que demostrar que se ha cumplido cierta cantidad o tipo de pruebas (cobertura de pruebas respecto a requerimientos, cobertura de pruebas respecto a líneas de código).
8. Casos de uso, esenciales para testear correctamente: si no están disponibles, el tester tiene que poder / saber escribirlos, lo que aportará mucho valor al proyecto.
9. Escenarios y/o User Stories.
Otros conceptos y técnicas igualmente importantes
1. Planes de prueba. Los mínimos necesarios y suficientes para entender qué se debe hacer y cuándo. Sin demasiado nivel de detalle, seguramente van a cambiar sobre la marcha.
2. Casos de prueba. Condiciones y resultados esperados que permitan probar los requerimientos, expresados típicamente como casos de uso.
3. Scripts de prueba. Qué hace el testar para probar; pueden formar parte de los procedimientos de prueba, y ser armados para pruebas manuales o automáticas.
4. Procedimientos de prueba. Que permitan al tester preparar, ejecutar y analizar los resultados de los casos de prueba. Sólo se requiere escribirlos expresamente si son complejos.
Las cualidades deseables en los testers
1. Comunicación para poder interactuar eficientemente con los distintos niveles de interesados.
2. “Arrojo”, tener el valor de ser proactivo y tomar el toro por las astas en muchos momentos del proyecto.
3. “Agilidad”, entender qué cosas son las mínimas a hacer, para lograr liberar un producto con suficiente calidad para los diferentes interesados, y nada más.
Cómo seguir un proceso exitoso
1. Planificar las pruebas, sólo lo necesario para entender y arrancar.
2. Utilizar los requerimientos para comandar las pruebas.
Aprovechar y completar la documentación que exista.
Escribir casos de uso si no existen, eventualmente completarlos.
3. Extender los casos de uso para facilitar la prueba, identificando las variables que alteran el comportamiento del sistema, y los diferentes estados y respuestas del sistema. Darán lugar a las variaciones, precondiciones y resultados esperados de los casos de prueba a generar.
(En el libro puede encontrarse bastante detalle y ejemplos sobre cómo extender los casos de uso y cómo crear los casos de prueba a partir de los casos de uso extendidos).
4. Generar los casos de prueba esenciales, positivos, negativos e inesperados, a alto nivel.
5. Mapear requerimientos <-> casos de uso extendidos <-> casos de prueba. Esto permitirá proveer trazabilidad, que es un requisito en general en proyectos que deben cumplir regulaciones.
6. Diseñar los casos de prueba detallados, lo que implica definir las necesidades de ambiente, los participantes o actores, y los procedimientos de prueba que permitirán ejecutarlos y analizar su resultado.
7. Ejecutar los casos de prueba. Lo que implica: disponer de una entrega del producto que funcione mínimamente y de un ambiente donde ejecutarlo; saber cómo ejecutar los casos y evaluar sus resultados; entender si aplica hacer alguna prueba de regresión; entender qué puede automatizarse y qué requiere pruebas manuales.
8. Registrar los resultados de las pruebas; evaluar cuándo finalizar; reportar estado de las pruebas.
Los resultados pueden expresarse en cantidades de defectos, relaciones de sus severidades, cómo y cuándo se resuelven, etc.
Respecto a finalización, tener en cuenta que “una pintura nunca está terminada”, y las pruebas tampoco. El criterio de finalización tiene que estar relacionado con las expectativas y necesidades de los interesados, y habitualmente se expresa como una combinación de defectos bajo un cierto nivel + cobertura sobre un cierto nivel.
Qué reportar y cómo depende de a quién se informa. Básicamente se informa sobre estado del producto (resolución de los defectos detectados) y estado de la prueba.
El estado de la prueba puede mostrarse vía trazabilidad (desde las necesidades o requerimientos a los casos probados y los defectos encontrados) y cobertura (respecto a los requerimientos o cobertura de diseño, y respecto al código ejecutado, o cobertura de código).
Mis opiniones
El libro describe de manera amena y siguiendo tres ejemplos, lo que el autor define como testing esencial y ágil, y cómo puede aplicarse en diferentes contextos y tipos de proyectos.
Particularmente me resultaron muy interesantes a nivel conceptos generales los capítulos 1, 4, 5, 6 y 8.
Considero que los capítulos 9 a 19 pueden leerse independientemente, en función al tema que nos interese profundizar en un momento dado; por otra parte, creo que es valioso y útil lo descripto en capítulos 13 (cómo extender los casos de uso), 14 y 15 (cómo identificar y describir los casos de prueba), pero no siempre es posible hacerlo en los proyectos al nivel de detalle planteado por el autor. Seguramente se pueden tomar ideas y adaptar a las restricciones de cada proyecto en particular, y enfocar más el análisis de riesgos de lo que propone Fournier (que pone foco en muchos aspectos de cómo hacer más ágil el testing para productos altamente regulados).
El capítulo 20 es un buen resumen del proceso esencial de testing propuesto, mostrado vía un ejemplo.
Coincido totalmente con lo expresado por Fournier en el final del capítulo 21 de su libro:
“I was going to start the concluding chapter with a story about
a group of testers that were proactive in everything they did,
saved projects, and were highly regarded by everyone.
Then I figure, why lie?
Much of the premise of this book relates to being proactive
and taking our destiny in our own hands as much as possible.
That means that, when we test, we will step on toes.
Although we can try to minimize the number of toes we step on, there
will always be some animosity generated and our efforts will
never be fully appreciated.
Accepting that takes courage.”
"Yo iba a empezar el último capítulo con una historia sobre
un grupo de testers proactivos en todo lo que hicieron,
que salvaron proyectos, y que fueron considerados muy positivamente por todos.
Luego pensé, ¿Por qué mentir?
Gran parte de la premisa de este libro se refiere a ser proactivo
y tomar el destino en nuestras propias manos tanto como sea posible.
Eso significa que, cuando se prueba, pisaremos muchos dedos.
A pesar de que podamos tratar de reducir al mínimo el número de dedos que pisamos,
siempre se generará cierta animosidad y nuestros esfuerzos nunca se apreciarán plenamente.
Aceptar esto requiere valor. "
Espero este resumen les resulte de utilidad, y los invito a discutir el tema, si les interesa, en el Grupo de Linkedin “Mejora de Procesos de TI” http://www.linkedin.com/groups?home=&gid=2603073&trk=anet_ug_hm
¡Que lo disfruten!
No hay comentarios:
Publicar un comentario