La calidad es siempre negociable

La calidad es negociable y en Agile es tan negociable como que la misma es escalable y varia indudablemente con cada iteración, a medida que una historia de usuario emerge como un motor de trabajo para el equipo.

Que “La Calidad No Es Negociable”  lo he leído inclusive en el famoso libro “scrum-y-xp-desde-las-trincheras”, pero queda claro allí que podemos hacer distinciones entre cosas que pueden evolucionar desde diseños y modelos básico, hasta un entregable de avanzada, y cosas que necesariamente deben tener un grado de calidad mínimo y suficiente para garantizar trabajos futuros.

Entre ambas cosas, podemos distinguir para el primer caso, interfaces en general, botones, comandos, scripts, webservices y hasta funciones que son implementadas como soluciones de base y pueden evolucionar completamente en futuras iteraciones. Para el segundo caso, nos referimos a elementos de diseño y arquitectura que mal implementados atentan contra factores de calidad como la mantenibilidad, modularidad, escalabilidad, seguridad, integridad, disponibilidad, etc., e inclusive contra la testeabilidad.

En Agile tenemos presente que la potestad de la calidad la tiene todo el equipo de trabajo y no un “grupo de QA” y para un mejor aseguramiento, preferimos el “testing temprano y colaborativo”, el que nace desde el primer día en que se conversa con dueños de productos (PO), Analista de Negocios, usuarios y otros interesados, el que continúa en nuestras mesas de análisis y continua con las decisiones del equipo y que facilitan que cada involucrado pueda agregar valor a favor de un desarrollo de calidad.

Un principio que sostenemos y nos ayuda en esta cadena iterativa y evolutiva de la calidad del software, es que los equipos Agiles no se dividen en Desarrolladores y Testers (aún cuando hay especialistas en ambas cosas), sino que se mancomunan en la figura de Team Members.

En Agile sabemos que una actividad de testing, exhaustiva o no, al final de la cadena de desarrollo no aporta calidad, aún cuando pueda dar índices y métrica.

Sin embargo esto que suena tan lindo, de ninguna manera se obtiene en los primeras iteraciones, sino que en futuros Sprint, el esperado de calidad comienza a tomar la forma negociada. En nuestras discusiones de proyecto, constantemente evaluamos alguna posible falta de funcionalidad o funcionalidad pobremente desarrollada y la enorme mayoría de la veces, se logra determinar que mientras futuros Sprints darían la cobertura esperada, en el actual contamos con una calidad “lo suficientemente buena”, sin descartar que en cada Sprint finalizamos y demostramos un incremento “potencialmente entregable” Utilizamos un concepto que se llama “good enough quality”, lo cual nos da los límites suficientes y necesarios para el testing que aplicaremos en cada nivel del desarrollo. Lo más importante, negociamos con el PO el grado de calidad de cada incremento.

Puedo decir  a estas alturas de mi experiencia, que cada vez más, y más empresas de cualquier envergadura  migran a Agile, inclusive para sus productos más críticos. Ya lo se, las empresas maduras no buscan “la bala de plata” pues ya saben que no existen, y quien adopte Agile o cualquier otro framework por moda solo está destinado al fracaso rotundo, de hecho atribuyo el fracaso de CMMI a la tendencia fashion de quienes consiguieron una evaluación positiva y luego encajonaron el proceso.

Justamente, sucede que hasta el día de hoy no han podido lidiar con los tiempos de respuesta exigidos cada vez más cortos, los cambios de requerimientos cada vez más demandantes y mayor diversidad de servicios asociados a productos, por lo que vienen dejando enormes “huecos de calidad” que sus metodologías tradicionales facilitan.

No intento debatir sobre metodologías, pero si tal vez un paradigma y éste que a muchos trato de explicar nos dice que “la calidad es siempre negociable”, pero podrás con esta negociación o no, dependiendo de tu paradigma de gestión de proyectos y mucho más que eso, dependerá del paradigma cultural de las organizaciones.

Por eso podremos ver que los managers se entorpecen en intentar modificar sus procesos para adecuar sus organizaciones a las nuevas corriente, pero al carecer de los principios correctos del paradigma al que intentan imitar, solo logran confundir a su plantel y no pasa mucho tiempo en que prefieren retroceder debido a los intensos fracasos.

La evolución es para todos, para algunos de una forma, para otros de otra forma, pero bueno, insisto, no se puede tener cuerpo sin espíritu.

calidad

Advertisements

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.

"Gestión del testing" – Próxima reunión de la Comunidad AGILE Córdoba

El testing de software es una actividad que no detiene su crecimiento y sin importar el contexto en el que se desarrollen aplicaciones o sistemas, el testing es uno de los pilares fundamentales para el aseguramiento de calidad.

Sin embargo, aunque muchos aprendieron a hacer testing en distintos niveles, un gran dilema es, cómo en las metodolgías Agiles podemos organizar un proceso de testing sabiendo de los muy cortos plazos del proceso de desarrollo y con muy bajas posibilidades de realmente hacer aseguramiento de calidad.

Muchos proponen la automatización hasta en sus más mínimos detalles, desde el requisito hasta la aceptación, pasando por el código, la integración y quizás el testing funcional.

Personalmente creo que el testing por si mismo, aunque está ligado a la automatización, no necesariamente está ligado al aseguramiento de la calidad y todo caso ambos, testing y calidad están ligados al factor escencial que es la comunicación.

Sin ir más allá quisiera referirme a un artículo anterior en este mismo blog donde expreso lo siguiente:

con respecto a Testing-Agile James Bach nos dice:

