De testers y code reviews

Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son “terreno de los desarrolladores”.

¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.

STASH13_PRactivity

Y no quiero oir a nadie diciendo cosas del estilo “pero yo no soy desarrollador” o “es que no sé leer código”, porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.

Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:

  1. Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
  2. Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
  3. Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
  4. Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
  5. Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!

Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!

Anuncios

De casos de test a mapas mentales: una experiencia personal

De casos de test a mapas mentales: una experiencia personal

La mecha que prendió este post fue este comentario en una de mis entradas de análisis de herramientas de test case management, preguntando por el resultado de la investigación en este tema realizada al principio del año 2011. La búsqueda terminó al cabo de algunos meses, a medida que me iba dando cuenta de que una herramienta de este tipo no encajaba en mi contexto actual, pero nunca concluí la investigación oficialmente. No la estoy concluyendo ahora con este post, a lo mejor la retomo en el futuro, pero dos años después de sus inicios, el hecho es que hemos vivido y testeado adecuadamente sin casos de test ni herramientas de gestión de los mismos. Así es como lo hicimos.

Antes de empezar, no estoy intentando afirmar cuál es la mejor solución en este aspecto, esto es el relato de una experiencia personal solamente, un caso de estudio si queréis. Simplemente food for thought, cosas a considerar si os encontráis en esta situación. Espero os sirva de ayuda 🙂

Nuestro contexto

Intentaré resumir nuestro contexto en unas pocas líneas, contáctadme si no es suficiente para entender la situación:

  • 2 aplicaciones web-based
  • Ambas aplicaciones son maduras, con más de 3 años de existencia cada una
  • +500 casos de uso (y creciendo!), desde simples CRUD a grandes y complejos casos de integración de sistemas con interpretaciones condicionales y reglas de negocio implicadas
  • Un departamento de 2 testers, emparejado con un equipo de 4-5 developers superlistos
  • Un promedio de 2-3 releases al mes
  • Sin automatización disponible (en el momento de iniciar la investigación)

El primer número que me vino a la mente fue que necesitábamos una herramienta que gestionara como mínimo +500 casos de test (digamos, el happy path de cada uno de esos casos de uso), ergo se supone que tendremos que desarrollar esos +500 casos de test, y también se supone que tendremos que mantener esos +500 casos de test, sin reclutar nuevos compañeros ni reducir la velocidad de releases que defendemos.

No podíamos realizar esa inversión, nuestro foco hubiera pasado de testear a crear y mantener casos de test, con la sensación de que se trata de una tarea interminable, ya que hay casos de uso nuevos cada mes, más revisiones de los ya existentes, implicando nuevos casos de test a redactar y casos de test viejos a mantener, más en algún momento explorar los unhappy paths si teníamos tiempo.

Qué hacíamos mientrastanto?

Al principio de todo, 2 años antes de que esta búsqueda empezara, intentaba crear los casos de test en Excel al principio de la fase de testing (desarrollábamos bajo waterfall por aquél entonces) antes de testear efectivamente, de lo que aprendí lo siguiente:

  1. Los casos de test evolucionan mientras testeas, por ello tu manera de pensar y la herramienta que uses tiene que estar preparada para esto.
  2. El mantenimiento y la reutilización de los casos de test es un tema candente, difícil de gestionar en un entorno cambiante como el nuestro, por las razones antes mencionadas.

Con este enfoque, descubrí que invertía más tiempo creando, editando y adaptando a la situación actual mis casos de test en Excel que testeando efectivamente. Progresivamente, fui abandonando ideas; primero, abandoné la idea de reusar casos de test (con lo que el asunto del mantenimiento desapareció también); y después, abandoné la idea de preparar todo el conjunto de casos de test antes de empezar el testing, abrazando un diseño de testing y una ejecución más dinámicos. Estaba haciendo testing exploratorio sin saberlo, pero no me sentía cómodo con la idea de no tener documentación de test. Por esto último empecé la investigación de una herramienta de gestión de casos de test.

Y… Apareció el mind mapping!

Mientras investigaba herramientas concretas, intenté averiguar qué hacían otros profesionales en situaciones similares a la nuestra, y descubrí que el testing exploratorio era real y muy respetado por testers muy influyentes; y descubrí el mind-mapping también.  Inmediatamente cambié el uso de Excel y Notepad en mis actividades exploratorias extraoficiales para usar Xmind como herramienta de soporte para las mismas.

