Gracias por todo, no vuelvas más! El rol del Tester en Kanban

Kanban es uno de los métodos ágiles (1) más utilizados, junto con Scrum. Incluso, muchos equipos que dicen usar Scrum en realidad lo que hacen es Kanban o un híbrido entre ambos que se ha dado en llamar “Scrumban“.

Kanban está entre los modelos de proceso más livianos (menos prescriptivos) para trabajar en desarrollo de software. Esto quiere decir que sus exigencias son mínimas: apenas un tablero con columnas, que representan estados; tarjetas que representan tareas, y el principio básico de limitar el “work in progress“, es decir, la cantidad de tareas que pueden estar al mismo tiempo en una columna. Con esto solo se puede empezar a trabajar, resulta ideal para equipos que realizan mantenimiento de aplicaciones, aunque en realidad Kanban no se limita sólo al software, puede aplicarse a cualquier tipo de tarea, si bien cuando se trata de comenzar un nuevo desarrollo de cero, es aconsejable incorporar algunas prácticas de Scrum (convertirlo en Scrumban, como dijimos arriba).

El primer paso para implementar Kanban es conseguir un tablero, unas tarjetas (para representar tareas) y definir cuáles van a ser las columnas en el tablero, es decir, los posibles estados de nuestras tareas. Aquí es donde suele aparecer el primer problema, que es no definir al menos una columna para el Testing. Este error, que solemos atribuir a las metodologías ágiles (porque, es cierto, algunos de los libros clásicos de Scrum, XP o Kanban ni mencionan al Testing), es en realidad un viejo vicio de nuestra Industria, que cada vez que puede se inclina por hacer un Testing insuficiente, o directamente nada de Testing. A este viejo vicio, los métodos ágiles que omiten hablar de Testing le vinieron como anillo al dedo (2).

Sin embargo, la importancia del Testing está muy lejos de ser discutible. Según cálculos recientes, en Estados Unidos, los bugs de software que no se detectan durante el desarrollo y llegan al usuario final, producen anualmente pérdidas por casi 60 mil millones de dólares (la fuente, aquí). Esta simple estadística debería ser suficiente para ponernos de acuerdo en que es sumamente necesaria la tarea de Testing (cuya principal función es, justamente, evitar que los bugs lleguen al usuario final). El Testing es necesario sin importar la metodología o el modelo de proceso que se utilice y Kanban, por supuesto, no es la excepción.

En consecuencia, el primer paso, fundamental, para hacer Testing en Kanban (y para hacerlo bien), es definir al menos una columna (3) para las tareas de Testing. Esto viene de la mano con el concepto de “definition of done”, es decir, cuándo vamos a poder decir que una tarea está completa (“done”). Aquí, debemos luchar contra la natural tendencia de los Desarrolladores a considerar completa una tarea cuando terminaron de escribir el código. En realidad, una tarea no está completa hasta que está probada, hasta que superó el Testing. Por esto es una buena idea agregar a nuestro tablero una columna de Testing antes de la columna Done. Esto le da a todo el equipo una visión bien clara de lo que se debe lograr: cada tarea debe estar desarrollada y probada para considerarla completa.

Una vez que hemos logrado que el Testing sea parte del proceso, el mismo debería fluir naturalmente. No obstante, muchos equipos encuentran en el Testing un cuello de botella, donde las tareas se acumulan. La forma en que Kanban prevé lidiar con este problema es limitar el “work in progress”. Como dijimos antes, se debe definir un número máximo de tareas que pueden estar al mismo tiempo en una columna. Si se ha alcanzado ese número, no puede moverse una nueva tarea a la columna hasta haber sacado otra. Esto obliga a que el equipo tome un enfoque colaborativo y flexible, que en la práctica significa que todo el equipo se dedica a eliminar el cuello de botella (en el ejemplo del Testing, desarrolladores e implementadores se pondrían a ejecutar pruebas, hasta limpiar la columna de tareas). Esto, en el largo plazo, no es la solución ideal. Para evitar que Testing se convierta en un cuello de botella, es una buena idea utilizar la automatización.

