Manual (Exploratory) Tester is not dead at all…

“My team (Pivotal Tracker) is looking for an exploratory tester. We are based in Denver, and I think we have about 25 people total on the team. It’s a really nice environment with great people. As with the rest of Pivotal Labs, we use XP practices such as pairing, TDD, and automating tests at all levels. We’re doing some exciting experiments to improve our ability to build quality in. For example, we’re automating all of our build and deployment processes, moving towards continuous delivery. We’re also starting to use story workshops and BDD (automated with Cucumber and Capybara) to guide development at the acceptance test level.”

Así es como inicia uno de sus post la muy famosa Lisa Crispin en el grupo público de Yahoo “Agile Software Tester”.

En ésta porción de texto nos muestra lo grandioso de su entorno de trabajo, donde lo más destacado es el “gran grupo de profesionales” que conforma su equipo de aproximadamente veinticinco (25) profesionales.
También nos cuenta que mayormente sus prácticas, como las del resto de la empresa, son del estilo XP (Extreme Programing) entre las que destaca trabajo en pares, TDD (Desarrollo Dirigido Por Pruebas, según siglas en inglés), automatización en todos los niveles :O lo que incluye la generación de sus paquetes de software (builds) en un esquema de Entregas Continuas (Continuous Delivery).

Además al parecer han encarado algunos “experimentos” con el objeto de mejorar la calidad en el proceso de desarrollo, aunque le anteceden técnicas para mejorar los contenidos y comprensión de las Historias de Usuarios, tales como “story workshops”. Inclusive han incorporado Desarrollo Dirigido Por El Negocio (BDD) utilizando algunas conocidas herramientas de automatización como Cucumber y Capybara, para conseguir un desarrollo orientado por Testing de Aceptación (AUT).

Como podrán ver, es un entorno ideal de trabajo donde las técnicas están “en la ola de la cresta” y no dudo de que se encuentren al mismo nivel las prácticas agilistas.  Los productos que desarrollan detrás de Pivotal Tracker son sin dudas innovadores y están entre los mas requeridos al rededor del mundo, así que no puedo menos que imaginar que la fuerza de conocimientos tecnológicos y el grado operativo están también en una máxima expresión.

El artículo de la señora Crispi continua diciendo:

“We need a tester who not only rocks at exploratory testing, but knows how to teach others (mainly programmers) some exploratory testing skills. The developer pairs are trying to do some exploring before they mark a story finished, but there are so many of them and only two testers right now. Our goal is that with BDD/ATDD, and the developers doing some exploring too, there will be more time for testers to do exploring at a more end-to-end level.”

En éste pedido en particular, no están buscando un nuevo desarrollador con habilidades única en un lenguaje o framework, ni un arquitecto de software eximio que establezca las bases tecnológicas, ni un experto consultor (ellos deben serlo todos) que determine los lineamientos de un proceso para trabajo Agile. No han mencionado tampoco  a un experto analista de negocios (BA) o dueño de producto (PO) para fortalecer la cadena de valor de ideación o gestación del producto, como tampoco se habla de un experto automatizador de pruebas.

Si ya sé, la página de ofertas laborales de Pivotal seguramente están todos o algunos de esos pedidos, de acuerdo, pero eso al menos lo podemos suponer todos, verdad? Lo realmente interesante es que en una de las empresas más conocidas del planeta están pidiendo un Exploratory Tester, algo a lo que en nuestra industria realmente no estamos acostumbrados.

Si son observadores en el posteo de Crispi, el pedido además de ser cordial y convincente, también es muy claro en varios aspectos a los cuales no debemos dejarlos pasar por alto:

“We need a tester who not only rocks at exploratory testing, but knows how to teach others (mainly programmers) some exploratory testing skills.”

Esta persona en particular tendrá un interesante y duro desafío al intentar explicar el enfoque del Testing Exploratorio a desarrolladores. Aunque ella (Lisa) lo expone como algo simple, liviano y muy “al paso” … “…to teach others SOME exploratory testing skills”, estoy seguro que quien tome este empleo, deberá extender sus conocimientos y habilidades a escala empresarial.
Seguramente Lisa sabe a que se enfrenta este postulante, por cuanto éste enfoque no es algo simple ni liviano, ni se aprende sin esfuerzo de la noche a la mañana, muy por el contrario tiene un sin número de particularidades que lo hacen complejo y difícil de implementar con éxito. Por un lado requiere de “practicantes” con una base conceptual importante “fuera de los estándares del testing tradicional”, pero también es necesario un absoluto apoyo de la empresa en todos los niveles.