Tan buen punto empecé a hacer esto tuve un momento de esos de “cómo no había hecho esto antes!”, ya que los mapas mentales son la herramienta perfecta para desarrollar y ejecutar pruebas mientras testeas, evolucionando tus ideas de testing mientras testeas efectivamente, disfrutando con el proceso y reforzando la parte creativa del testing, cosa que también tiene su gracia. Además de esto, el uso de mapas mentales nos permitió desarrollar un “mapa mental de ideas de testing” al inicio de los proyectos e iteraciones y evolucionarlo a medida que estas avanzaban y profundizábamos en su contenido, compartiéndolo con el resto del equipo, tanto desarrolladores como stakeholders, creando una gran compilación de ideas de pruebas justo antes de empezar efectivamente a testar, y pudiendo evolucionar esta compilación mientras el testing tenía lugar.

La búsqueda de una herramienta de test case management finalizó de facto…

…en el momento que me pregunté ¿por qué iba a querer invertir esa cantidad de tiempo en documentar esos casos de test cuando estamos cumpliendo razonablemente bien sin ellos? Las primeras respuestas que me vinieron a la mente se referían a registros de ejecución de pruebas, cobertura y reutilización. Así que las analicé profundamente.

El tener registros de ejecución de casos de test no es razón suficiente para implementar una herramienta de gestión de casos de test, por lo que seguí profundizando en las otras respuestas.

Sobre cobertura… somos principiantes en testing exploratorio, así que me sentía inseguro de que nos dejáramos areas importantes sin testear con un enfoque tan dinámico, pero la idea de implementar una herramienta de gestión de casos de test no me era suficiente, preferí pensar en mejorar como testers exploratorios; además, alimentar esas herramientas nos hubiera quitado tiempo de testing efectivo, por lo que la coberturase vería afectada también. Por otro lado, qué cobertura te ofrece una herramienta de gestión de casos de test? La cobertura sobre los casos de test que has sido capaz de introducir en ella, cosa que es una manera sesgada de ver la cobertura. Me sentí más seguro haciendo crecer la cobertura en las áreas importantes a medida que íbamos testeando.

La reutilización ha sido un hito reciente para nosotros, decidiendo no reutilizar nada hasta ahora, recreando y revisando las ideas de pruebas a medida que lo hemos ido necesitando, afilando nuestros sentidos y habilidades exploratorias en cada iteración, aunque probablemente modifiquemos esta conclusión pronto.

Próximos pasos (algunos ya ejecutados)

Habiendo decidido oficialmente que hacíamos testing exploratorio con mapas mentales y siendo felices con ello, empezamos a iterar esta idea para mejorar nuestro desempeño. Cosas que ya hemos hecho al respecto:

  • Invertir tiempo en automatizar validation checks, para combinar nuestra óptica exploratoria profunda con cobertura general y ligera en términos de checking.
  • Documentar formalmente algunos casos de test para los casos de uso más críticos (hablamos de unos 5 o así), creando una mini test-suite a ser ejecutada en cada ciclo de testing, antes de la instalación de una nueva versión. Esta suite no se automatizará nunca, ya que requiere unos 15 minutos de ejecución y quiero los 7 sentidos de un tester pensante en ella, y un robot no me ofrece esa seguridad. Los smoke tests son documentados formalmente también. Estas son pruebas sencillas que demuestran que el testing exploratorio y el documentado formalmente pueden coexistir.

Cosas que espero hagamos en el futuro cercano:

  • Repensar el tema de la reutilización. Quizás podríamos desarrollar un mapa mental con checklists para empezar esa recopilación de ideas de pruebas con algo ya hecho, actualizando estos documentos a medida que los vamos usando, aceptando que tienen que ser actualizados antes de evolucionarlos, pero tomando ventaja del conocimiento y esfuerzo mental ya aplicado.
  • Desarrollar una especie de testing low-tech dashboard, basado en mapas mentales, con la intención de comunicar más fácilmente el estado del testing al equipo et altri.

Finale

Pues ya está. Un proceso de 4 años resumido en menos de 1500 palabras. Espero poder escribir algo más al respecto en los próximos 4 años, a ver si mejoramos en este interminable y fantástico asunto!

expoQA 2012

expoQA 2012