La automatización no reemplaza al Tester (4). No es su objetivo, ni debería serlo. El principal objetivo de la automatización es aliviar al Tester de las tareas repetitivas, que tranquilamente pueden ser llevadas a cabo por un robot. La principal de estas tareas son las pruebas de regresión. Estas pruebas son repetitivas, monótonas, pero muy necesarias, es preciso ejecutarlas ante cada modificación del software. Es por eso que son candidatos ideales para automatizar, dejándole al Tester la labor más compleja de ejecutar pruebas exploratorias, donde se requiere el uso de su experiencia y su creatividad y donde, al menos por el momento, un robot no puede ayudar.

Hay otras prácticas que la aplicación de Kanban nos llevará a considerar, como la Integración Continua, o el uso de “andariveles”, que resultan muy útiles, pero que ya son parte de la práctica más avanzada de este método. Seguramente los abordaremos en un futuro post. Por el momento, nos quedamos con que la clave está en incorporar el Testing al proceso y, hecho esto, abordar una estrategia de automatización que nos ayude a evitar los cuellos de botella. Dejar al Testing afuera del modelo es un error que sólo conduce a grandes pérdidas y, en muchos casos, al fracaso del proyecto.

kanban_board
Ejemplo de un tablero Kanban

(1) deliberadamente evito el término “metodología”, lo cual Kanban no pretende ser y que no es apropiada para lo que es apenas un (pequeño) conjunto de prácticas. En la industria, sin embargo, es habitual referirse a estas prácticas como “metodologías ágiles” y hasta el momento no tengo conocimiento de que esto haya producido víctima alguna.

(2) Creo que el malentendido se origina en que los métodos ágiles proponen que se construya la calidad desde el momento cero (“build quality in”) y que sea responsabilidad de todo el equipo. Por ejemplo, un Desarrollador debería realizar pruebas unitarias de su código independientemente de otros tipos de pruebas que se realicen después. De ahí a eliminar el rol del Tester, hay un abismo (donde terminan cayendo muchos proyectos sin Testing…). Otra fuente de malos entendidos es que las prácticas ágiles no definen el rol del Tester (como no definen ningún rol en realidad), mientras que el rol del Desarrollador parece obvio, el del Tester no lo es tanto.

(3) Algunos equipos que llevan un tiempo usando Kanban definen más de una columna para el Testing. Por ejemplo, se podría tener una columna de Testing Funcional o Exploratorio, otra de Testing de Regresión y tantas columnas como tipos de pruebas necesitemos aplicar.

(4) Sobre este tema, te invito a leer nuestro post: ¿La automatización reemplaza al Tester?

 

Anuncios

Diferencias entre Herramientas de Test de Performance

Introducción
Básicamente hay dos maneras de obtener indicadores de performance:

  • Fijar los usuarios concurrentes y medir los tiempos de respuesta de uno o más pasos por llamada/s (la experiencia del usuario, la cantidad de usuarios que supuestamente soporto concurrentes en línea)
  • Fijar la tasa de requests que se quiere obtener y medir los tiempos de respuesta (la experiencia del server con los usuarios arriba intentando ver mi contenido)

Hay dos herramientas Open Source que se utilizan habitualmente para fijar la cantidad de usuarios (o threads concurrentes) y medir tiempo de respuesta:

ab (Apache Benchmarking)
Línea de comandos, normalmente instalado por default cuando se instala Apache.

JMeter (Apache JMeter)
Mucho más sofisticada. Interfaz gráfica, Java, permite hacer varios pasos por llamada y varias llamadas, parseo de regular expressions, graduar cantidad de threads concurrentes, etc.

