Exploratory Testing: Olfato e intuición amplificada

Fortalezas y debilidades de las Pruebas Exploratorias

Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

Para esta práctica son necesarios ciertos elementos que le anteceden:

  • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
  • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
  • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
  • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
  • Conocimiento y dominio del negocio al que pertenece el problema
  • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
  • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
  • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
  • Olfato e intuición amplificada

Hay que considerar que para el éxito de esta técnica se utilizarán las definiciones que se hacen a nivel de Historias de Usuario y/o Requerimiento,  para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas para verificar que el sistema no haga lo que no debe hacer.
Es decir que básicamente la información disponible conforman nuestros Scripts de ejecución y también evidencia de funcionalidad.

Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar inicialmente en la fase de desarrollo y manifestarse en las diferentes integraciones de los sistemas, más no pretender que las pruebas exploratorias indiquen que las funciones del sistema funcionen correctamente, sino entender que el concepto es en si mismo, la detección de fallos y errores.

Advertisements

Pay per Defect o elevar la conciencia creativa del acto verificador?

Un amigo posteó:

¿Como creéis que se debe incentivar a los equipos de calidad? ¿Es posible incentivar por defecto encontrado o es contraproducente?

Imaginemos una compañía que decide incentivar por objetivos, e incentiva el equipo de desarrollo por funcionalidad implementada en el menor tiempo. ¿Como incentivamos al Tester? o dicho de otra manera como sabemos quién realiza mejor labor de verificación?

Una respuesta de otro amigo:

Pues yo creo que incentivar la localización de errores está bien.
Eso sí, debe haber un “juez” que decida si cada caso es digno de contabilizar o no, es decir, que tome la decisión en los casos dudosos (“es que no estaba en los requisitos escritos” … “sí, pero es algo ‘obvio'” … y cosas de ese estilo). Ah! Y añado otra cosa : igual que se incentiva la localización de errores en el testeo creo que se debería “desincentivar” cuando un Cliente localiza el error una vez lanzada la versión.
Luego se hacen las cuentas de la vieja y se saca balance.
Ya verías la de errores que se encuentran !!! jejeje

El aporte de uno más:

¿Qué tal un esquema intermedio?

1) Incentivar a los desarrolladores con relación inversa al número de defectos que “les” encuentren los Testers.
2) Incentivar a los Testers con relación al número de objetos/unidades/loquesea que pasen a producción validados
3) E incentivarlos a todos con la “velocidad” del proceso completo, y con relación inversa a los defectos encontrados en producción.

La “fórmula” no sería sencilla, pero puede que se lograse un resultado adecuado. ¡O que se lograse confundirles a todos!

Pero mi opinión fue la siguiente:

Me resulta un poco extraña la cuestión de tener que incentivar a un Tester o grupos de Testers por tener que hacer su trabajo bien. Igual para los desarrolladores o cualquier otra persona que cumpla un rol específico dentro de la cadena productiva de software.

Es cierto también que al principio el Tester se haría de una muy buena suma de dinero extra por la cantidad de detección de fallos y conforme avanzan los ciclos, deberá devolver dinero y hasta poner de su bolsillo por que no encontrará fallos que se sabe por métricas, están allí.

Dependiendo del entorno de trabajo, la suspicacia de las personas, los objetivos personales de cada integrante del equipo de Testers entre otros elementos, es bueno aplicar criterios de competencias operativas., pero en otros casos no. Equipos enteros podrían desintegrarse por generarse ciertas incomodidades. No quiero ni hablar de como impactaría sobre nuestros productos.

Quizás es bueno tener ciertas métricas como, cantidades de defectos detectados por Tester, pero no podríamos evitar entrar en comparaciones odiosas y mirar que tipo de defectos detecta cada uno de ellos y como es el impacto de cada uno de esos defectos detectados en los proyectos.
Tal vez este tipo de mediciones solo servirían para que en caso de necesitar dividir el equipo de Testing, al “mejor Tester” se le asignaría una especie de “jefatura” sobre otros que no tienen el mismo rendimiento. Pero que aporta a la calidad en si mismo? tal vez poco o nada.