Inesperadamente, he asistido a la edición de este año del expoQA. Digo inesperadamente porque no tenía intención de asistir (las conferencias en general son muy caras, y tal y como está el patio, me parece muy bien que la empresa donde trabajo sea cauta en este aspecto), pero resulta que fui el afortunado ganador del sorteo de una entrada gratis entre los lectores del Testing Planet, revista-diario trimestral muy molona sobre testing, fabricada por la gente del Software Testing Club, y es muy feo rechazar los regalos, no? 😉

Total, que me planté en Madrid la noche del 5 de Junio y el 6 por la mañana, tras algún que otro incidente con el transporte interurbano madrileño (sí, he dicho “interurbano”, porque el venue no era muy accesible que digamos), estaba listo para devorar lo que fuera que se cociera en expoQA, sin saber muy bien cuál era la filosofía de la expo en si misma; es decir, son unas conferencias sobre testing y demás, pero ¿dadas por quién y a qué nivel? Pues a eso iba, a capturarlo.

expoQA

A toro pasado puedo decir…

Nivelazo.

Sin ser muy consciente de ello, me iba a exponer a varias charlas profundamente motivadoras e inspiradoras de #testingheroes como Paul Gerrard, Julian Harty, Graham Thomas, Stefaan Luckermaans, John Reber, Derk-Jan de Grood, Fred Beringer et al. Cada cuál hablando un poco de “su libro”, pero a grandes rasgos, hablando todos de lo mismo: la evolución del perfil profesional del tester, el futuro del rol, la importancia de la automatización para dejar espacio a otros tipos de testing y de mayor valor, como el testing de performance, el testing en dispositivos móviles, el testing de infraestructura…

Eddy Bruin, charlando sobre testing en dispositivos móviles

De las casi 40 ponencias, keynotes y charlas realizadas en los días 6 y 7 de Junio, “mi expoQA” se consolidó en 13 sesiones sobre dos grandes temas: mobile testing (fantásticas charlas por parte de Julian Harty y Eddy Bruin – en la foto -, así como una demo de SilkMobile, herramienta para automatización funcional en móviles de Borland / Micro focus) y filosofía / metodología / background / proceso del testing en general (este tema/s principalmente tocado por los grandes popes anteriormente mencionados).

Me esforzaré por ejecutar un Top 3 de charlas a las que asistí, aunque me quedaba con 7 de las 13, creo…

  1. “The redistribution of testing” – Paul Gerrard: primera sesión, primera keynote, inicio electrizante del expoQA. Que poderío, que ideas tan claras, qué manera de salirse del dogma y ofrecer visión de futuro del tester y su profesión sin sonar fatalista ni pedante. Fantástico.
  2. “Test process improvement : answering the BIG questions” – Graham Thomas: es muy fácil señalar que algo tiene que mejorarse, así como preguntarse cómo mejorarlo, lo que es más complicado es responder a esas preguntas. Muy profesionalmente, este consultor independiente británico ofreció pistas sobre cuándo, quién, cómo… mejorar el proceso de testing. Muy interesante.
  3. Ex Aequo “Mobile testing” – Julian Harty / “Testing in a new world” – Eddy Bruin: empate en mi mente para estas dos en tercer lugar, fantásticas introducciones ambas al mundo de la movilidad y sus entresijos. Justo lo que necesitaba para perder el miedo al desconocido móvil y empezar a tener referencias básicas para empezar con buen pie en este terreno, que hace meses que llama a la puerta de Netquest. Mención especial a Julian Harty, improvisando una sesión magistral (por eso no hay link al programa) ante la ausencia del ponente oficialmente invitado a hablar de este tema. Los grandes se hacen grandes en estos momentos…

Como siempre me pasa en festivales, conferencias y demás, no asistí a las premiadas como mejores charlas de la edición (es algo innato en mi). Fueron las siguientes:

  • “Mutation: a testing technique ready for its transference to industry” – Macario Polo: escogida como la mejor ponencia por parte del comité de la expo, la técnica de la mutación se refiere a introducir errores en el código para comprobar si el testing encuentra esos errores, evaluando la confianza de las suites. Fantástica idea, que puede pegar fuerte en el futuro cercano.
  • “Exploratory Testing Myths” – Luis Fraile: elegida como mejor ponencia por parte de los asistentes, la charla de Luís trató del testing exploratorio desde el punto de vista desmitificador y práctico. Me quedo con mal sabor de boca por no haber asistido a esta, pero no se puede tener todo…

En resumen, gran experiencia, puede ser una práctica recomendable asistir a una gran conferencia sobre testing una vez al año, cargando las pilas y tomando ideas y ejemplo de lo más puntero en el sector, para luego volver a la tierra y aplicar algo de lo que se haya aprendido, ya sea en términos prácticos o filosóficos.