Diferencias entre AB y JMeter
En caso de querer comparar los resultados de un test de stress entre estas diferentes herramientas con el objetivo de que los resultados sean similares se sugiere leer esta breve descripción:

1) El testing con JMeter se lo debe ejecutar teniendo destildado en la pantalla HTTP Request http Client el checkbox: Recuperar todos los recursos empotrados en el archivo HTML (retrieve all embedded resources from html files) dado que AB sólo hace la llamada al HTML y no a lo que el mismo tiene embebido.

2) En JMeter el tester coloca Número de Hilos (threads) que es la Concurrencia y cantidad de pedidos (requests) que repite un usuario; la multiplicación de ambas nos da la muestra total de la prueba. Ej: 10 hilos x 10 req/hilo = 100 req totales de las 10 concurrencias (total de la muestra).

Por otro lado Apache Benchmarking, en cambio se colocan los siguientes valores:
ab –n(valor) –c(valor) http://hostname:port/path

Donde a diferencia de JMeter –n no es la cantidad de request por usuario sino la cantidad total de request de toda la concurrencia, es decir lo que para JMeter es la muestra total, mientras que –c es la Concurrencia (o Grupo de Hilos para JMeter).

De esta manera, para que las pruebas en las diferentes herramientas, se ejecuten con el mismo nivel de carga con el objetivo de validar los resultados entre ambas se muestra el siguiente ejemplo:
En JMeter                                                        En AB
Prueba 1: 30 hilos x 1 req/hilo = 30               ab -n 30 -c 30 http://hostname:port/path
Prueba 2: 30 hilos x 10 req/hilo = 300         ab -n300 -c30 http://hostname:port/path
Prueba 3: 30 hilos x 100 req/hilo = 3000      ab -n3000 -c30 http://hostname:port/path

Usando una u otra herramienta, siempre se sugiere tener un panorama bien amplio y probar:

  • URL de Home
  • URL de Nota / Aviso / Post
  • URL inexistente (Error 404) como una forma de medir cuanto le cuesta al webserver resolverlo

En la otra vertiente de fijar requests/segundo se encuentra otra herramienta Open Source:

