QA-Testing en SCRUM

Estimado tester del mundo,

Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

“¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3), o dos (1), serán mitad de desarrollo y mitad de testing? ¿como se gestionan los defectos en tiempos tan acotados? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuar codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

NO ME QUEDAN CLARO LOS CICLOS!!!”

 

 

 

 

 

 

 

 

Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros en tantos años de vida de Agile. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y te aseguro que en SCRUM no está estipulado como es el proceso de testing y calidad. Pero eso está bien por cuanto Scrum no es prescriptivo hasta el punto de definir “cómo hacer el trabajo” del equipo.

Leí varios libros sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

Alguna respuesta lógica podría ser:

  1. la intervención temprana del equipo de testing en el ámbito del proyecto.
    Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas por adelantado. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos (la cual es mayormente deseada en los negocios actuales), como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos (inclusive dentro del Sprint en curso).
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando la historia del usuario es expuesta al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
    Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
  2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
    Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
    Estas herramientas ayudan a…
  3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

En relación a tus preguntas te diría que:

  • Tres semana de desarrollo y uno de testing es posible, pero es mejor dejar de pensar en fases tan marcadas. Que opinas de colaborar todo el tiempo con lo que sabes, con lo que entiendes? Seguramente será más beneficioso para todos en términos de “descubrimiento de la feature” y/o “descubrimiento del product”, si te involucras y con tus opiniones generas mínimamente dudas.
    No considerarías a esto mismo TESTING?
  • ¿Tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional. Lo que puedes hacer sabiendo que cuentas con los recursos necesarios y adecuados (interación plena, coordinación y colaboración, pero principalmente la involucración), es gestionar de un modo colaborativo, es decir con la opinión de todos a tus sugerencias y propuestas de planificación, así probablemente ya no existirán más los clásicos problemas de “responsabilidad de un rol”, porque el resultado será algo funcional a todos y generado por todos.
  • Mientras se hace testing los desarrolladores codifican y mientras reportas fallos, ellos corrigen, al rato lo verificas. Para eso está el trabajo en equipo, solo hay que consensuarlo y organizarlo.
    Aunque está mal visto en los paradígmas tradicionales, los desarrolladores serán eventualmente los mejores testers; puedo asegurar que visto que es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo en general, no solo a QAs.
    En el mismo iterín, los desarrolladores también adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
    Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
    Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
  • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
  • La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos.
  • Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
    También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
  • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento, va ligado de la frase “está hecho!!!”.
    Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Para que esto no quede con un amargo sabor, te paso este enlace que podrá al menos darte una idea de como iniciar, pero te repito, aprende por tu cuenta pues no hay recetas.

Advertisements

El impacto de las redes sociales en Argentina

Argentina se encuentra liderando el acceso y participación de las redes sociales, aún cuando España es el país que recientemente mas integrantes a sumado a este fenómeno Web 2.

image

El fenómeno de la creciente participación en las redes de enlace social, está relacionado principalmente por la necesidad de recupero de comunicación interpersonal, muy probablemente ligado a la gran dispersión de las personas al rededor de todo el mundo. Estos medios son la herramienta ideal para localizar y contactar a personas a las cuales se les ha perdido el rastro.

Otro motivo no menos poderoso para el uso de herramientas sociales, tiene que ver con búsqueda de trabajo y relación profesional o comercial, donde nuevas oportunidades se abren en dos frentes, tanto para quienes buscan un nuevo puesto de trabajo como para quienes buscan nuevos prospectos. Del mismo modo para quienes tienen relaciones de negocios en algún grado.

Es interesante notar que lo que aparentemente tiene un impacto de corto alcance, en realidad tiene un alcance inimaginable, tal es así que con solo tener unos cuantos contactos directos o de primer nivel, se genera una red de contactos que se disgrega por múltiples regiones del mundo, logrando así disponer de una red verdaderamente amplia, donde localizar a una persona, buscar trabajo, mano de obra califica o promocionar un producto, es mucho más simple y veloz, por no hablar de los costos que aún pagando, tienden a cero.

Aún no hemos visto más que los inicios de las redes de la Web 2 y los servicios comienzan a escalar para brindarnos capacidades multimedias, aplicaciones de planificación de proyectos globales, coordinación de equipos distribuidos, ambientes colaborativos, soporte de archivos, voice mail, chat y poderosos monitores de estadísticas que nos ayudan a tener mayor visibilidad y definición de los rumbos a tomar.