Nos vemos en la próxima edición (o lo intentaremos)!

5 años de TRAC, 8 horas de JIRA

5 años de TRAC, 8 horas de JIRA

La empresa en la que trabajo, netquest, está en pleno proceso de cambio. La compañía ha mantenido un ritmo de crecimiento sostenido desde su fundación hace ya más de 10 años y, a parte de los retos comerciales y productivos a los que se ha ido enfrentando, también ha tenido que ir haciendo los deberes en lo que a organización interna se refiere, puesto que no es lo mismo gestionar la actividad de 5 personas (2003) a la de más de 50 personas repartidas en 5 ciudades y 4 países distintos (2011).

Sin ir más lejos, y ya entrando en materia, el ciclo del desarrollo de software ha venido funcionando con el TRAC como herramienta de bug-tracking. Hasta aquí, ningún problema, me gusta el TRAC, es un bug-tracker sencillo pero potente. Sin embargo, la tecnología de netquest tiene una característica que hace que algunos procesos sean algo distintos con el resto de empresas que fabrican software: las aplicaciones son de uso interno. Entonces, rápidamente, el TRAC se estableció también como la herramienta para que los usuarios registraran bugs, nuevas funcionalidades y propuestas de mejora.

Aquí ya empiezan las “hostilidades”, puesto que el bug-tracker está preparado y configurado para ser usado por miembros del equipo de desarrollo, en cambio el usuario final de las aplicaciones encuentra dificultades en la multiplicidad de campos presentes en el formulario y que no tienen sentido para él (cosas como Componente, Severity, Versión, Milestone… sin mencionar los campos predefinidos incorporados especialmente para el desarrollo de los proyectos).

Esto se puede superar con una buena documentación sobre cómo abrir buenos tickets (que así se llaman en el TRAC) y con la comprensión del usuario final (que debe cultivarse y mantenerse). Pero claro, la cosa se complica aún más si, dada la costumbre en el uso del bug-tracker, la herramienta se establece como la solución de helpdesk productivo de la compañía (aclaración: el ciclo productivo de netquest pasa por un uso intensivo de las aplicaciones desarrolladas en el área tecnológica por parte de los usuarios internos finales de las mismas), además este helpdesk ha ido evolucionando hacia un soporte de proyectos, tratando múltiples temas, no todos relacionados con las aplicaciones (por tanto, no competiendo todas ellas al departamento de desarrollo).

Total, que sin darnos cuenta (ejem…) tenemos un bug-tracker usado por toda la empresa para 3 cosas distintas:

  1. Gestión del ciclo de desarrollo tecnológico de las aplicaciones.
  2. Buzón de sugerencias de nuevas funcionalidades y mejoras, así como bugs encontrados en producción.
  3. Herramienta de helpdesk sobre aplicaciones y uso de las mismas en proyectos.

Esto, en términos prácticos, podemos verlo como 2 proyectos distintos, el desarrollo y mantenimiento de las aplicaciones (puntos 1 y 2 anteriores) y el helpdesk sobre el uso de las mismas y derivados. Cada uno de estos proyectos requiere sus campos, sus flujos, sus tareas, su funcionamiento, sus reports… El TRAC no puede proporcionar correctamente esa segmentación según su implementación inicial. Qué podemos hacer en este punto?

  • Tirar de plugins y trac-hacks, para customizar la herramienta a nuestra medida.
  • Desarrollar internamente los plugins necesarios, si lo anterior no fuera suficiente.
  • Cambiar de herramienta (siempre hay que estar preparado para esto).

La primera se ha demostrado inútil según nuestras necesidades; la segunda requiere tiempo de desarrolladores (que dejan de dedicarlo a las aplicaciones correspondientes), cosa dificil de justificar. Solo nos queda la tercera. Si además añadimos a la equación que el ciclo la empresa necesita una renovación y mejora en sus procesos (implicando al bug-tracker o similar), apenas hay salida.

Total, que estamos evaluando la implantación de JIRA en la empresa.

JIRA logo

Es muy difícil sacar tiempo para investigar o evaluar herramientas nuevas mientras tiras adelante tus tareas habituales. Lamentablemente solo he podido dedicar 8 horas de los 30 días de evaluación que hemos tenido, suerte que no era el único evaluador… 😦

Mi conclusión resumida es:

