Cómo armar un gran equipo de Testing

Parte 2: Consiguiendo los mejores Testers (continuación)

En el post anterior, detallamos algunas de las habilidades que hacen a un buen tester. Estas habilidades van más allá del conocimiento técnico que puede demostrarse en un examen. La idea es tenerlas presentes a la hora de entrevistar a un candidato, para que podamos identificar al que tenga la mayor cantidad de estas habilidades. El objetivo es armar el mejor equipo de Testing, empezando por incorporar a los mejores Testers.

A continuación, vamos a ver en detalle el resto de las habilidades que son fundamentales para ser un buen Tester.

Creatividad: sin esta habilidad, ningún Tester puede ser completo. Podrá ser metódico, ordenado, detallista, tener buena comunicación, pero si a todo eso no le suma una buena dosis de creatividad, nunca llegará a obtener grandes resultados. La creatividad es necesaria para pensar en lo que nadie pensó, para imaginar condiciones inesperadas donde el sistema puede fallar y pueden aparecer los errores. Es la base de la prueba exploratoria, donde no se sigue una estructura, sino que se va buscando, descubriendo funcionalidades y encontrando discrepancias. La creatividad le permite al Tester ir más allá de lo que está especificado, y ver lo que nadie ve.

¿Cómo evaluar la creatividad de un candidato en una entrevista? Una manera es plantear problemas de pensamiento lateral. Otra sería plantearle situaciones reales y pedirle que proponga varias soluciones, aclarando que no hay una respuesta correcta. La idea es ver cuántas respuestas es capaz de generar, no tanto evaluar la validez de esas respuestas.

creativity

Facilidad para aprender: es clave que el Tester tenga la habilidad de aprender rápido y solo. En muchas oportunidades, sucede que necesitamos probar una aplicación de la que no tenemos documentación, o la misma es muy escasa. En tales casos, el Tester debe explorar la aplicación y descubrir por sí mismo las funcionalidades. Deberá tener la capacidad de hacerlo sin contar con suficiente ayuda.

La capacidad de aprender con rapidez y facilidad también es importante para que el Tester pueda trabajar en distintas tecnologías y adaptarse a diferentes entornos. Esto le permitirá entender lo nuevo, para poder diseñar mejores pruebas.

Si bien existen tests específicos para evaluar la capacidad de aprendizaje, quizás lo más simple sea recurrir al propio currículum del candidato, indagando en el mismo en busca de conocimientos que haya adquirido por sí mismo. Si los conocimientos del candidato provienen únicamente de estudios formales, hay que dudar.

Malicia: esta es una palabra que puede sonar negativa, pero es la que mejor explica el concepto que queremos transmitir. No existe un buen Tester que no encuentre muchos defectos y para encontrar muchos defectos hay que querer encontrarlos. Es decir, hay que ejecutar las pruebas con la intención deliberada de hacer fallar el sistema y que aparezcan errores. De poco sirve ejecutar pruebas con el ánimo de que todo funcione correctamente. Eso no es lo que hace un buen Tester. Un buen Tester siempre quiere romper el software. Se sienta ante la pantalla y piensa: “¿cómo puedo romper esto?”. Por lo tanto, entendemos como malicia a esa intención de encontrar bugs, que en definitiva es positiva para el equipo y el proyecto.

Aquí no vamos a decir que el mejor candidato va a ser el que le ponga el pie a otro candidato para que se caiga, o le vuelque café sobre la camisa. En todo caso, estamos en busca de malicia aplicada a la tarea de Testing. Podemos pedirle que imagine que debe probar un software con determinadas características, y que nos diga cómo piensa romperlo. Si notamos un brillo en los ojos cuando decimos la palabra “romperlo”, podemos ir preparando la carta de oferta…

image001-1

Integración al equipo: por último, esta puede no ser una habilidad específica del Tester, pero es algo que no debe dejarse de lado. Debemos tener en cuenta que el candidato va a integrarse a un equipo, que quizás se está formando y donde contamos con personas que tienen determinadas habilidades y características.

Por un lado, y sobre esto vamos a extendernos más adelante, es importante que el equipo se complemente. Es decir, que cada uno de sus integrantes cuente con algunas habilidades, de manera que entre todos cubran todo el espectro necesario en un equipo de Testing. Por ejemplo, podemos tener un candidato con un perfil técnico, ideal para automatizar, pero si en el equipo ya contamos con un perfil similar, deberíamos preguntarnos si realmente necesitamos a dos personas con habilidades parecidas, y si no nos van a estar faltando otras habilidades.

