menu_superior

El tester ágil como fusión de perfiles (III)

El tester agil como fusión de perfilesEste post forma parte de una pequeña serie de post que tengo intención de escribir para profundizar en la figura del “tester ágil”, entendiendo como tal al tester que desarrolla su actividad dentro de un modelo de desarrollo ágil. En principio la serie no tiene una duración concreta, de momento tengo 3 posts en mente, pero es posible que a la larga acabe ganando contenido y se convierta en uno de los topics del blog.

El tester fusión o tester universal

Para explicar gráficamente este perfil en mi ponencia en el evento de PAM, hice la analogía con un iceberg: Al igual que el iceberg tiene una parte dentro del agua y otra fuera, el tester universal debe estar al tanto de lo que ocurre en desarrollo (testing de caja blanca) y pendiente de lo que ocurre en el negocio (tester de caja negra). Es importante significar que “estar al corriente” quiere decir exactamente eso, saber qué pasa, qué se hace, con qué objetivos, etc. En ningún caso quiere decir que el tester sea responsable de desarrollar el software y ponerlo en producción, eso lo hacen los desarrolladores y los responsables de operaciones respectivamente.

Actividades de un tester universal

Definido el ámbito de actuación, hagamos lo propio con las actividades a realizar:

  • Ejecutan pruebas sobre el código. Un tester universal debe tener cierta familiaridad con el código, es decir, conoce la sintaxis y está capacitado para ejecutar pequeñas porciones (módulos, clases, métodos, grupos de sentencias, etc) con el fin de identificar su correcto funcionamiento. En el caso de que sea responsable del análisis estático de código esta aptitud también es útil para confirmar resultados y descartar falsos positivos.
  • Automatizan casos de prueba. Uno de los grandes caballos de batalla del testing es la automatización de la ejecución de casos de prueba. El tester universal debe ser capaz de automatizar casos de prueba tanto a nivel de pruebas unitarias como a nivel de interfaz.
  • Conocen riesgos y prioridades. A lo largo de esta serie de post ha quedado de manifiesto que no se puede aislar el software del negocio, por lo tanto el tester debe conocer cuales son los riesgos y prioridades del negocio con el fin de elegir estrategias de pruebas que aseguren estos objetivos.
  • Ejecutan pruebas de sistema. Las pruebas de sistema se definen como las pruebas que se realizan sobre el sistema completo, es decir, no sólo hay que hacer pruebas a pequeña escala (pruebas unitarias) si no también las del sistema completo para verificar que la funcionalidad es correcta de extremo a extremo.
  • Monitorizan aplicaciones en producción. El último (y muchas veces olvidado) escalón, es la funcionalidad en producción, un tester universal debería tener en cuenta qué está pasando en producción tanto a nivel funcional (defectos, necesidades del usuario, dificultades para encontrar determinadas funcionalidades, etc) como a nivel de rendimiento (concurrencia, consumo de recursos, picos de carga, indisponibilidad, etc). En principio no tiene porqué manejarse en producción, simplemente disponer de la información en dicho entorno y saber analizarla.

Por último, me gustaría describir cómo podemos ordenar en diferentes escalones o niveles las actividades propias de un tester

  • Arranque de Sprints. El tester debe participar en el arranque del sprint para conocer qué funcionalidades entran en el mismo y así poder planificar y priorizar el esfuerzo de pruebas para ese sprint (*1)
  • Construcción de código. Durante esta fase que ocupa la practica totalidad del sprint, se ocupa de automatizar y ejecutar casos de prueba. A pesar de no haberlo mencionado explicitamente es vital que el tester forme parte del equipo que “produce” el software ya que la ejecución de las pruebas requiere total sincronización con los desarrolladores.
  • Sistema completo en PRE-producción. Cuando el sistema llegue a preproducción, el tester debería ejecutar pruebas exploratorias (pruebas manuales para reproducir casuísticas complejas o de mayor riesgo) y de regresión (automatizadas).
  • Sistema en PRODUCCIÓN. Una vez que el sistema en está producción, el tester debería monitorizar su software: satisfacción de usuarios, defectos, alineamiento con el negocio y rendimiento. La idea no es que solucione las problemas en producción si no que tenga en cuenta está información para el testing de próximas entregas.

(*1). Hablo de sprints por ser la “medida” más popular, se puede considerar otra, el objetivo de fondo es organizar la actividad. En realidad en este último parrafo se pueden hacer muchas salvedades en función de la práctica concreta. El propósito que se vean los disintos niveles a los que debe actuar un tester universal.

, , ,

Comments are closed.