A las buenas del Tester?

Los Testers suelen encontrar fallos de severidad Invalidante o Graves a penas inician el Testing. No es mérito del Tester sino de la incompetencia de alguien en fases anteriores. No señalo a nadie, pero desde el Tester para atrás, hay muchas responsabilidades intrínsecas.

Me gusta mucho la idea de incentivar, pero sin generar competencias sino creando ambientes colaborativos (inclusive para eso estamos aquí nosotros) y cada uno en su puesto de trabajo debe elevar al máximo su responsabilidad (habilidad de respuesta).

Por lo tanto considero que verificaciones y/o validaciones no puede quedar librado a la buena de un Tester, sino que debe guiar a cada uno de los involucrados en el proceso hacia los resultados esperados, también sus controles y gestiones.
Así, si se considera la existencia de Testers en un equipo de desarrollo de software, tal como sucede actualmente en los equipos Scrum, no debería quizás quedar fuera de la supervisión de Responsables QA y permitir que la carga de gestión recaiga sobre los hombros de tal o tales personas.

Lo que se puede hacer es, “elevar la conciencia creativa del acto verificador” agregando capacitaciones especializadas en herramientas, técnicas, modelos y patrones de calidad, invirtiendo en el aprendizaje de conceptos avanzados y modelando nuevos modos de hacer testing y demás elementos que existen para sumir al equipo de desarrollo entero en un estándar que desde el llano y como punto de partida sea muy alto.

Entonces, presumiendo un equipo maduro, consciente y capaz, presumiremos que todos los defectos del producto fueron eliminados y en relación directa, un producto de alta calidad. Ahora a generar retorno de inversión.

Cierta oportunidad siendo Líder de Testing al finalizar uno de los proyectos postulados para certificación CMMI-4, mi equipo detectó grandes cantidades de fallos en los productos solo en los primeros ciclos, cuando había planificados 12 ciclos de pruebas. Conforme se comenzaron a resolver los fallos, previo a los ciclos subsiguientes, nuestra tasa de detección cayó significativamente para el resto de los ciclos (considerar PARETO).
Esto me llevo a analizar la situación, a modificar definitivamente el modo en que manejamos los ciclos.

Finalizado el proyecto que menciono, invité a mi equipo a un almuerzo y por supuesto al equipo de Desarrollo. Allí pude explicar lo que habíamos conseguido trabajando en equipo y como unos sin otros no pueden evidenciar su actividad hecha con responsabilidad. Gracias a esto pudimos mejorar nuestro proceso en forma significativa.

Creo en definitiva, que brindar las herramientas adecuadas, la capacitación necesaria y sostener un ambiente colaborativo y ameno, son los mejores incentivos.

Es cierto también que al principio el Tester se haría de una muy buena suma de dinero extra por la cantidad de detección de fallos y conforme avanzan los ciclos, deberá devolver dinero y hasta poner de su bolsillo por que no encontrará fallos que se sabe por métricas, están allí.

Cómo ven que a los productos de software desarrollado por un equipo Agile sean probado (testeado) por un equipo no Agile (tradicional)?

No es una locura, pasa bastante seguido. Piensen en un cliente que contrata una empresa de desarrollo Agile o varias de ellas para distintos productos y los pre-releases son enviados a otra organización diferente para el testing de sistema donde se corren exaustivamente distintos tipos de pruebas, como usabilidad, bases de datos, performance, seguridad (autenticación/ autentificación), etc.

Esta discusión la abrí hace 20 días en el grupo ScrumMaster de Linkedin y aún tiene una interesante participación, con variadas opiniones expuestas por los distintos miembros del grupo.