Por otro lado, hay que tener en cuenta las características de personalidad y cómo puede llegar a encajar nuestro candidato en el equipo. Aquí podremos apoyarnos en Recursos Humanos.

Es también una buena idea que alguno de los miembros del equipo tenga una breve charla con el candidato, y tengamos en cuenta su feedback, ya que él puede darnos una visión que nosotros no tenemos, desde “adentro del equipo”. Ya que van a ser compañeros de trabajo, deberíamos tomar en cuenta su opinión.

Finalmente, a la hora de armar un equipo de Testing, deberemos buscar la correcta combinación de habilidades, para que podamos utilizar en cada momento las que se necesitan, según la tarea. Como hemos dicho, ese será el tema del próximo post.

 

Anuncios

Cómo armar un gran equipo de Testing

Parte 1: Consiguiendo los mejores Testers

 

Entrevistar eficazmente a un Tester no es sencillo. Sobre todo, cuando necesitamos armar un equipo de Testing y no contamos con profesionales idóneos que puedan evaluar a los candidatos técnicamente. Sin embargo, enfocarse sólo en los conocimientos técnicos es un error. Muchas veces, se opta por pedirle al candidato que complete un examen escrito, a veces, para peor, tipo multiple choice. Se entiende que esto simplifica la tarea, pero es un recurso que se queda a medio camino. No estoy en contra de los exámenes, el conocimiento técnico es importante y valioso, pero hay que entender que no es lo único, ni siquiera lo más importante. Existen determinadas habilidades que un buen Tester debe tener y que no deberían pasarse por alto en una entrevista. No hay que olvidar que el conocimiento técnico puede incorporarse de manera más o menos rápida con una capacitación. Sin embargo, ciertas habilidades son mucho más difíciles de adquirir, o llevan mucho más tiempo. Por eso, no hay por qué descartar el examen técnico, pero antes deberíamos asegurarnos de que estamos evaluando también las habilidades fundamentales con las que debe contar todo buen Tester. A continuación, las que creo son las principales.

Atención al detalle: esta es una habilidad básica e imprescindible. No se puede ser buen Tester si no se está atento a los detalles. Esto vale tanto para lo visual, cuando se necesita por ejemplo comparar una implementación contra un diseño, como para otros detalles como errores de tipeo u ortografía, mensajes al usuario equivocados o incomprensibles y hasta problemas de usabilidad.

Además, en mi experiencia, la mayor parte de los errores reportados por el cliente o usuario final ante su primer contacto con el sistema, son errores de detalle.

Es por eso que un candidato que combina bien la ropa debería tener ventaja sobre otro de estilo desaliñado. Y antes de pedirle que resuelva una consulta SQL, habría que proponerle el juego de las 7 diferencias.

7 dif

Comunicación: existen excelentes programadores que se calzan los auriculares todo el día, fijan la vista en el monitor y se aislan del mundo (aunque esto en el contexto de Agile es discutible). En un Tester, esto es inadmisible, porque parte de su trabajo consiste en indagar. Ya sea para averiguar los requerimientos (o los baches en ellos), entender la forma en que esos requerimientos fueron implementados, saber si una aplicación está testeable, conocer cuándo será el próximo release, o reconocer si lo que está observando es un error o no. Para todo eso, es necesario preguntar. Y sobre todo, hacer las preguntas correctas. Es por eso que las habilidades de comunicación son fundamentales. El Tester debe ser un muy buen comunicador, debe saber preguntar y debe saber explicar. Necesita además comunicarse con diplomacia y saber adaptarse a los diferentes estilos y personalidades, según sus interlocutores.

Es una buena idea, antes de presentarle al candidato la hojita con el examen, tener una buena charla, amplia, pasando por diversos temas. Es también recomendable pedirle que cuente algunas de sus experiencias, sobre todo de casos puntuales en los que haya sabido resolver situaciones desafiantes, a través de la comunicación.