Wowwww.

Me explicaré, solo han sido 8 horas de inmersión, pero ni con 8 semanas te acabas todo lo que hay. JIRA es una herramienta enorme, sí sí, he dicho…

ENORME

Así de salida, creo que vamos sobrados con ella para hacer lo que queremos hacer y hacerlo tan bien que suponga un salto productivo de impacto, así como mejorar mucho en la eficiencia de la producción y el desarrollo.

En concreto, desde mi breve punto de vista, los aspectos que me han llevado a pensar así son:

1. Customización total, total de TODO:

Sea lo que sea lo que necesites, la interfície de la herramienta te lo permite hacer de manera sencilla, desde modificar los evidentes look & feel de la aplicación, proyectos, componentes, tipos de issues (que así se llaman en JIRA) hasta patrones de notificación en caso de modificaciones de issues, esquemas de permisos, nuevos campos de todos los tipos (textuales, menus de selección, checkboxes…), lo que necesites para customizar los formularios de apertura de nuevos issues. Ah, estos formularios pueden ser distintos según el tipo de issue que estés abriendo, también 😉

2. Herramienta diseñada para gestionar múltiples proyectos personalizados:

Esto nos va de perlas, puesto que era la principal deficiencia del TRAC. Además, JIRA no solo está pensado para gestionar distintos proyectos, sino que también permite gestionarlos de un modo distinto.

Los elementos que usan los proyectos (como los issues, los permisos, los usuarios y sus grupos, los flujos de issues…) se pueden customizar para cada uno de los proyectos. Por ejemplo, puedes tener un formulario muy simple para que los usuarios finales puedan registrar bugs encontrados durante el uso de las aplicaciones (dentro del proyecto de Helpdesk, por decir algo) y un formulario mucho más complejo y ajustado al ciclo de desarrollo para registrar bugs encontrados por el departamento de QA o los propios desarrolladores (dentro del proyecto de la aplicación X) y, si hubiera puntos de contacto entre proyectos (por ejemplo propuestas de mejora de aplicaciones logueadas en el proyecto de Helpdesk que debieran trasladarse al proyecto de desarrollo de la aplicación), los issues se pueden mover o clonar entre proyectos automáticamente y sin ningún problema.

Además, no solo JIRA está pensada para gestionar múltiples proyectos, sino que también está preparada para gestionar proyectos de todos los tipos, más allá del desarrollo tecnológico. Y eso, a la vista de la versatilidad ofrecida, se nota oiga. El gran ejemplo aquí son las sub-tasks, issues que están contenidos dentro de otros issues, como cuando una historia de usuario requiere distintas tareas de implementación, cada una de ellas con su estimación temporal de entrega, volumen de trabajo pendiente, etc.

3. Workflows, transitions y post functions

Rizando el rizo, el más difícil todavía. Además de customizar lo que quieras y añadirlo a los proyectos que tu quieras, en JIRA se puede configurar el flujo de los issues (workflow), sus estados y los movimientos de los mismos según el estado en el que se encuentran (transitions). Era necesario que así fuera, puesto que usar la aplicación para (por ejemplo) gestionar un ciclo de proyectos no tecnológico con el clásico flujo de bug-tracker reporter-developer-tester-closed no hubiera funcionado.

JIRA Default Workflow

Workflow por defecto de JIRA (imagen sacada de la documentación oficial de Atlassian)

Pero lo mejor de este punto son las post functions, acciones que realiza la aplicación automáticamente dada una transition concreta. JIRA ofrece de salida un conjunto de post functions ya programadas (como actualizar campos del issue, disparar un mail al reporter original…) y permite al administrador programar las post functions que necesite para que sean disparadas en la ejecución de las transiciones. A partir de aquí, no hay límites, puedes montarte tu proyecto con tus componentes y tus flujos de trabajo, sin restricciones.

Además…

Por supuesto, todo viene con más documentación de la que pueda procesarse y guias, tutoriales para todos los niveles. Por otro lado, JIRA también ofrece soporte, obvio ya que es una herramienta de pago, y necesario, puesto que es fácil perderse en la enormidad y complejidad de la misma.

Para terminar, la usabilidad para el usuario es máxima, la navegación es sencilla, los links y el acceso a las acciones que necesitas en cada momento están en la pantalla en la que te encuentras cuando los necesitas (también con shortcuts!); puedes configurarte tu propio dashboard y compartirlo con otros usuarios, y un sinfín de etcéteras…

