¿Que tal es tu relación con el equipo de desarrollo? Si tu respuesta es mala, tienes un serio problema. Cierto es que existe el mito de que la gente de testing y los desarrolladores no se llevan bien, pero es eso, un mito. En todos los años que he estado haciendo testing nunca he tenido ningún problema grave con la gente de desarrollo con la que he trabajo. Me imagino que todo depende también de la personalidad de cada uno y del tipo de empresa. Por lo general, los equipos de desarrollo interactuan con los de testing para temas relacionados con defectos. A nadie le agrada que le digan que no hace su trabajo correctamente, pero en realidad (aunque ellos crean que es así) nuestra labor es encontrar problemas en software, no quien lo ha generado. Es por eso que se debe de tener mucho tacto y sensibilidad, ya que desde su punto de vista estamos criticando su trabajo.
El libro “lessons learned in software testing” aborda este tema tan delicado. De este libro debemos aprender los siguientes puntos:
- Comprender como piensa un programador.
- Crea una relación de confianza, no de rivalidad.
- Proporcionale ayuda. Es importante que la ayuda sea mutua, y que en ningún caso se oculte información.
- A los programadores les gusta hablar sobre el trabajo que están desarrollando, hazles preguntas.
- Colabora con ellos en el testeo de la aplicación. Quieren que su aplicación funcione correctamente y no dudarán en ayudarte.
Estos son algunos de los puntos extraidos del libro…no los olvides, te pueden ser de gran ayuda y facilitarán tu trabajo. Aunque creo que ha esta lista hay que añadir el “hacerse respetar”. En algunas empresas la gente que hace test son vistos como informáticos que han fracasado en su carrera y que ahora se dedican a esto de la calidad. Demuestra que esto no es así y que tu trabajo están respetable e importante como el suyo.
Pello, gran libro! Lo recomiendo a todo aquel que haya ‘batallado’ en el mundillo de QA.
Respecto a los desarrolladores, podemos encontrar tal grado de colaboración que incluso te pidan los Test Cases que has preparado para una funcionalidad que todavía están implementando. No me importa si me ‘chafan’ unos cuantos defectos que podría haber encontrado. Nuestro objetivo no tiene que ser ‘anotarnos’ montones de defectos.. Por el contrario, leyendo nuestros casos de prueba pueden darse cuenta de que no se han interpretado los requerimientos de la misma manera y aclararlo antes de implementar.
Estas técnicas y esta colaboración siempre redunda en la calidad general del proyecto…
Ante la visita de un desarrollador para conseguir mas informacion de un issue que hemos reportado en el DTS de turno y te pregunta “Me has puesto un bug …”
Nuestra respuesta desde el lado de QA tiene que ser “El bug lo has puesto tu, yo solo lo he encontrado” Tedi dixit
Gracias por la referencia literaria
En una ocasión, un desarrollador confesó que se sentía ofendido, pues había trabajado en la release durante toda la tarde anterior y en pocos minutos habiamos reportado un bug importante.
Reflexiones:
- Ni el tester ni el desarrollador son malos; todos somos un equipo.
- Si aparece un bug importante tan rápido, las pruebas unitarias están fallando (o no se ha hecho ningún tipo de smoke test).
- Todos deberiamos alegrarnos de encontrar bugs (desarrolladores, QA y cualquier otro departamento). Si aparecen en la gestación del producto y no en el mercado, ya es un gran logro.
Una cosa a tener en cuenta es tambien la ubicaicón física de los equipos de test y desarrollo, el hecho de tener los equipos de test y desarrollo en un mismo espacio hace que las relaciones humanas mejoren y se cree un mejor clima entre el programador y el tester, y a la larga se nota en un mejor trato (por ambas partes) y en un clima de trabajo más rápido.
Por otra parte nos encontramos en casos donde el famoso outsorcing obliga a tener equipos de test y desarrollo prácticamente independientes, y esto acaba provocando tiranteces y “momentos delicados” que hace que pequeñas tonterias puedan repercutir en el desarrollo de un producto.
Pere, 100% de acuerdo. Además, estando con el resto del equipo, de vez en cuando, ‘oyes’ cosas de las que no te habías enterado, sean nuevos requerimientos o bien noticias sobre el propio proyecto. Cierto es MUY importante estar ‘colocado’ (os acordais del ‘collocation’ de HP?) junto al resto de la gente del proyecto.
Mi experiencia trabajando como Jefe de QA, es que las relaciones con el equipo de Desarrollo no son fáciles. Sin embargo, esa misma experiencia me ha hecho utilizar una estrategia que ha sido exitosa a medio plazo. Podría resumirla (a falta de personalizarla en cada caso) en los siguientes puntos:
1. Conocer a las personas de ambos equipos
2. Tratar primero con personas y profesionales, obviar el término tester o programador.
3. Analizar y mejorar los medios y formas de comunicación entre equipos
4. Acordar un vocabulario y terminología común
5. Potenciar la colaboración entre ambos equipos, con una continua y mejorada interrelación
6. Intercambiar información de interés mutuo, por ejemplo, desde QA, los procesos de Calidad que puedan servir a Desarrollo para hacer su trabajo
7. Consensuar los análisis de resultados expresados en los reportes de QA y del proyecto en general.
Actualmente, tengo un nuevo reto. Estoy en una gran compañía, pero con un concepto mal aplicado de lo que es la Gestión de la Calidad. Os iré comentando la evolución, por ahora deciros, que es un desafío con el cual estoy aprendiendo muchísimo.
Yo estuve trabajando en una consultora donde tenían un concepto de la calidad bien diferente al que tenía yo. Tenen un departamente que hace calidad IT. Basicamente hacían proyecto de implantación de CMMI y de ITIL. La mayoría de la gente que estaba allí eran lo que ellos llamaban metodólogos, ya que desarrollanban las metodología que debería usar la empresa o un proyecto en concreto. Esto, al fin y al cabo, es calidad, pero aplicada de otra manera.
De todos modos creo que esto de implantar metodologías es un gran negocio para las consultoras…