Pensamiento lógico: esta es otra habilidad muy importante, que pone en juego la capacidad analítica del Tester. Se aplica fundamentalmente cuando está ante los requerimientos funcionales. En ese momento, debería utilizar esta capacidad para entender primero la lógica del sistema y sus requisitos, y luego para detectar baches, inconsistencias o discrepancias en los mismos requerimientos. De la misma manera, el proceso de diseño de pruebas requiere del uso de la lógica. Recordemos que el diseño de casos de prueba consiste fundamentalmente en encontrar la cantidad mínima de casos que permitan probar el mayor número de escenarios, de acuerdo a los requerimientos. Esto no puede hacerse sin el uso de pensamiento lógico, es por eso que esta habilidad resulta fundamental.

Aquí bien podríamos recomendar que en el examen se incluyan algunas preguntas básicas de lógica, ya que esto resulta bastante sencillo de evaluar de este modo.

desorden

Orden y organización: es muy difícil ser un gran Tester si no se es ordenado, organizado y prolijo. Está claro que estas son habilidades necesarias en la mayoría de los trabajos, pero particularmente en el de Testing. El Tester necesita ser ordenado para asegurarse de que no se le escapa nada, para tener en claro qué probó y qué no, en qué momento lo probó, siguiendo cuáles pasos, contra qué versión, etc. Debe ser ordenado también a la hora de reportar los defectos detectados, como así también para su seguimiento. Estas habilidades también le servirán para recordarle al equipo que debe seguir determinados procesos, cuando se desvíen, y para responder consultas en las situaciones en que algo no esté del todo claro. Debe ser también organizado para saber priorizar sus tareas. La clave de un buen trabajo de testing está en la buena organización y la correcta definición de las prioridades, sobre todo en los momentos más candentes de los proyectos, cuando al mismo tiempo hay que verificar correcciones de bugs, probar nuevas funcionalidades y ejecutar regresiones. Y por último, debe ser prolijo, cuidadoso de seguir todos los pasos necesarios para ejecutar correctamente las pruebas, generar los datos y reportar los defectos. De lo contrario, los resultados de las pruebas no serán confiables.

Una manera de evaluar el orden y la organización en un candidato, es proponerle preguntas abiertas, donde deba elaborar una respuesta, siguiendo determinados pasos para llegar a una conclusión. También puede pedírsele que priorice u organice una lista teórica de tareas. Sin embargo, no habría que pasar por alto ciertos detalles, como la puntualidad para llegar a las entrevistas, que recuerde con quién se le dijo que debía reunirse, que se haya asegurado de contar con el tiempo suficiente para la entrevista, etc.

En la segunda parte detallaremos algunas habilidades más de los mejores Testers.

El Tester Agil y el Síndrome de la Película Empezada

cinema

Imaginemos una persona que quiere ir al cine a ver una película. Saca su entrada anticipada, pero por determinadas circunstancias, llega tarde a ver la película y se pierde la primera parte. Entonces, verá por ejemplo que los actores buscan a alguien, pero no sabrá a quién ni por qué. O verá a un actor deseando venganza, sin saber bien qué le hicieron ni por qué está tan enojado. A esto llamo el “Síndrome de la película empezada”.

De la misma manera, a pesar del auge de las Metodologías Agiles, ATDD, TDD, etc., en muchos proyectos todavía se involucra tarde a los Testers. Suele pasar que se incorpora al Tester cuando las user stories ya están escritas, estimadas y con los criterios de aceptación ya delineados. De esta manera, el Tester se pierde parte de la película, y el proyecto a su vez pierde la visión que puede aportar el Tester.

Desde el punto de vista de la gestión del proyecto, se entiende que se haga esto por una cuestión de presupuesto, principalmente porque se presume que durante los primeros sprints el Tester no tendría demasiado para hacer y por lo tanto, sería un desperdicio de recursos.

