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.

“Usuario descontento” o “descontento íntimo”?

smiley

En numerosas ocasiones hemos tenido la virtud de resolver inconvenientes a nuestros bien aventurados clientes, usuarios de nuestros sistemas en distintos niveles. Ellos agradecidos de nuestras prontas respuestas e inteligentes resoluciones, toman vigor en el uso y recomendación de las nuevas funcionalidades, se adentran en las opciones que ofrecen nuestras soluciones y generan nuevas propuestas de cambios que inyectan un flujo de trabajo a nuestras empresas.

Sin embargo a veces sucede lo contrario, nuestro cliente esta insatisfecho y todas las acciones en las que podamos incurrir le Featured imageparecen pocas o de “soluciones facilistas”. No es necesario pensar en “el cliente” como la masa corporativa que adquirió nuestro producto, sino en sujetos individuales que en algún punto del mapa organizacional provocan una suerte de ruido nocivo.

Independientemente de que se trate de un grupo de usuario o un único usuario, nuestra organización se moviliza en múltiples aspectos. Desde que “suben los incidentes” y hasta que “bajan las soluciones”, el hilo conductor del descontento de nuestro usuario, pasa por las distintas áreas provocando diferentes reacciones que a su vez producen diferentes resultados.

Los primeros resultados son “conversaciones” con demandas poco constructivas, con acusaciones sin sentido práctico y respuestas reactivas poco esclarecedoras. Este comportamiento primario e inicial denota la inmadurez del grupo, del área, de conjunto gerencial y finalmente de la empresa completa. En un ambiente así nadie muestra el más ínfimo ápice de satisfacción. 

Featured image

Es posible que no se acepte que los fallos y defectos existirán indefectiblemente y que no hay proceso, metodología o técnica que eviten su llegada al usuario final, sin embargo una mentalidad rígida e inflexible solo lastima a la organización y sus equipos. Así, bajo un formato de miedos insensatos contagiados por los clientes, las organizaciones prestadoras de servicios se adentran en una ficción de “el cliente siempre satisfecho”.

No pasará mucho tiempo hasta que vean su reflejos adormecidos hasta el punto de herir a sus propios equipos ya sin soluciones, provocará un “sangrado interno” que dudosamente cicatrice con rapidez.

Posturas inflexibles hacia adentro y la dogma de “hacer lo que sea” para mantener la ficción de “el cliente siempre satisfecho”, crea nebulosas que rodean al conjunto de las personas, fabrican desconfianzas infundadas y desvalorización el capital humano y profesional, aunque nuestras acciones no caigan ni una millonésima en la realidad.

Finalmente debemos reflexionar si el peligro es nuestro “usuario descontento” o somos nosotros mismos con nuestro “descontento íntimo”, quizás por falta de madurez.

Functions and Features

Inclusive Technologies es un sitio que a sido creado con el objeto de ayudar al desarrollo, evaluación o compra de productos usables y accesibles. Tal como ellos los indican, “productos que trabajan mejor por que son fáciles de utilizar”.

He decidido tomar la definición o conceptos de éste sitio, en relación a como diferenciar Funciones de Características de un producto, ya que en solemos utilizar ambos términos en el idioma ingles (Functions and Features) sin distinciones.

It is important to remember the distinction between product functions and product features.  Functions are the “product’s answer to the set of user tasks”; features are the “user tools” inherent in the product used to perform the functions (Wood, 1995).

Placing a telephone call is a function; the dial tone and the touch-tone keypad are features used to accomplish the function.  Product Types have different sets of functions, and each Model within a Type accomplishes its functions through potentially different features.

 

Pero en el desarrollo de software es algo muy relevante hacer buenas distinciones, tanto así que cada ciclo se apoya en el anterior y sin bases bien establecidas, estaríamos nada más y nada menos que desarrollando un gran error, y lo demostraremos al final de la iteración o al final en los releases.

Smallers and Largers Cyscles

 

Dicho en otras palabras, sabemos que en Agile, pero en cualquier otro método de desarrollo de software o de negocios, la comunicación es el hilo conductor hacia el éxito o hacia el fracaso.

Functions and Features

 

Entonces… Por que la importancia de distinguir entre Functionality y Features en el desarrollo de software?

  • por que solemos confundir User Stories con Tasks para desarrollo, cuando en realidad las User Stories deberían representar pedidos del cliente (the “product’s answer to the set of user tasks) y las Task serían las acciones concretas a realizar para crear Features que irán de cumplimentando Functions.
  • Por que las User Stories al ser Functionalities, se expresan en el lenguaje del negocio en cuestión y tendientes hacia un lenguaje de alto nivel, muy comprensible por cualquier ser humano.  Típicamente no incluyen expresiones asociadas a la tecnología, como restricciones de lenguajes y tipos de bases de datos o formatos de los campos, lo cual es expresado cuando desarrollamos Features.
  • Por que las User Stories ayudan a determinar alcances y límites del negocio, sin exclusiones ni inclusiones,  por ende dependencias y con ello desarrollamos criterios de aceptación para validar, no para verificar.
  • Por que al confundir User Stories con Tasks, los criterios de aceptación no se manifiestan en un lenguaje de usuario final o perteneciente al dominio del negocio, sino a un cliente del dominio tecnológico, por lo tanto la tendencia es a la verificación en lugar de a la validación.
  • Debido a esto terminamos haciendo demostraciones técnicas de como impacta la entrada de un dato en la base de datos, o como funciona el sistema de mensajería, o como un dato es transformado, en lugar de hacer demostraciones para que el cliente valide nuestras aplicaciones desde un punto de vista de valor funcional para su de negocios.
  • Por que ésta confusión nos hace olvidarnos del “para que” (Funciones) y concentrarnos en el “como” (Características) y todo luego tiende a la verificación tardía (Quality Control), en lugar de tender a la anticipación de lo que desarrollaremos (Quality Assurance)

De ahora en más me gustaría que pienses como están desarrolladas (expresadas) tus matrices de trazabilidad, tus casos de pruebas funcionales, tus escenarios de pruebas genéricas, tus pruebas de sistemas, tus pruebas de integración y unitarias, tus requerimientos y tus historias de usuario.

Piensa como está tu backlog, tanto de producto como del sprint. Piensa ahora en los releases y finalmente piensa en que cosas de valor le estás demostrando a tu cliente.

No será que te pases las iteraciones demostrando la infraestructura en lugar de la utilidad que le hace ganar dinero a tu cliente.

Functions and Features.

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