No me atrevo a especular sobre todo lo que aún nos deparan estos avances, pero sin duda estamos en un proceso de aprendizaje y adaptación, el cual cada vez es más rápido, tiene más adeptos y el feedback es instantáneo, hasta el punto tal que en cuestión de horas las aplicaciones OnLine perfeccionan sus funcionalidades y potencian sus servicios.

OpenSpace

Durante los últimos 15 años, claramente se ha ido percibiendo como el Espacio Abierto puede crear organizaciones inspiradas, donde personas normales trabajan juntas para crear resultados extraordinarios con regularidad.

face to face meeting

¿Qué es?

La Tecnología de Espacio Abierto es una forma de permitir a toda clase de personas, en cualquier tipo de organización, crear reuniones y eventos que inspiran.

En reuniones, eventos y organizaciones, de Espacio Abierto, los participantes crean y manejan su propia agenda, de trabajos y sesiones simultáneas, en torno a un tema principal de relevancia estratégica, tal como: ¿Cuál es la estrategia, el grupo, la organización o la comunidad que los “stakeholders” pueden apoyar y trabajar en conjunto, para crear?
El resultado es poderoso y efectivo a la hora de implementarlo y ayuda a apoyar lo que ya está sucediendo en la organización, no sólo planeando sino actuando, aprendiendo y enseñando, con pasión y responsabilidad, siendo no sólo participantes sino ejecutores.

¿Cuándo y Por Qué?

El Espacio Abierto funciona mejor cuando el trabajo que se debe realizar es complicado, las personas y las ideas que están involucradas son diversas, la pasión por resolverlo (y potencial para conflictos) es enorme, y el tiempo para realizarlo “era ayer”.

Es llamado “pasión limitada por la responsabilidad”, “la energía de un buen coffee break”, “auto-organización intencional”, “espíritu en el trabajo”, “caos y creatividad”, “evolución en la organización”, y una forma poderosa y sencilla de hacer a las personas y a las organizaciones moverse cuando y donde es más necesario.

Y mientras que el Espacio Abierto es conocido por su falta de estructuración y abierto a sorpresas, resulta ser que los eventos u organizaciones de Espacio Abierto son, de hecho, muy estructuradas, pero esa estructura es tan perfectamente diseñada para las personas y para el trabajo diario, que pasa desapercibida en sus roles de dar apoyo (no obstaculizar) a un trabajo mejor realizado.

Aún más, las historias y trabajos que se realizaron en Espacio Abierto son generalmente más complejos, más fuertes, más duraderos, y se pueden mover de manera más rápida y ágil que trabajos realizados por expertos o bajo los diseños administrativos convencionales.

.

¿Cómo se estructura?

Cuando se abre un Espacio Abierto para un grupo de personas, para que realicen su trabajo más importante, se debe garantizar estos resultados:

1. Todos los puntos considerados como los MÁS importantes para los participantes, serán tratados;

2. Todos los puntos que surjan serán sugeridos por los participantes más calificados y capaces de lograr algo en cada uno de esos puntos;

3. En un período tan corto como uno o dos días, todas las ideas, discusiones, informaciones, recomendaciones, conclusiones, preguntas para discutir y planeamientos más importantes, serán documentados en un reporte muy fácil de entender, impreso y entregado en las manos de los participantes en el preciso momento que ellos se marchan;

4. Cuando el momento sea apropiado para esto, el contenido de este reporte puede priorizarse en pocas horas, aunque se esté trabajando con grupos grandes (100);

5. Después de un evento, todos estos resultados pueden ponerse a disposición de toda la organización o toda la comunidad, sin necesidad de realizar el evento, ya que conversando se puede invitar a los “stakeholders” en la implementación, justo en el mismo momento;

6. Y resultados como estos pueden ser planeados e implementados más rápido que cualquier otro tipo de “intervención para grupos grandes”. Es literalmente posible obtener en días y semanas lo que cualquier otro tipo de técnica dura meses y años.

Las buenas y malas noticias es lo que funciona. Buenas noticias porque hace que las personas y el trabajo se muevan, malas noticias porque puede significar que muchas cosas pueden llegar a cambiar. Cosas que uno desea, aparecerán y cosas que uno no desea, desaparecerán, y en algunas ocasiones vice-versa-pero así es como la vida funciona. En resumen, el Espacio Abierto trae vida a la organización y trae a las organizaciones de vuelta a la vida.

Estráido de OpenSpaceWork