Sin embargo, esta es una creencia equivocada. Veamos algunos ejemplos de tareas que el Tester podría tomar a su cargo en las etapas tempranas del proyecto:

  • Estimar las tareas de Testing: sabemos que, cuando les hablamos de tareas de testing, como diseñar casos de prueba, generar datos o planificar las pruebas, muchos PMs dicen “sí, sí, bueno…” con gesto de incredulidad, pensando que esas tareas van a ser agujeros negros adonde irán horas que no producirán ningún resultado tangible. Sin embargo, estas tareas son necesarias y aportarán su valor al proyecto, y por lo tanto, deben ser estimadas. Por otra parte, cada una de las user stories requerirá de tiempo de testing. Muchas veces, sin embargo, se realiza la estimación sin tener esto en cuenta, olvidando que una user story no está terminada hasta que fue completamente testeada. Ese tiempo debe ser considerado e incluido en la estimación.
  • Escribir los criterios de aceptación: el Tester es la persona ideal dentro del equipo para realizar esta tarea, por ser quien va a tener la visión funcional del desarrollo y además porque los criterios de aceptación van a constituir la base de su trabajo de testing. Suele pasar, sin embargo, que los criterios de aceptación los escribe el Scrum Master, convirtiéndose en una suerte de repositorio del conocimiento funcional, lo cual le quita tiempo y reduce la eficiencia de todo el equipo. Además, convierte al Scrum Master en un proxy entre el equipo y el Product Owner. Sucede que los proxies son muy buenos cuando son necesarios. Cuando no lo son, se convierten en un problema. Otro enfoque es que haya un Business Analyst que escriba los criterios de aceptación. El problema con esto es que esta persona suele participar al inicio del proyecto, y luego al no tener demasiado que hacer, se lo asigna a otro proyecto. Como consecuencia de esto, las preguntas que surjan en las etapas posteriores sobre los criterios de aceptación (“¿qué quiso poner acá?”, “¿este criterio todavía es válido?”, etc.), quedarán sin respuesta.
  • Automatizar: es muy difícil que un proyecto bajo metodologías ágiles resulte exitoso si no se utiliza la automatización de pruebas, como mínimo en un nivel básico de regresión. Esto no se puede lograr si no se comienza desde el inicio mismo del proyecto. Sin embargo, suele suceder que en el sprint 10, alguien de pronto le dice al Tester: “recordá que es un requerimiento de este proyecto tener pruebas automatizadas, por lo menos la regresión”. Frases como esta le ponen los pelos de punta al más calmado. A esta altura del proyecto, el Tester normalmente se está rompiendo la cabeza pensando cómo encontrar el tiempo para hacer una “mini-regresión”, y le hablan de automatizar…

Estos son sólo algunos ejemplos de tareas que generan valor y que el Tester puede tomar a su cargo en las primeras iteraciones, cuando las tareas de testing en sí no deberían demandarle demasiado tiempo.

Son también buenos motivos para que el Tester esté involucrado desde el comienzo y, entre otras ventajas, pueda evitar el “Síndrome de la película empezada”. El autor se permitió la licencia de inventar este “síndrome”, basándose en su teoría de que alguien que se incorpora a un proyecto cuando este ya ha comenzado, al igual que el espectador que llega tarde a una película, por más que se quede hasta el final y no se pierda de nada más, sentirá siempre la incertidumbre de pensar que quizás le falta saber algo. Acaso en las primeras escenas había un detalle que en realidad modificaba todo el sentido de la historia… Este síndrome sólo se logra evitar si se puede mirar la película completa (o participar en el proyecto desde el comienzo).

¿Qué puede hacer el Tester? Es simple: pedir, demandar, exigir que lo incluyan en el proyecto desde el principio. Hablar con el líder de Testing, con el responsable del proyecto, con quien sea necesario para lograr este objetivo. Una buena idea es mostrar la lista de más arriba, para dejar en claro que hay actividades que puede hacer para aportar valor en esas primeras iteraciones y así hacer buen uso de su tiempo.

De otra manera, será siempre víctima de la duda que le va a generar esa parte de la película que se perdió… ¿y si era todo un sueño y yo nunca lo supe?…

Nuevas fechas para Formación de Testers en Buenos Aires

EXO TRAINING CENTER®, líder en Capacitación y Entrenamiento de Profesionales y Empresas de TI que buscan estar a la vanguardia del conocimiento y las Mejores Prácticas, ha anunciado recientemente un acuerdo con QAbility, para el dictado de cursos de Testing/QA de Software.

La propuesta resulta interesante tanto para aquellos que buscan insertarse en el mercado laboral de IT, como así también para quienes necesitan fortalecer sus habilidades y así potenciar sus posibilidades de crecimiento dentro del mercado.

Para lo que resta de este año, se han anunciado 3 fechas, en octubre, noviembre y diciembre.

cursos exo

Más información en el sitio Web de Exo Training Center

Automatización de pruebas: el éxito está en cambiar

Muy bien. Después de mucho esfuerzo en tiempo y dinero, tenemos la regresión automatizada funcionando. Podemos ejecutarla las veces que queramos, con resultados confiables, velocidad aceptable y sin inconvenientes. Hasta la hemos incorporado a la integración continua y todo funciona. Ahora, podemos relajarnos. ¿O no?…