Lo primero que pude notar es que este planteo del testing realizado por un equipo NO AGILE a un producto desarrollado por un equipo AGILE, es algo que en realidad no viene a ser muy común en el mundo del desarrollo del software. Al menos puedo tomar esta deducción en base a que no muchos se animaron (en relación con otros debates) a participar y a su vez, los que participaron, no ofrecieron muchas variantes, desde el punto de vista de experiencias reales con este formato que propuse.

Desde una perspectiva defensiva hacia el equipo Scrum pareciera ser importante evitar a toda costa la irrupción de parte del equipo de testing al equipo de desarrollo y es entonces cuando el verdadero desafío tiene que ver en como resolver situaciones en la que se detectan errores de severidad alta, que tienen estrecha relación con el trabajo “ya finalizado” y requiere modificaciones importantes o cambios en las características originales desarrolladas en Sprints anteriores.

Dicho de manera gráfica, si el equipo independiente de testing detecta issues debe tener en claro que bajo Agile, lo que el equipo de desarrollo ya liberó, no puede ser modificado y cualquier mejora o cambio, requerirá de la introducción de nuevos elementos al backlog del producto y la gestión correspondiente.
Entonces una solución podría ser que el pre-release existente se transforma en un pre-release con issues conocidos y se refleja en las notas del incremento.

Pero que sucede en escenarios en los que el cliente entrega la potestad al equipo de testing independiente, de determinar si el producto se puede liberar o no.

Es sabido que hay organizaciones que exigen que sus productos críticos sean evaluados para la superación de ciertos criterios de calidad a los cuales llaman “Portales de Calidad”, los cuales solo pueden ser superados por el equipo de testing siguiendo los tradicionales planes de calidad y testing de proyectos también tradicionales. Esta situación sin duda pone en una posición precaria al equipo de desarrollo Agile, políticamente hablando.

Desde el punto de vista de Agile, se podría plantear también que mientras el equipo de testing se concentra en registrar issues de iteraciones pasadas, el equipo de desarrollo se concentra en generar un nuevo incremento funcional de valor para el cliente y cabe la posibilidad de que la resolución de la mayoría de los issues detectados por testing, carezcan de algún valor para cliente en Sprint posteriores.

Diferencias metodológicas

Un punto muy importante a considerar es la gran diferencia metodológica del proceso de testing entre un equipo de Testing-Agile y un equipo de Testing-Tradicional. Mientras que los primeros cobran vida y sentido en las mismas fases del desarrollo del producto (para este ejemplo en particular) los segundos tienen sentido cuando el producto ya existe y debe ser evaluado.
Metodológicamente hablando, el Testing-Agile no sería tan exigente en cuanto a la documentación requerida para realizar las pruebas de software, no exigiría un plan detallado, ni evidencias basadas en casos de pruebas del tipo script ejecutadas en determinados ciclos, ni pedirá métricas del testing.
En contraposición, el Testing-Tradicional sería exigente en todos esos aspectos y muchos más para determinar la cobertura de pruebas y calidad para el productos. También habría un plan detallado y varios puntos de control a respetar exaustivamente.

Variaciones de esta naturaleza, exige la comunicación entre ambos equipos y la consiguiente negociación para facilitar los hitos de liberación.
Dicho de otra forma, la colaboración del equipo Agile puede no ser una responsabilidad contractual, pero si es una necesidad imperiosa que el equipo Agile proporciones principalmente su know-how del dominio.

Y por otro lado considero una gran responsabilidad para con el mismo equipo de desarrollo, favorecer que sus creaciones sean correctamente interpretadas y evaluadas. No cabe la posibilidad de un desentendimiento o el mismo trabajo ya “hecho” fracasará por la sola falta de colaboración entre equipos.

Factores que atentan al testing automatizado

Antes que nada, voy a respestar a otros blogers que en sus blogs llevan nombres similares:

http://josepablosarco.wordpress.com/2010/06/02/factores-que-atentan-contra-las-pruebas-automatizadas/

http://testingbaires.com/?p=749

