Sumario ->
Se propone discutir acerca de la importancia que tiene la comunicación durante el proceso de pruebas del software asignado, y cómo los equipos de test tienen que ser capaces de entender los aspectos funcionales y técnicos del negocio, además de saber interactuar con los distintos stakeholders del proyecto.
Desarrollo
Cada día se hace más importante, a mi modo de ver, poder crear/recrear/mantener/afianzar una buena comunicación no sólo entre nuestros pares sino además con nuestros clientes (internos y/o externos).
Si bien contamos con más herramientas y entornos de trabajo que nos permiten no solo mantener comunicación de manera remota (por chat y/o por videoconferencia) sino además, compartir archivos de trabajo con nuestros compañeros y/o clientes; todas estas actividades requiere una cierta prolijidad de nuestra parte, organización, respetar normas de calidad, administrar el tiempo y saber escribir y comunicarnos adecuadamente para que entiendan el mensaje que queremos trasmitir.
La comunicación oral y/o escrita, es un ejercicio diario que puede adquirirse y hay cursos que permiten adquirir las denominadas ‘habilidades blandas’, como por ejemplo la redacción de informes, sino además para administrar tiempos, para lograr una comunicación eficaz, etc etc etc.
Indudablemente la comunicación es muy importante durante el proceso de pruebas del software.
El equipo de QA (como en algunas empresas lo denominan) deben ser capaces de entender los aspectos funcionales y técnicos del negocio sobre el cual se aplica el software que tiene que testear, comprender las limitaciones y restricciones de la tecnología y poder comunicarse de forma efectiva y eficaz con los distintos stakeholders del proyecto, como son:
– el Analista Funcional
– el Desarrollador
– el Arquitecto
– el Operador
– el Responsable del Proyecto
– el Responsable Comercial
– el Usuario final
Lograr todo ésto no es tan sencillo ya que no siempre se logra esta sintonía entre cada una de las personas que participan en el proyecto.
Cuando hay que establecer un Equipo de QA en una empresa y por ende, en sus respectivos proyectos para atender a sus clientes (internos y/o externos), se deben fijar y acordar/negociar la política y procedimientos de QA, ya que nuestra actividad puede darse verticalmente y/o atravesando horizontalmente todas las gerencias involucradas.
Establecer los criterios de trabajo y la forma de comunicación no es tarea sencilla, ya que a nadie le gusta -a decir verdad aunque digan muchos lo contrario- que se han equivocado y que se ha cometido un error. No en vano figuran estos aspectos en el Foundation Level Syllabus como: (a) La psicología de las pruebas y (b) El código deontológico.
Por otra parte, a pesar de tener estos criterios y forma de comunicación establecida, nada ni nadie nos garantiza que haya que ir haciendo ajustes a medida que uno va interactuando y progresando con el testing asignado.
A continuación, expongo algunas claves que pueden evaluarse para manejar ciertas situaciones que se dan durante la ejecución de un proyecto (no tienen ningún ordenamiento) y que permiten mejorar la comunicación entre las partes:
– Charlas ‘face to face’ es mucho más provechoso que intercambio de correos interminables.
– Video Conferencias para Proyectos Distribuídos es la opción mandatoria.
– Acercarse al analista o al desarrollador para ‘discutir’ -en el buen sentido de la palabra- un requerimiento, vale más que un chat o un correo electrónico.
– Definir reuniones de avance de 15 minutos diarios entre el analista y/o desarrollador, para instancias de proyectos críticos, puede ser una buena alternativa.
– Adelantar la Agenda de una reunión de manera tal de exponer el objetivo y alcance de la misma (Recomendación: escribir los títulos de los temas y ser lo más cortos posibles)
– Armar una Minuta de reunión lo más concreta posible y ofreciendo al principio de la misma los resultados obtenidos, si se alcanzó o nó con el objetivo y alcance, y la próxima fecha de reunión (Recomendación: enviar una copia a todos los que participaron de la misma)
– Tratar de esforzarse en entender el problema que tiene tanto el Analista y/o Desarrollador, como el Usuario final a fin de componer una condición de prueba lo más acorde a la realidad para obtener el resultado esperado.
– Acordar los casos en que pueda aplicar la entrega de una Orden de Magnitud en vez de una Estimación, entendiendo que luego habrá que transitar el proceso de Estimar donde el Esfuerzo de prueba previamente entregado puede conservarse o variar en más.
– Diseñar un template para Estimar el Esfuerzo de Prueba lo suficientemente inteligente (fórmulas y macros mediante) que permita a la hora de tener que negociar, ir modificándola a pedido de nuestro cliente y que automáticamente se vayan modificando los totales de ciertas celdas para ir tomando decisiones.
– Recurrir a casos de prueba pre elaborados para la reutilización de los mismos y así acelerar los tiempos de Diseño y/o Preparación de Datos. Para esta tarea es imprescindible contar con una herramienta para la gestión de las pruebas.
– Tener un procedimiento para explicar detalladamente cómo se originó la incidencia detectada junto con la respectiva evidencia complementaria, para permitir que otras áreas pueden reproducirla.
– Antes de enviar un correo o comunicar una incidencia, en caso de tener dudas, solicitar la opinión de alguien del equipo
– Tener preparado un esquema de extracción de informes de estado cuando la parte cliente nos solicita conocer el estado del testing para un determinado requerimiento