“The developer pairs are trying to do some exploring before they mark a story finished”

Quien no ha notado que las Historias de Usuario usualmente son entregadas con un estado de “hecho” (done) dudoso, y que finalmente el ciclo de desarrollo se extiende hasta el final de Sprint tratando de resolver los defectos y errores que solo se detectaron en las pruebas de sistema?
Claramente la señora Crispi transparenta aquí una de las debilidades de casi todas los equipos que juegan a XP delimitando la participación de los Testers a fases tardías como en Waterfall.

 but there are so many of them and only two testers right now

O bien puede ser que el tan alto y preciado nivel de aplicación tecnológica les hace pensar que se necesitan menos personas en el proceso de desarrollo y por ello “recortaremos Testers”

Our goal is that with BDD/ATDD, and the developers doing some exploring too..

y “eventualmente sumaremos a algún tester”, pero esperamos que desarrollo tenga tiempo de hacer sus propias pruebas de integración garantizando algún flujo mínimo que de cierta cobertura antes de hacer “committ”.

…there will be more time for testers to do exploring at a more end-to-end level.”

porque actualmente no estamos llegando a hacer pruebas punto-a-punto y nuestros testers no logran hacer pruebas completas en los distintos flujos de negocio, ya que deben hacer sus pruebas en los puntos intermedios, revisar los datos para múltiples tipos de usuarios y sus accesos, más sus acciones posibles según los roles, analizar datos en las bases, chequear cambios de estados y trabajar contra servicios web de terceros.
La Hiper-super-archi automatización de las pruebas no son suficientes y el cliente se ha quejado tantas veces de que nuestro producto falla en algunas acciones complejas, o en los resultados mostrados, que exige que seamos mucho más cuidadosos en el análisis y en las pruebas.

Finalmente todo esto por supuesto y como es costumbre, es percibido como un “Issue de calidad” (de la vieja y nunca bien amada “área QA”), pero no asumiremos que necesitamos más testers analistas (los famosos “manual testers”) insertos en el proceso y menos herramientas intentando suplantar la inteligencia del ser humano.

You have a passion for customer-focused web & mobile apps, and discovering interesting interactions and side effects. You know good testing isn’t about quality gates that hold back releases, but about sharing information and helping to release faster and with more confidence. Whether you know how to code or not, you find you have the most fun testing. You are sharp, curious and enjoy exploring the dark corners of complex software. You judge your success by customer feedback and the success of your team, not how many problems you find. You enjoy collaborating closely with other team members.

Claro, los grandes volúmenes de datos dan una sensación de velocidad y cobertura y las enormes cantidades de horas insumidas en generación de estos frameworks de automatización y su mantenimiento, sumado a las horas de generación de las pruebas automáticas, nos dan la idea de que lo estamos haciendo bien y así muchas cosas menos podrían fallar.

Lo cierto es que haciendo cierto tipos de lecturas (totalmente sesgadas por supuesto) de éste pedido de Pivotal Tracker, podremos deducir que el Tester analista debe ser un practicante del Testing Exploratorio, que el Testing no puede ser ejecutado por herramientas o robots, que no cualquiera puede hacer Testing… pero lo que más me agrada de haber leído éste pedido en particular, es que puedo concluir que simplemente el Tester no ha muerto.

Advertisements

Orders Of Ignorance y el Testing Exploratorio

Cuando inicias una actividad de testing en si, tienes dos opciones:

1, dispones de una magnitud de conocimiento suficiente para asegurar que pronto estarás en el descubrimiento de bugs

2, dispones de una magnitud de ignorancia suficiente para solo permitirte aprender, es decir, reducir esa magnitud de ignorancia, por lo que no estás en condiciones de encontrar bugs