Algunos nos dicen que los siguientes factores son los que atentan contra la posibilidad de automatizar efectivamente las pruebas de software:

  • Falta de testers que sepan programar, en varios lenguajes y con experiencia en automatización.
  • Desarrollos que no siguen prácticas de diseño que facilitan la automatización de las pruebas y su reusabilidad en el tiempo.
  • La falsa creencia de que la automatización de pruebas solo se realiza a nivel de GUI.
  • Dependencia en herramientas que no son la panacea de la automatización.

Otros disparan contra los mismos clientes quienes expresan gran interés en automatizar el proceso de pruebas y tienen muy altas expectativas en ello sin saber realmente si posible por parte de sus proveedores, brindar un servicio tan específico

Algunos remarcan como algunos conceptos erróneos  se establecen en el mercado:

  • Es fácil sólo hay que grabar los test manuales
  • Es el trabajo de los Testers el automatizar los test
  • Podremos reducir el número de Testers en cuanto tengamos la herramienta
  • Somos ágiles ahora los desarrolladores harán esto

 

Fuera de foco

Desde mi punto de vista, considero que la falta de enfoque es el primer factor en contra del Automation Test.
Las personas que deben pensar esta materia con un enfoque estratégico dentro de una organización, suelen cometer varios errores fatales.
Un error típico suele ser el de intentar automatizar solo algunos aspectos, por ejemplo, solo el código y se relegan otros niveles de pruebas.
Un error similar pero contrapuesto, es el de intentar automatizar todo, desde el requerimiento hasta la prueba de aceptación y mucho más allá.

Con cualquiera de estos enfoques sumado una baja asignación de recursos (horas, equipamiento, proyecto) y sin un proyecto acorde, lógicamente a muy corta data se fracaza.

Creo que esto es así por los “Buzzwords” que al final de tanto sonar generan tendencias erróneas y también por aquello de que aún no se sabe que es la calidad y que es el testing y todo eso que tanto discutimos en los foros.

Conociendo nuestras necesidades

Las organizaciones primero deben conocer sus necesidades, ligarlas con sus posibilidades y limitaciones, establecer los objetivos específicos que persiguen con la automatización (más calidad y menores costos, disminución de riesgos, entendimiento de los sistemas, generación de oportunidades de mejora), para luego establecer pautas para la creación de una arquitectura de automatización.

Un ejemplo costoso

Si solo consideramos la automatización de pruebas de sistemas para un sistema ya existente, podríamos pensar en un modelo que finalmente se parece mucho a los aplicados actualmente por las organizaciones que intentan migrar rápidamente a un modelo de automatización para pruebas de pre-release.

Bajo este modelo, la automatización se hace en paralelo al ya existente juego de pruebas definidas para la ejecución manual. La estrategia consiste en reemplazar paulatinamente las pruebas manuales que dan cobertura a determinadas características, por pruebas que a futuro serán plenamente automaticas.

En muchos casos, el esfuerzo ha sido tal que los ciclos futuros de pruebas de regresión ya cuentan con un modesto juego de pruebas automáticas y actualmente son seleccionables para ciclos que corren en paralelo al ciclo de pruebas manuales, siendo éstas últimas un validador de los resultados de las primeras.

Sin embargo esta forma de hacer las cosas tiene costos que son dificilmente posibles de encarar y sostener por cualquier tipo de organización.

Pude observar que se trata de una gran inversión con un ROI no muy cercano, debido a que mientras existe un grupo de testers que corren pruebas manuales, hay otro grupo que para los mismo casos de pruebas van diseñando los casos “automatizables” y esto implica quizás una duplicación del personal para hacer lo mismo, pero con especialidades diferentes. Cabe destacar que este modelo solo es posible si ya se cuenta con casos de pruebas manuales definidos, ejecutados y con resultados conocidos.

