sábado, enero 30, 2016

Acomodando o Forzando Scrum para Equipos de Testing


Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.


------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),
y la empresa “Y” lo prueba y certifica


Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

  • un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
  •  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –
dice: “yo voy a probar usando Scrum”


¡ ¡ ¡OMG!!!


Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:
  • Planeación
  • Ejecución
  • Revisión
  • y Retrospectiva
Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:
  • El Product Backlog es todo lo que hay que probar
    • Casos de uso
    • Historias de usuario
    • Requisitos no funcionales
  • El sprint backlog
    • Es lo que se selecciona a probar durante el ciclo
  • El team es un equipo de testing
  •  Product Owner y Scrum Master conservan sus definiciones.
Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características
  • Todos los casos de prueba de la HU o del CU diseñados
  • Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
  • Reporte de incidencias encontradas actualizado.
Y la DEFINITION OF READY:
  • Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
  • Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:
  • Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
  • Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.



Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.
**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)

No hay comentarios.:

Publicar un comentario