Hacer tests, validar que tu aplicación funciona y no tiene fallos hoy en día ya no es suficiente… en el mundo en que estamos, bombardeados de información continuamente, hay que validar que lo que se envía al cliente no solo funciona, sino que los datos tienen sentido.

Pongamos un par de ejemplos de 2 webs que tienen cierto éxito: Groupalia y emagister. Ambas envían mails periódicos con información sobre actividades o cursos.Pues bien, en Groupalia he recibido mails con ofertas como la siguiente:

Como pueden enviar una oferta donde el descuento es del 0%?

Y en emagister, tras haber pedido información de un curso, recibo ofertas de otros 2 cursos… bueno, si se pueden llamar cursos:

En este momento, pensé, bueno, quizá el envío de mail funciona mal… pero este curso realmente no existe en la base de datos de producción… craso error! Porque si entramos en el curso… funciona! He de decir que he estado tentado de comprar un “curso 1 – Probando el chiringuito”.

Por favor, señores directivos… han de tomar conciencia ya de que los datos de producción se han de controlar. Tener una misma base de datos para test y producción nunca ha sido ni será una buena práctica.

Mi consejo… ahorren unos dinerillos y pongan bases de datos aisladas para entornos de test, les ahorrará muchos dolores de cabeza, y se ahorrarán quedar en ridículo ante sus clientes.

Por otra parte, en empresas como estas que hemos visto, no estaría mal tener un tester que haga una gestión del contenido de lo que se envía al cliente. Un tester que validara no solo que lo que se envía al cliente está libre de errores, sino que validara que lo que se envía tiene sentido desde el punto de vista de negocio (las prioridades de las ofertas están correctas, etc…), por decirlo fácilmente, lo mismo que sería un test de usabilidad, pero aplicado al contenido.

Debido a que durante el desarrollo de cualquier producto software se identifican un gran número de defectos, en muchos casos de alta prioridad o prioridad crítica, un equipo para la revisión de defectos (Defects Review Team) es esencial en cualquier equipo de testing.

Un DRT (Defects Review Team) proporciona una rápida y eficiente respuesta a un defecto en cualquiera de nuestros entornos y garantiza una oportuna solución. El equipo estará integrado por los siguientes miembros:

• Responsable del equipo de desarrollo (Development team leader).
• Jefe de proyecto (Project manager).
• Responsable del equipo de pruebas (QA team lead).
• Cliente (Opcional). Es importante que el cliente forme parte de este equipo, aunque no siempre es posible su participación.

Plan de acción:

Lo primero que debemos hacer es establecer un plan de acción. Podemos establecer reuniones semanales para discutir los defectos más importantes…pero claro, una revisión semanal en algunos casos puede no ser suficiente, y una reunión diaria puede ser deficil de conseguir. ¿Que podríamos hacer? Podemos establecer como norma, una reunión semanal y después, cada miembro del equipo se debe comprometer a revisar diariamente los defectos. En caso de que sea necesario se pueden establecer reuniones ocasionales si fuese requerido.

Nuestro plan de acción:

1. Todos los miembros del DRT deben de ser notificados, por ejemplo via email, de todos los defectos de prioridad alta y crítica.
2. Semanalmente se discuten los defectos más importantes. Los defectos ya existentes se revisan para asegurarnos que el defecto no está duplicado.
3. Si el defecto es válido, se introduce en nuestro DTS (Defect Tracking System) como “OPEN” (más tarde serán asignados por el responsable de desarrollo).
4. Se revisan los defectos críticos que deberían haber sido arreglados y que aún no están solucionados. Se analizan las causas y se establece un plan de acción, ¿como podemos arreglar lo antes posible?.
5. Haremos análisis a largo plazo…¿Que acciones debemos tomar para que defectos así no vuelvan a repetirse?.
6. Debemos de establecer timelines en la resolución de defectos a corto plazo.

Cualquiera que haya sido programador probablemente ha recibido defectos mal reportados. Defectos que no dicen nada ( “No funciona!”); que no tiene sentido; que no dan suficiente información; que dan información errónea. Defectos que resultan ser error del usuario, problemas que son culpa de otro componente del programa; o que resultan ser un problema de red.

Tenemos que distinguir claramente hechos reales de especulaciones. Debemos dejar a un lado las especulaciones, frases como: “Yo creo que el problema podría ser…”, y ceñirnos a los hechos, a lo que ha ocurrido.

¿Que debe incluir el reporte de un defecto?:

1. Título del defecto: Una frase corta que describa el defecto. El título puede ser la parte más importante del defecto ya que en los meetings de revisiones de defectos lo primero que se lee es el título del defecto y en función de el se puede tomar la decisión erronea de rechazarlo(“rejected”, “referred”…). Debemos recordar que en este tipo de meetings se revisan muchos defectos y no hay tiempo de leer en detalle todo los pasos del defecto. Es por ello que el título puede ser determinante.
2. Breve descripción: intenta describir el defecto en dos o tres frases.
3. Pasos para reproducirlo: introducir todos los pasos, debe de ser lo suficientemente explicativo para que el desarrollador pueda reproducirlo fácilmente. Pasos claros que no resulten ambiguos
4. Resultado actual: describe lo que realmente ha ocurrido.
5. Resultado esperado: describe lo que debería de haber pasado.
6. Adjuntar toda la información que sea posible: logs, screenshots o cualquier otra información adicional que creamos puede ayudar al desarrollador a la hora de identificar el problema.

Describir un defecto no es difícil, pero si requiere un poco de sentido común. He visto defectos demasiado extensos y otros que apenas ocupan unas lineas…un defecto no debería añadir una sobrecarga de trabajo a los desarrolladores, sino ayudarles a reproducir el error y resolverlo de manera efectiva en el menor tiempo posible.

Lo que en principio puede parecer una afirmación bastante lógica no siempre es así. En muchas ocasiones son los propios desarrolladores o jefes de proyectos los que, “alegremente”, cierran defectos que no han sido verificados por testing. Un defecto marcado como “Arreglado” (Fixed-Ready to test), debe de ser siempre verificado por el equipo de testing. Si el defecto es “rechazado” por no ser considerado un defecto, el tester deberá de pedir más información sobre el defecto para así realmente verificar que no se trata de un defecto y estar de acuerdo con la decisión. Si el defecto es rechazado por ser considerado “duplicado”, el tester deberá verificar que efectivamente el defecto existe y que efectivamente está duplicado. En muchos proyectos los desarrolladores tienden a esconder los defectos refugiándose en que el defecto está duplicado.

El tester que normalmente encuentra un defecto lo retesteará, pero si el defecto viene de una persona ajena al equipo de pruebas entonces el tester deberá de evaluar e intentar reproducir el defecto. Un defecto no debe ser cerrado si no ha sido revisado por el equipo de testing.

¿Como podemos evitar esta situación? Es importante definir apropiadamente el ciclo de vida de un defecto. Debe de ser añadido como un proceso más a nuestra estrategia de pruebas. Por ejemplo, todo defecto, como mínimo, pasa por los siguientes estados:

1. Abierto
2. Asignado
3. Arreglado
4. Listo para ser testeado
5. Cerrado

A estos estados debemos añadir unos sub-estados:

1. Rechazado, una vez se ha encontrado el defecto es revisado. Si no se considera un defecto, pasaría al estado de “Rechazado”.
2. Reabierto, este sub-estado ocurre cuando se testea un defecto y todavía no está debidamente arreglado.

Como había comentado anteriormente, estos estados son sólo un ejemplo…dependiendo de las necesidades de vuestra empresa este ciclo de vida variará. Adjunto un ejemplo de los diferentes estados en los que puede estar un defecto:

JIRA es una herramienta de gestión de defectos y projectos. En otras ocasiones habíamos hablado de herramientas de este tipo pero de código abierto (open source) y por lo tanto gratuitas. Este no es le caso de JIRA, que es de pago…y desde mi punto de vista, un poco cara.

Aún así, me gustaría analizar esta herramienta ya que es otra opción disponible en el mercado. Además, en la web oficial podreís hacer un tour ó probarla Online.

Destacaría de esta herramienta la posibilidad de crear Workflows, permitiendote definir los procesos de tu compañia a todos los niveles, departamentos, proyectos, a nivel de defectos. A la hora de crear nuevos defectos, podemos hacerlo incluso via email, esto os puede permitir que el help desk ó el propio cliente introduzca defecto encontrados en producción. También nos permite asignar un defecto a dos desarrolladores, opción que me parece bastante útil.

Por último destacar que el JIRA integra un sistema de email. Este sistema te permite, además de envio regular de emails, la posibilidad por ejemplo de decirle a la aplicación que te alerte cada mañana de los defectos de mayor prioridad.

Y por supuesto, JIRA incluye un sistema de gestión de usuarios, administración, internalización y costomización además de un alto nivel de seguridad

En resumen, JIRA es una herramienta muy potente que te permite no sólo introducir defectos sino también gestionarlos. Aunque por el precio siempre tendreis el Mantis, que no es tan potente pero que es gratuito.

Podeis encontrar más información sobre esta herramienta en: http://www.atlassian.com/software/jira/

También tienen una aplicacioón para hacer integración continua ( Bamboo )…bastante cara también.