Por otro lado, es necesario incurrir por parte de los automatizadores, en el aprendizaje de varios tipos de herramientas, debido que aún cuando cada una de ellas insista en darnos máxima cobertura, esto no ocurre y de uno u otro modo se ven limitadas por distintos factores propios de las aplicaciones; y no solo del diseño sino de otros aspectos conyunturales. Esto significa que hay más inversión de la que inicialmente se estimó, no solo en tooling sino en tiempo y esfuerzo para los mismos objetivos.

Y suponiendo que lograramos alcanzar un importante nivel de automatización, básicamente un Pass-Fail de una herramienta no reemplaza el carácter analítico de los humanos, sobre todo en escenarios de gran complejidad donde las variables de resultados posibles requieren del análisis experimentado de personas que ya se han enfrentado a problemas que no se registraron o que conocen modos de fallos específicos en condiciones particulares.

Este grado necesario de interacción, nuevamente juega en contra del ROI de las pruebas automatizadas al requerir de más recursos que los estimados.

Finalmente debemos iniciar el modo de mantenimiento de lo automatizado y para cada ciclo deberemos generar aún más automatización, de modo que los problemas mencionados antes ingresan a nuestros nuevos ciclos, cada vez.

Ahora ustedes habrán notado que solo hice referencia a un modelo de todos los que podríamos imaginar, en este caso expuse uno que considero de los más común y que implica que ya tenemos un sistema donde al menos existe un profesional experto en sus características y existen casos de pruebas para regresión.

Algo de Testing Automatizado

Objetivos del Testing Automatizado

  • Tests deben mejorar la calidad al más bajo costo
  • Tests deben reducir riesgos mientras aumentamos la velocidad de ejecución
  • Tests deben requerir mantenimiento mínimo al mismo nivel que el sistema involucrado
  • Tests deben ser ejecutados como parte del proceso de construcción
  • Tests deben ayudarnos a entender el sistema bajo pruebas
  • Tests deben ser fácil de ejecutar

Debemos evitar que:

  • El mantenimiento de pruebas automáticas se conviertan en un cuello de botella
  • Que provoquen una disminución de la velocidad de la productividad
  • Que el esfuerzo y tratamiento sea equivalente a un full-development-project
  • Centrar el éxito de los proyectos en la automatización

Tipos básicos de Testing donde se puede automatizar

  • Testing Unitario a nivel del código
  • Testing de aceptación de productos/servicios (pruebas del cliente)
  • Testing de interfaces a nivel de prototipos y luego a nivel de integración o preintegración

Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

¿Cuales son los objetivos de nuestro Testing Automatizado?

Estos deben estar alineados con todos los objetivos de Calidad.

Algunos factores que afectarían a nuestros objetivos:

  • Deseamos automatizar las pruebas regresivas?
  • Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?
  • Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

Comencemos a Organizarnos

Elegir una estrategia

Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización. Debería ser una combinación de aproximaciones basadas en:

  • Objetivos
  • Tipo de sistema que queremos probar
  • Cual es nuestro actual nivel de:

    • Testabilidad: Definir la capacidad del sistema a soportar automatización de pruebas
    • Automatización: Si la base es cero ese es el peor escenario
  • Cambios que debemos considerar para una mejor aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas:
    • ¿Podemos modificar el Proceso de Desarrollo?
    • ¿Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítemes?
  • Seleccionemos un nivel de Testing a automatizar e iniciemos: de Aceptación, de Unidad, de Integración, de Regresión, etc.

Seleccionemos las herramientas basándonos en

  • Estrategia seleccionada
  • Orientación del testing (Aceptación del cliente, de componente,  middleware, GUI, bases de datos)
  • Open Source, propietario
  • la tool seleccionada se adapta a nuestra aplicación o debemos adaptar la apliación a la tool?
  • Cuales son nuestros costos?

Puntos para facilitar el mantenimiento

  • Cuales son las expectativas de gestión de pruebas automatizadas y en general?
  • Cuales serán los estándares a seguir o que patrones se implementaran?
  • Impactaremos positivamente en otras áreas?
  • Impactaremos positivamente en otros proyectos asociados?