Si es viernes a la tarde y usted siente que necesita relajarse, no siga leyendo.

Un buen día, aparece un error en producción. Después de las corridas para solucionarlo y probar que todo siga funcionando, es aconsejable realizar un análisis para tratar de descubrir qué falló. La idea no es encontrar culpables, sino detectar qué salió mal, para corregirlo y que no se repita. En ese análisis, es posible que descubramos que la falla estuvo en la regresión automatizada, que no fue capaz de detectar el error. ¿Pero… cómo?

Ocurre que una vez que hemos logrado armar una regresión automatizada que funciona, que está completa y es confiable, necesitamos dar un paso más, que podemos considerar como parte del mantenimiento de esa regresión. El paso extra consiste en realizar cambios, para que siga siendo eficiente. Cambiar para evitar lo que se conoce como “paradoja del pesticida”.

La paradoja del pesticida se basa en un fenómeno observado en la actividad agropecuaria. Explica que, tras un tiempo de aplicar en un campo el mismo pesticida, en dosis similares y en la misma forma, éste pierde su efectividad, ya que habrá matado a todos los bichos a los que puede matar. Sin embargo, esto no quita que haya otra especie de bichos a los que este pesticida no puede eliminar. Esto, llevado al campo del Testing de Software, significa que, si repetimos una y otra vez las mismas pruebas bajo las mismas condiciones, estaremos seguros de que estamos libres de cierto tipo de defectos, pero habrá otro tipo de defectos que no vamos a detectar, que son “inmunes” o se han adaptado a nuestras pruebas. La paradoja del pesticida forma parte de uno de los principios de las pruebas de software definidos por la ISTQB.

En realidad, este fenómeno se aplica a todas las pruebas de regresión, pero especialmente a las automatizadas. Ocurre que, cuando la regresión se ejecuta manualmente, con el solo hecho de cambiar a la persona que ejecuta las pruebas, logramos un enfoque distinto y por consiguiente, podemos tener resultados diferentes. Las pruebas automatizadas, en cambio, son más sensibles a la paradoja del pesticida, por ser ejecutadas siempre por un robot.

Para evitar este fenómeno indeseable, como hemos dicho, deberemos realizar cambios. Vamos a necesitar del Tester, que va a ser quien va a definir estrategias para realizar modificaciones en las pruebas, sin que ellas pierdan su eficacia. Existen numerosas estrategias que se pueden aplicar para evitar la paradoja del pesticida. Algunos ejemplos:

  • Cambiar el set de datos de prueba: como hemos mencionado varias veces, los datos de prueba son muy importantes. No se trata de probar con cualquier dato, sino que deben ser diseñados cuidadosamente, ya que el set de datos incorrecto puede arruinar los mejores casos de prueba. Cuando se ha utilizado el mismo set de datos por un tiempo prolongado, es hora de cambiarlo por otro. Este cambio puede determinar que aparezcan errores que antes pasaban inadvertidos, que suceden ante determinados datos, y con otros no. Esto debe hacerse cuidando de no desvirtuar el espíritu de los casos de prueba.
  • Modificar la secuencia o el orden de las pruebas: normalmente, la regresión automatizada tiene su secuencia de ejecución. Muchas veces, esta secuencia puede alterarse, para buscar que las pruebas tengan un nuevo enfoque. Suele pasar que con sólo cambiar el orden en que se ejecutan los tests, aparecen errores que antes no se detectaban.
  • Ejecutar las pruebas sobre otro ambiente: de la misma manera, si ejecutamos el mismo set de pruebas sobre un ambiente distinto de hardware y/o software, podemos obtener resultados diferentes. Por ejemplo, si veníamos ejecutando nuestra regresión sobre el ambiente de Test, podemos ver qué sucede si la ejecutamos en Staging o incluso en Producción. Es posible que el mero cambio de ambiente nos descubra problemas que no se habían visto antes.

Estos son solamente algunos ejemplos de modificaciones que podemos aplicar para evitar la paradoja del pesticida. Estos cambios deben realizarse siempre con profundo conocimiento del concepto y el sentido de las pruebas, para evitar que terminen siendo inválidas. Asimismo, se recomienda que formen parte del mantenimiento normal de la regresión automatizada. De esta manera, vamos a asegurarnos que nuestra automatización continuará siendo exitosa a lo largo del tiempo.