“… cuando di con Agile-Testing encontré un punto de vista desde los desarrolladores que descubrieron Agile y pensaron que esto se trataba de automatizarlo todo y eso es lo que hacen. Por lo tanto solo hablan de herramientas y herramientas y mencionan todas las que conocen.
O lo que realmente significa es, hagamos ingeniería utilizando las habilidades para testar rápidamente las cosas realmente importantes, de una forma sistemática y organizada. El nucleo principal de Agile-Testing se llama SKILLS…………………………………….. la automatización es importante, pero no confundamos Testing con herramientas.

Testing no se trata de herramietas, sino de humanos que pueden hacer algo con las herramientas.”

De mi artículo AGILE con ‘a’ y con ‘A’

Próxima reunión: Jueves 2 de septiembre, 18:30 hs.
Sede:  INTI Córdoba, Av. Vélez Sársfield 1561 (frente a Plaza De Las Américas)

Nota Importante:

  • Por razones de seguridad en sede y espacio, inscribirte para participar
  • Debido a la naturaleza de la actividad, rogamos ser puntuales para facilitar la organización y poder participar y aprovechar los juegos en su totalidad.

Visual Studio Team System 2010 y sus nuevas caractarísticas para Testing

Microsoft no deja de sorprender con sus vistosos paquetes de sistemas para toda clase de entornos. Ahora se dispone a liberar su Visual Studio Team System 10 y lo primero que me llamó la atención, fueron las nuevas características de automatización del testing  para Interfaces de Usuario Final (UI).
En esta difusión vemos un claro ejemplo, aunque demasiado sencillo, de como es posible automatizar la mayoría de los aspectos relativos a pruebas sobre las interfaces de usuario. La suite escribe todo el código necesario y solo nos resta agregarle la inteligencia suficiente y necesaria para ampliar la batería y mejorar la cobertura.

Otro aspecto importante de este potente paquete es la disponibilidad de herramientas VSTS para el Aseguramiento de Calidad del Software, más allá de los aspectos relativos a solo testing.
Microsoft provee en este conjunto, herramientas orientadas al TESTER sin pretender que el mismo sea un desarrollador en potencia, ni que el desarrollador ejecute testing funcional.
Se promete un entorno rico y colaborativo donde diseñar las pruebas desde el principio sea posible, escribir los casos de pruebas sea bajo un lenguaje unificado y cotidiano, ejecutarlos sea acorde a la capa para la que se diseñó , reportar defectos, priorizarlos, resolverlos y verificarlos, se harán en un único hilo de proceso, de una manera sencilla y única que permita derribar cualquier barrera comunicacional entre desarrolladores y testers.
La propuesta es un único entorno de trabajo orientado al objetivo del negocio.

Lo agradable, desde mi punto de vista, es la promesa de que a pesar de la potencia de la suite para promover la automatización de todo el conjunto de pruebas en todos los niveles del ciclo de desarrollo, en realidad viene a promover la “ingeniería de las pruebas manuales”, pero potenciando aspecto relacionados al diseño de las pruebas, planteos de casos documentados, mejora en el manejo de cambio de requerimientos y el impacto en las pruebas.
De este modo las pruebas son controladas y se disminuye el alto grado de aleatoriedad de las pruebas manuales controlando los diferentes escenarios diseñados.

Y para finalizar, les dejo un pequeño ejemplo de como hacer Testing Unitario para código de dispositivos móviles con Visual Studio Team.
En realidad solo quería decir…Aguante la calculadora !!!!

¿Que hace un SQA?

Es responsable de asegurar la calidad de los productos generados en el proyecto y del proceso utilizado. Para asegurar la calidad debe revisar la calidad de los entregables de planificación del proyecto y los entregables de valoración del proyecto. Además revisa el nivel de apego al modelo de proceso de desarrollo de software y a los planes de Verificación, Gestión de Proyecto y Gestión de Calidad, documentando las desviaciones encontradas.

Debe conocer los conceptos y técnicas de Gestión de Calidad del Software. Debe identificar las propiedades de calidad que deben cumplir los productos del proyecto.

Centralizar y revisar las entregas que se realizan durante el ciclo de vida del proyecto.

Realiza las Revisiones Técnicas Formales con los responsables de los productos a revisar.

El Responsable de SQA debe:

  • Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo

  • Asegurarse de que se realicen estudios de factibilidad

  • Realizar mediciones para comprobar la calidad del proyecto

  • Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos

  • Evitar el desperdicio de esfuerzo en conjunto con el Administrador y el Arquitecto

  • Registrar las métricas de aceptación tomando en cuenta el Documento de Validación con el Cliente.

Perfil del rol

  • Debe conocer los requerimientos del sistema.

  • Debe conocer los estándares o lineamientos del proyecto para asegurar la calidad.

Actividades que son responsabilidad del rol

  • Planificar la Calidad

  • Revisión Técnica Formal (RTF)

  • Revisar las Entregas

  • Revisar el Ajuste al Proceso

  • Evaluar la Calidad de los Productos

  • Realizar el Informe Final de Calidad

Entregables que son responsabilidad del rol

  • Plan de Calidad

  • Informe de RTF

  • Entrega Semanal de SQA

  • Informe de Revisión de SQA

  • Informe Final de Calidad

Actividades en las que está involucrado el rol

  • Relevar los Requerimientos

  • Especificar los Requerimientos

  • Priorizar los Requerimientos

  • Validar los Requerimientos

  • Validar con Prototipo

  • Definir el Alcance del Sistema

  • Definir la Línea Base del Proyecto

  • Planificar el Proyecto

  • Describir la Versión

  • Planificar la Transición

  • Seguimiento de Satisfacción del Cliente

  • Gestión de Riesgos

  • Registrar Esfuerzo

  • Auto estudio

  • Reunión de Equipo

  • Preparar Cierre del Proyecto

  • Reunión Conmemorativa


Obtenido de MUM