Podríamos utilizar KeyWord como patrón regular para la reducción de costos de mantenimiento al utilizar la interfaz de usuario como base para automatización.

El enfoque que realizamos afectan las acciones

  • Los desarrolladores podrían ser resopnsables de crear o auditar y ayudar en el mantenimiento de las pruebas automatizada a nivel unitario, componentes y middle-ware, pero QA debe ser parte activa e igualmente responsable utilizando su criterio.
  • QA puede facilitar la integración directa con el proceso de desarrollo responsabilizándose de la creación de pruebas automáticas de otro tipo, como las de GUI para sistemas y aceptación.

Revisemos el Plan de Pruebas Automatizadas

En todos los casos se debería hacer una revisión de la efectividad del proceso y buscar la forma de mojorarlo. Las siguientes cuestiones podrían ayudarnos:

  • ¿Las automatizaciones son difíciles de mantener?
  • ¿Disminuyen la velocidad del Proceso de Desarrollo?
  • ¿Son eficaces en el logro de nuestros objetivos de calidad?

Tester tradicionales e ineficiencia de los procesos

 

 

 

Este título viene a raíz de un comentario que hice en uno de los grupos en los que participo en LINKEDIN. Alguien expuso:

 

… en cuanto mas sepa un desarrollador, mejor para los testers porque el codigo que escriban sera menos propenso a errores y en definitiva con menos bugs nos beneficiamos todos.
De todos modos el trabajo de tester / qa nunca deberia dejar de existir.
Por mas conocimiento que tenga un programador es un ser humano, no una maquina por lo cual siempre ocurrirán fallas.
Luego se debe auditar.. no deberiamos dar por entendido que todo lo que hicieron los programadores esta bien, tiene que haber una persona que lo compruebe.
Por ultimo los errores no solo pueden ser de programacion sino de funcionalidad por eso se debe comprobar que se cumplen los requerimientos que pide el cliente (refiriéndose a un tercero auditando el trabajo)

Mi opinión fue la siguiente:

Estimado, no estoy de acuerdo en aquello que aseveras …”De todos modos el trabajo de tester / qa nunca debería dejar de existir” si es que estás haciendo una afirmación, ni en “Luego se debe auditar”, tampoco con “tiene que haber una persona que lo compruebe”.

Algunas metodologías de desarrollo han permitido formar, facultar y fomentar equipos de desarrollo sinérgicos, sin un departamento de calidad adherido, por lo que no existen testers ni QA para auditar trabajo en fases tardías. En este contexto, el aseguramiento de calidad está a cargo de absolutamente todo el equipo de desarrollo, interesados e inclusive clientes.

Tal es así que se busca la terminación de artefactos de calidad, basados en la anticipación y prevención de defectos y no en su detección tardía. Nuevamente, no existe aquello de que debe existir alguien que audite a otros, ni compruebe si algo está bien o mal.

Con estos modelo de trabajo todas las actividades de pruebas son extremadamente importantes, yo personalmente llamo a estos equipos como “Embedded Testing Teams” (equipos embebidos en testing), y de hecho los expertos en pruebas des software son los mismos desarrolladores, quienes diseñan, desarrollan, ejecutan y mantienen las pruebas a distintos niveles.

En la vereda del frente se encuentran metodologías del desarrollo que promocionan auditorias e inspecciones a los artefactos de software que son salidas de alguna fase, o sea al final del trabajo de alguien. Absolutamente todas estas auditoras y/o inspecciones generan algún nivel de retrabajo, del mismo modo que el testing que tradicionalmente conocemos, de hecho, las auditorias e inspecciones son nada más y nada menos que técnicas de testing estático.

Colegas, admitamos que los “tester tradicionales” existen gracias a la ineficiencia de los procesos tradicionales y por supuesto a la ineficiencia no solo de sus “desarrolladores”, sino de todos los roles que admiten, se adaptan y permanecen en estos modelos de trabajo.

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.