Para finalizar, podemos concluir que el rol del Tester sigue siendo necesario, que estamos lejos de que la automatización reemplace al Tester. Más bien, necesitamos de él como nunca, para aportar su creatividad y el toque humano, que le permitirá al robot seguir siendo eficiente.

¿La automatización de pruebas reemplaza al Tester?

humano robot

Muy frecuentemente, surge este tema, ya sea como pregunta o como materia de discusión. Algunos parecen tener la fantasía de reemplazar a los Testers por un conjunto de pruebas automatizadas, que presionando un botón garanticen la calidad de un producto. Sin embargo, las cosas no son tan sencillas, y se corre el riesgo de perderse una parte importante de los beneficios de una prueba bien realizada.

Existen, dentro de la labor del Tester, dos conjuntos de actividades o tareas bien diferenciados.

Por un lado, tareas que son estructuradas, esquemáticas e incluso repetitivas. En este grupo, podemos incluir a las que en el mundo ágil se conocen como story tests, que son aquellos tests que se encargan de verificar que se cumplen los criterios de aceptación de cada una de las user stories. Estas pruebas normalmente cubren el camino feliz o correcto, es decir, la forma normal o esperada de utilizar la aplicación. Son bastante lineales, ya que surgen directamente de los criterios de aceptación. Contando con estos, el diseño de los tests no requiere mayor esfuerzo, y su ejecución no produce mayor emoción.

En este grupo también podemos incluir a las pruebas de regresión. Estas pruebas son fundamentalmente repetición de tests que ya se han realizado, con el objetivo de verificar que no se han introducido nuevos errores. Y son reiterativas por naturaleza. Es decir, que ante cada modificación que se le realiza al sistema, deben ejecutarse las mismas pruebas de regresión. Una y otra vez. No es difícil imaginar que en desarrollos con numerosas iteraciones, las pruebas de regresión llegan a ser la pesadilla del Tester.

De acuerdo a sus características, los tipos de pruebas que incluimos en este primer grupo son ideales para automatizar. Tanto las story tests como las pruebas de regresión, al ser estructuradas y repetitivas, qué mejor que dejarlas en manos de un robot. Por un lado, cualquier Tester estará de acuerdo en que son aburridas, de manera que le haremos un gran favor si se las ahorramos. Por otro lado, el robot nos garantiza una ejecución eficiente: no sólo van a ser más rápidas, sino que podremos estar seguros de que no se olvidará de nada y cumplirá al pie de la letra con todos los pasos necesarios para la ejecución de cada uno de los tests.

Ahora bien, del otro lado, tenemos otro conjunto de pruebas de características totalmente distintas. Son las que llamamos pruebas exploratorias. Estas pruebas son desestructuradas y requieren de creatividad. Típicamente, el Tester se sienta ante la aplicación y va ejecutando pruebas a medida que va descubriendo las funcionalidades, sin otra guía que su experiencia y creatividad. Muchas veces, estas pruebas se utilizan para suplir la falta de documentación. En muchos otros casos, son el complemento de las pruebas anteriores. La gran ventaja de este tipo de tests es que suelen revelar fallas desconocidas, aquello en lo que nadie pensó y la creatividad del Tester supo sacar a la luz.

Para este tipo de pruebas, los robots no son apropiados. Se necesita una persona, un Tester que además cuente con buenas habilidades y vasta experiencia, que va a combinar con su creatividad para descubrir aquello en lo que nadie pensó. Esta es la tarea que suele resultar más gratificante, desafiante y entretenida para los Testers, y la que nunca se van a aburrir de ejecutar. Es lo que hace el trabajo del Tester interesante y divertido.

En suma, ¿La automatización de pruebas reemplaza al Tester? En parte sí, y está bien que lo haga, en cuanto se enfoque en aquellas tareas repetitivas y estructuradas, que para un ser humano resultan monótonas y aburridas. Y en parte no, ya que no se puede encomendar a un robot una tarea desestructurada y creativa como el test exploratorio. Para eso es imprescindible un ser humano.

Lo que hay que entender, es que no conviene robotizar a un ser humano, poniéndolo a ejecutar tareas repetitivas, ni humanizar a un robot, esperando que aporte creatividad o pensamiento lateral. Para que los resultados sean exitosos, debemos aplicar cada recurso en lo que mejor sabe hacer.