Lo único sería…

Si tuviera que decir algo que no haya visto claro sería la parte de reporting sobre issues. Así como en el TRAC, el reporting era sencillo y potente (configurable mediante UI, TracQuery language o el lenguaje de la DB que tuvieras debajo), JIRA viene de salida con un conjunto de reports establecidos y no queda claro que hay que hacer si quieres otros, no encuentro donde se configuran como administrador y en la documentación parece ser que debes referirte a un plugin que permite programar los reports en JAVA, pero tampoco queda demasiado claro.

En resumen:

Dada la customización, potencia, versatilidad y multidimensionalidad de JIRA, me inclino a pensar que es la herramienta que necesitamos en netquest en el momento presente, y no puedo esperar a que se implante para comprobarlo!!!

La fatiga del tester

Esta semana hemos subido a producción una nueva versión de una de las herramientas propietarias de Netquest que básicamente ha consistido en el rediseño casi total de una de las áreas tratadas por la aplicación. El proceso de testing ha sido largo, duro y difícil, y he sido presa de la fatiga por varios errores de apreciación realizados durante el proceso y que me juro que no voy a cometer nunca más:

  • Incorporación tardía al proyecto: esto es más grave como más tardía es la incorporación (obvio, no? ;-)) y como más grande es el proyecto. Testers y QAs del mundo, hay que encontrar tiempo para asistir a las reuniones de análisis de nuevos requerimientos o funcionalidades (o convocarlas nosotros mismos) para no “perder comba” de lo que sucede. El proceso de testing se pone en marcha más rápido y mejor si no nos coge “en frío” en lo que al contenido se refiere.
  • Desorganización en las pruebas manuales: no tengo los deberes hechos en lo que a organización y documentación de pruebas manuales se refiere. Aunque el rediseño de la herramienta implica casos de uso nuevos y eliminación de viejos (con el consiguiente efecto idéntico en los casos de test), aquellos casos que no han cambiado o que lo han hecho muy poco tienen que estar listos para ser ejecutados y la redacción de casos nuevos tiene que quedar almacenada para futuras situaciones similares. Es importante invertir el ciclo del trabajo y empezar a documentar el testing pensando en el reaprovechamiento futuro de los casos. Una buena herramienta de Test Case Management puede ser de vital importancia en este punto.
  • Falta de automatización en las funcionalidades básicas: de las dos herramientas desarrolladas por la empresa, en esta no tengo nada automatizado. Esto añade gran incertidumbre a aquellas situaciones donde el volumen de trabajo es difícil de asumir, ya que si falta tiempo para validar las nuevas funcionalidades, mejor ni pensar en las existentes. Como más funcionalidades básicas estén aseguradas por pruebas automáticas, más nos podremos concentrar en las funcionalidades nuevas y mejor dormiremos la noche antes de la subida a producción.
La fatiga del tester

Otros factores que contribuyen a que la fatiga haga mella en los testers pueden ser…

  • Procesos largos de pruebas: hacer pruebas es divertido, pero hacerlas bajo presión temporal y durante muchos días seguidos no lo es tanto. Me vuelvo a referir a los puntos anteriores: cuanto antes nos incorporemos al proceso, mejor organizados estemos y tengamos aseguradas las funcionalidades básicas mediante pruebas automáticas, más corta será la fase de (puramente) testing de un proyecto o una funcionalidad nueva.
  • Encontrar muchos errores o muy graves: encontrar errores es buena señal, porque serán corregidos antes de llegar a manos del usuario final; esto siempre es bueno. Lamentablemente, encontrar muchos errores alarga el final del proceso de testing (trasladar los errores a la herramienta de bugtracking correspondiente requiere tiempo e implica que además de validar las funcionalidades, habrá que validar que los errores se han arreglado). Además, encontrar errores graves puede ser algo frustrante, ya que estos errores acostumbran a ser bloqueantes, impidiendo proseguir con la validación de funcionalidades concretas, lo que añade mayor presión temporal a la situación.

Al final, la subida a producción fue bien y se hizo con seguridad, pero el proceso de testing ha requerido de demasiada “fuerza bruta” y las aplicaciones se han hecho demasiado grandes y complejas como para seguir con este planteamiento. Es hora de cambiar de planteamiento y subir el listón para entregar mejores versiones en menos tiempo y con el esfuerzo racionado y concentrado en aquellas áreas que lo requieran, sin perder fuelle en procesos intermedios.