httperf
Línea de comandos, la estamos usando en combinación con autobench (un script para automatizar ejecuciones sucesivas de httperf.
Desde el punto de la estabilidad, el uso de httperf permite encontrar más rápidamente los puntos de saturación que con las otras herramientas suele disimularse. Fundamentalmente porque la carga es un producto de la cantidad de usuarios concurrentes por los requests que realiza cada uno. Así que fijar una carga de esta manera implica cantidad de usuarios pero también un comportamiento esperado. En cambio, la tasa de requests por segundo bruta es un indicador más directo del umbral que soporta el server y de los efectos bola de nieve que se producen cuando se encuentra la saturación. Permitiendo encontrar además otros indicadores paralelos en CPU y memoria, pudiéndose validar la cercanía a un punto de quiebre/saturación directamente en un access.log.

Claro que existen también herramientas pagas -algunas incluso muy costosas- pero entendemos que, a menos que necesitemos alguna funcionalidad específica que estas herramientas puedan proveer, para las pruebas básicas de Performance que podemos hacer desde Testing, las mencionadas arriba son más que suficientes.

Las principales ventajas:

  • Son gratuitas
  • No requieren de demasiado tiempo ni esfuerzo para dominar sus funcionalidades básicas
  • Ofrecen flexibilidad para obtener reportes e información de performance con diferentes indicadores

En próximos posts iremos profundizando sobre algunas de las pruebas de performance típicas, como planificarlas, ejecutarlas, reportar y los aspectos a tener en cuenta en cada una.

 

 

Cuál es el verdadero valor de un curso?

¿Estás pagando por algo que podrías tener gratis?

Con la masificación de las nuevas tecnologías, aunada a la necesidad de encontrar una salida laboral rápida, la oferta de cursos de capacitación ha crecido enormemente. Han surgido numerosas empresas de capacitación, con la favorable consecuencia de que se puede elegir. Sin embargo, no todas las opciones son igualmente valiosas, y habría que someterlo a un breve análisis, para determinar cuál es la elección más conveniente.
Sabemos que hoy en día todo se puede encontrar en Internet, que ha facilitado enormemente la difusión de conocimientos y que, además, es el reino de la copia y la duplicación. Así, no sólo es posible descargar manuales y libros de cualquier tema, sino que además, cuando uno comienza a buscar, encuentra que numerosos sitios ofrecen cursos “gratis” de lo que sea. Normalmente, estos cursos son auto-guiados, es decir, que uno mismo debe ocuparse de leer el material (o mirar videos) y auto-evaluarse. Bastante parecido a leer un libro o un manual en los ratos libres o en el viaje en subte.
Por otro lado, existen algunas empresas de Educación en IT que cobran por cursos de capacitación que en realidad son dictados por algún “recién llegado”, que se aprendió el tema a las corridas, y que se limita a repetir el material (muchas veces copiado de otro lado), como un robot. Incluso, suele suceder, que la misma persona que “enseña”, por ejemplo, Testing, dicta también los cursos de Java, Excel y reparación de celulares. Esto, que parece un chiste, es fácilmente verificable entrando a la Web de alguna de estas empresas de Educación en IT.
En estos casos, nos preguntamos, ¿cuál es la diferencia con el curso gratuito? Los asistentes a estos cursos, ¿no están pagando por algo que podrían tener gratis? A grandes rasgos, creemos que sí, dado que están adquiriendo un producto que les aporta muy poco valor y les dará poco beneficio cuando se encuentren con la realidad de la práctica profesional.
Entonces, debemos volver a la pregunta del título: ¿cuál es el verdadero valor de un curso?

 

Creemos que tiene una respuesta muy simple: el verdadero valor de un curso está en la experiencia que pueden aportar quienes lo dictan. Los conceptos teóricos, impartidos por sí solos, además de que pueden encontrarse fácilmente en cualquier parte (y gratis), no tienen más valor que el leer un libro. Es decir, sólo nos van a aportar la base teórica, que es tan importante, pero a la que se necesita sumar la experiencia para poder aplicarla a la práctica, sobre todo cuando uno pretende alcanzar la tan mentada “salida laboral”.
Los profesionales que integramos QAbility, aparte de que nos dedicamos específicamente al Testing y la Calidad, contamos con más de 20 años de experiencia como profesionales reconocidos en el mercado y, lo más importante, seguimos en la actividad profesional, resolviendo día a día los desafíos que nuestras actividades nos presentan. Es así que, a cada uno de los conceptos teóricos, podemos enriquecerlos con ejemplos y casos de la “vida real”, a partir de nuestras experiencias en la práctica. El asistente a nuestros cursos se lleva un valor agregado que va mucho más allá de la simple lectura de un manual. Cuenta con la base teórica, desde ya, pero enriquecida con el conocimiento de cómo se aplica cada concepto en la práctica. Esto es de enorme valor a la hora de encarar la actividad profesional en proyectos reales, donde la mayoría de las veces la realidad que uno encuentra difiere bastante de lo que dicen los libros y, por lo tanto, la aplicación directa de la teoría de poco sirve.
Por todo esto, a la hora de elegir un curso de capacitación, les recomendamos investigar la trayectoria y experiencia de quienes lo dictan. Incluso, no tener miedo de preguntar y solicitar los antecedentes profesionales de los capacitadores, para asegurarse de que son capaces de agregar verdadero valor al curso. De lo contrario, para incorporar solamente la teoría, nuestro consejo es no pagar por algo que se puede conseguir gratis.

Una visión del equipo de QA sobre el rediseño de TN 2016

Y acá estamos… después de otro gran hito, nos encontramos escribiendo nuevamente una nota para el Blog Dev… ¡Para contarles sobre el trabajo que hicimos con la nueva Web de TN!

Esta vez desarrollamos una nueva versión de las aplicaciones nativas (Android / iOS), un nuevo backoffice para la redacción de TN.com.ar, el sitio web para escritorio, el sitio web para móviles y los nuevos Instant Articles de TN en Facebook.

Esta nueva entrega vino a reemplazar un producto que tuvimos más de 3 años online, que fue premiado y reconocido tanto aquí, en nuestro país como afuera en varias ocasiones. Ahora tenemos la misión de superar esos logros e ir por mucho más.

La idea del post es enfocarnos en QA (Quality Assurance) y contar cómo se trabajó durante los 8 meses de desarrollo del proyecto desde nuestro equipo y cómo hemos adaptado las áreas y los procesos al nuevo marco metodológico. Esta vez, y a diferencia del 2013, todo el desarrollo del proyecto lo hicimos íntegramente basados en una Metodología Ágil: Scrum.

¿De qué hablamos cuando hablamos de Scrum? Es el marco metodológico de desarrollo de software más divulgado y sus características más importantes son:

  • Estrategia de desarrollo incremental, en lugar de ejecución completa del producto.
  • Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

Repasemos parecidos y diferencias entre los proyectos: ‘Rediseño 2013’ y ‘Rediseño 2016’.

  • Ambos proyectos duraron 8 meses en su fase de desarrollo.
  • En ‘Rediseño 2013’ participaron alrededor de 20 personas mientras que en ‘Rediseño 2016’ cerca de 60, entre desarrolladores, testers, diseñadores, periodistas, editores, etc.
  • En ‘Rediseño 2013’ se trabajaba con metodología tradicional, algo tipo Cascada, donde el testing venía luego de la entrega de cada nueva versión.
  • En cambio en ‘Rediseño 2016’ hubo testing constante, de Sprint a Sprint y durante todo el proyecto.
  • Esta metodología además permitió que se pueda sostener con sólo 3 QA’s (1 menos que en 2013!) un equipo de desarrollo y producto que creció a más del doble. Con una proporción aproximada de 1 QA por cada 4 ó 5 desarrolladores.
  • ‘Rediseño 2016’ tuvo el triple de issues (UserStories, Tareas, Subtareas, Defectos, Mejoras), que ‘Rediseño 2013’; ésto pudo tener varias explicaciones:

– Este nuevo proyecto fue mucho más ambicioso: Todo un nuevo Backoffice / Rediseño completo de Frontend para Desktop y Webmobile / Nueva versión de las Apps / Instant Articles Facebook

– Todos los Requerimientos, representados en UserStories, se documentaron en la misma herramienta donde se hizo todo el tracking de todo el proyecto, llegando a ser el 25% de los issues totales.

– Se discriminaron mejor las Tareas de desarrollo:

  • Por Plataforma: Desktop / Webmobile / Apps / Backoffice / Backend / IA FB
  • Tipo de Contenido: Vivos / VOD / Fotos / Galerías / Gifs / Audios / MaM

– Desarrollo gestionó y documentó de mejor manera las Subtareas Técnicas.

Esto hizo que comparando ambos proyectos, en la relación Defectos/Mejoras reportadas, y comparándola con su cantidad total de issues, mejoró rotundamente, ya que:

captura1

Entre los 3 QA’s hemos reportado 697 Defectos y Mejoras, los cuales representan el 33% de los issues totales de todo el proyecto.

Siendo los componentes Desktop / Webmobile los que concentraron el 44% de los defectos, siguiéndole Backoffice que concentró el 20% de los mismos.

captura3

Conclusión:

Encontramos una mejora significativa en el Proceso de Trabajo respecto de hace 3 años.

Todo ésto gracias a la capacidad de adaptación de las personas del equipo y a su enorme voluntad por generar mejores productos y procesos, amparados sobre una metodología que funciona!!