Una iteración en la vida del Tester

Con la llegada de las metodologías ágiles, el rol del Tester sufrió una transformación. Una de las principales diferencias con otras metodologías es el ritmo de las tareas de testing, que se expanden a lo largo de cada uno de los ciclos de desarrollo ágil, llamados iteraciones.

iteracion tester

Cómo son, día por día, las tareas del Tester durante cada una de esas iteraciones?

Día 1: En el primer día de cada iteración, las user stories de más alta prioridad se van tomando del backlog. El Tester, junto con el resto del equipo y el Product Owner, deberán trabajar en definir los criterios de aceptación para cada una de esas user stories. Es el momento de formular las preguntas de más alto nivel, para ir delineando la funcionalidad que entregará cada una de las user stories, como así también cuál va a ser el valor que le aportará al negocio.

Durante la segunda parte de la sesión de planificación, deberán identificarse y estimarse las tareas de testing para cada una de las stories. Típicamente, las tareas de testing son: “Definir casos de prueba”, “Escribir tests automatizados”, “Ejecutar prueba exploratoria”.

Días 2 y 3: En estos días, la principal tarea del Tester consiste en mantener conversaciones con el Product Owner, con el objetivo de refinar los criterios de aceptación para cada una de las user stories. La buena comunicación es clave en esta etapa, porque le permitirá al Tester dilucidar en detalle qué es lo que se espera de cada una de las funcionalidades. Este es un proceso que bien puede continuar en los días subsiguientes.

Asimismo, durante estos días, el Tester comenzará a diseñar los tests de aceptación. Esto debe verse como una tarea colaborativa, que ayudará a guiar el desarrollo, en la medida en que los desarrolladores escriban el código que pase esos tests. Esta tarea de escribir tests de aceptación continuará durante los siguientes días. Normalmente, el proceso de diseñar estos tests disparará nuevas preguntas, que generarán nuevas charlas con el Product Owner, a fin de continuar refinando los criterios de aceptación.

Días 4 y 5: Aquí es donde suele comenzar el test exploratorio, ya que normalmente ha finalizado el desarrollo de algunas de las user stories. Entonces, una vez que se ha asegurado de que los tests del “camino correcto” pasan, el Tester comienza a usar su creatividad para pensar en condiciones o escenarios en los que nadie pensó, y de esa forma encontrar errores inesperados. Generalmente, se seguirán ejecutando pruebas exploratorias hasta casi el final de la iteración.

Días 6 y 7: En la medida en que se van desarrollando más user stories, el Tester comienza a ejecutar pruebas que buscan verificar funcionalidades combinadas o integradas. El objetivo es asegurarse de que las nuevas funcionalidades se integran correctamente con las funcionalidades pre-existentes. Esta tarea seguirá adelante por un par de días por lo menos. El éxito de esta tarea depende en gran medida de que las user stories estén diseñadas correctamente

Días 8 y 9: Asumiendo que el desarrollo de todas las user stories está completo hacia el 8vo. ó 9no. día, es el momento de ejecutar pruebas end-to-end, que verifiquen tantos escenarios como sea posible, siempre basándonos en casos reales de uso del sistema. El principal objetivo de estas pruebas es verificar que todas las nuevas funcionalidades aumentan el valor del software para el negocio y que el mismo se halla en condiciones de ser entregado al cliente o usuario final.

Día 10: En el último día de la iteración, el equipo realiza una demostración de las user stories al Product Owner, buscando obtener su aceptación. Esta demo generalmente requiere un armado cuidadoso, como generar los datos necesarios o asegurarse de que todas las funcionalidades están listas para ser demostradas. Así, el equipo completo se concentrará en generar una versión que pueda ser presentada al cliente. El Tester, por ser quien está más familiarizado con las funcionalidades, suele ser el encargado de llevar adelante la demostración.

Asimismo, como cierre de la iteración, se suele realizar una reunión denominada retrospectiva, donde todo el equipo analiza la marcha de la iteración que está concluyendo, resaltando los aspectos positivos (que deben repetirse) y los que se pueden mejorar. El Tester aportará su visión a esa retrospectiva.

Aclaración: La duración de cada una de estas tareas no es taxativa, sino más bien indicativa, y puede variar de un proyecto a otro. Es decir, que algunas tareas podrían comenzar antes o después de lo indicado más arriba, y prolongarse por más tiempo, incluso más allá del final de la iteración.