Si nuestra situación actual es la del punto 2, entonces nuestra actividad principal no es la de encontrar bugs, sino la de aprender para posteriormente encontrar bugs. Esto debemos tenerlo en cuenta principalmente para aprender a planificar el testing (el que sirve para encontrar bugs)


Un modo efectivo de acortar este proceso natural, es la de pensar en ambientes colaborativos de muy alta comunicación, principalmente cara-a-cara, y un enfoque muy poderoso es el del Testing Exploratorio.

Recordemos la premisa del ET (Exploratory Testing), que nos indica que “ET es abarca un proceso simultáneo de aprendizaje, diseño y ejecución de pruebas.”

Con ET encontrámos la manera de hacer shortcuts a nuestro orden de ignorancia, permitiendo decrecer indefectiblemente desde los niveles alarmantes de aislamiento, donde se intenta buscar el conocimiento en documentación imprecisa o incluso irrelevante para el testing en si mismo, hasta magnitudes aceptables de ignorancia, mermada gracias a interdependencia con otros roles (principalmente desarrolladores).

Con este enfoque ET, es posible resaltar la colaboración entre miembros del equipo y del producto, lo que se traduce a que ET es mucho más que una actividad específica del tester, sino más bien es una actividad guiada por el tester, pero altamente interdependiente del caracter colaborativo de la organización para facilitar la interacción en pos del descubrimiento de mejores escenarios de usos y sus exigencias.

El apoyo organizacional es inevitable para tener éxito en evitar errores típicos del testing tradicional, que están ligados justamente a órdenes de ignorancia que incluso, no permiten pensar en como disminuir la magnitud de ignorancia en una manera razonable, por cuanto trabajando como departamentos independientes, se exige a QA/Testing la planificación up-front del testing, junto con el diseño exaustivo de scripts de testing, aún cuando la magnitud de ignorancia es del tipo “ni siquiera se lo que no se”.

Sugested: http://c2.com/cgi/wiki?OrdersOfIgnorance

Agile testing y gestión de defectos

Desde hace un buen tiempo me encuentro en contra de la registración de defectos masiva, principalmente para entornos de desarrollo de software Agile, donde en resumidas cuentas un defecto pierde su razón de ser ni bien es corregido y verificado en el mismo Sprint de desarrollo.

Muchos me han preguntado, pero como hacen los desarrolladores en Agile para saber de que estamos hablando cuando alguien del team encuentra una anomalía, y mi respuesta siempre fue que el trabajo cara a cara evita cualquier tipo de aparato comunicacional y facilita no solo la corrección sino la mejora.

Por otro lado es cierto que existen muchos modelos de trabajo, como los tercerizados o los remotos, que impiden que los equipos se encuentren co-localizados y entonces ya existe la necesidad de algún sistema de gestión de defectos, sobre todo si hay personas que se dedican exclusivamente al testing de los items de trabajo.
Para estos esquemas también hay soluciones verdaderamente livianas, pero sin llegar a mencionar a ninguna, les diría que lo que prima es la real posibilidade contactarnos entre desarrolladores y testers para hablar de los defectos, su severidad, impacto, priorización y soluciones posibles.

Los invito a intetar un esquema simplista, donde el tester detecta el defecto, lo ingresa en una cola de trabajo inmediato, el equipo en una reunión cercana analiza los defectos acumulados (cola de trabajo), prioriza y resuelve. Tomen fecha de ingreso del defecto a la cola y feche de verificación de la solución.
Tomen exáctamente los mismos tiempos para un defecto que ingresa por una herramienta de gestión de defectos y comparen. Luego me cuentan.

Por lo pronto comparto un interesante artículo que habla de un método de gestión de defectos utilizando la automatización de pruebas como herramienta de evaluación del defecto y entidad documentacional, donde lo que se gana es un activo de software (test case automatizado) y capacidad de repetir la ejecución de la prueba las veces que se requiera.

Este punto de vista es muy efectivo y soluciona enormemente varios problemas a la vez, como la falta de cobertura por caminos alternativos significativos, aumenta el volumen de pruebas de regresión fiables, la registración del defecto, etc.

Source: STAREAST: Agile testing and defect tracking.

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.

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í.