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).
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
- 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.
- 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.
http://testingbaires.com/la-importancia-de-la-comunicacion-interpersonal-para-un-tester/
No hay comentarios.:
Publicar un comentario