Comunicación Tester-Desarrollador

Si bien se ha escrito mucho sobre las comunicaciones desarrollador-desarrollador, desarrollador-cliente, gerente del equipo desarrollador, no pude encontrar ningún texto que brinde pautas sobre la comunicación y relación entre probador y desarrollador.

Ya sea que los evaluadores y desarrolladores sean equipos separados o en el mismo (en mi caso, soy un evaluador solitario en un proyecto de desarrollo ágil), creo que la forma en que se perciben los evaluadores es extremadamente importante para que las pruebas sean bien aceptadas y para cumplir su objetivo de mejorar la calidad del proyecto (por ejemplo, no deben considerarse como una fuerza policial).

¿Algún consejo o estudio sobre cómo un probador debe comunicarse con los desarrolladores?

Actualización : Gracias a todos por sus respuestas. Todos confirmaron lo que tenía en mente. Por ahora, mi equipo era muy receptivo a mi papel y terminamos haciendo un progreso real. Podría haber elegido más de una como respuesta, pero tuve que tomar una decisión.

La forma más fácil de mejorar la comunicación es trabajar junto con sus desarrolladores (y diseñadores y arquitectos, etc.) y desglosar lentamente esos roles tontos y eventualmente darse cuenta de que todos somos probadores, excepto que algunos de nosotros tenemos más experiencia que otros.

Para ágil, simplemente hazlo "por el libro". Los probadores son parte del equipo y no solo una entidad externa a la que entregas cosas cuando está hecho. Su valiosa experiencia se utiliza durante todo el desarrollo. Primero, cuando creas historias de usuarios, ayudas a derivar pruebas de aceptación y a automatizarlas. Luego, los desarrolladores utilizan estas pruebas en su trabajo. También pasa tiempo a diario para realizar pruebas exploratorias de trabajos parciales y completados, y habla con la OP para aclarar y mejorar sus pruebas continuamente.

A eso me refiero cuando hablo de "trabajar juntos". Estoy completamente seguro de que así es como debería funcionar la comunicación en un equipo. Este artículo lo explica muy bien por cierto.

Frente a esto, a muchas organizaciones les gusta manejar el desarrollo colocando a todos los evaluadores (y DBA, y diseñadores y programadores) en departamentos separados. Esto funciona en contra de la comunicación y solo sirve para consolidar la idea del desarrollo por etapas. Intentar mejorar la comunicación en tal situación es posible, pero las pequeñas mejoras que puede esperar no valen la pena. Al menos no en comparación con poner a las personas en la misma sala y crear equipos interfuncionales.

Creo firmemente en CUALQUIER tipo de comunicación entre dev y test.

Muchas veces he visto peleas de bollos entre cada equipo, mezquinas de un lado a otro ("cerrado por diseño", seguido de "reabierto", etc.).

Siempre les digo a los probadores con los que trabajo que vengan a hablarme si tienen alguna duda.

Una cosa que realmente ODIO es que los desarrolladores se vuelvan arrogantes con respecto a las pruebas y hablen al respecto, por lo que cualquier cosa que pueda hacer para fomentar buenas relaciones con los equipos de prueba, trato de hacerlo.

Un probador debe ser muy claro y preciso con los desarrolladores al comunicarse sobre errores y pruebas. Una lista detallada de los pasos para reproducir el error, capturas de pantalla si es necesario ... Las descripciones vagas de los errores que no pueden reproducirse o que no tienen pasos claros para reproducirse agriarán muy rápidamente la relación desarrollador-evaluador.

Nunca solía creer que siempre hay un nivel de desacuerdo entre el desarrollador y el evaluador, pero tuve que enfrentar esta situación cuando uno de mi mejor amigo obtuvo el rol de evaluador en la empresa en la que estaba trabajando y, para mi sorpresa, se le asignó el mismo módulo para probar que estaba desarrollando y, por lo tanto, fue real FUNtrabajar con él y debo decir que es muy importante comprender la opinión de otra persona en tal situación y tener control sobre el propio ego, esto me ayudó mucho y los muchachos trabajamos bien con nuestro profesional compromisos, así como el nivel de amistad personal.

Dado que usted declaró que es un probador único en un entorno ágil (suponiendo que Scrum), tal vez sea posible aprovechar la reunión retrospectiva como un foro abierto para definir el proceso de comunicación.

Como saben, la reunión retrospectiva es para abordar las arrugas dentro del proceso Scrum. Estos podrían ser elementos como permitir a los desarrolladores horas XY de tiempo ininterrumpido, comunicación solo por correo electrónico los lunes y verbal el resto de la semana, lo que sea adecuado para SU equipo; como la comunicación nunca es un enfoque único para todos.

Como desarrollador, aprecio un probador que muestre iniciativa. No dibujan líneas ... quieren que se resuelva el defecto; independientemente de la causa raíz. Los desarrolladores y evaluadores tienen que separar los sentimientos de los negocios. Los defectos son parte del negocio ya que los humanos están involucrados. El mejor enfoque para la resolución de defectos es un equipo alineado establecido para resolver los defectos de manera integral. Cuando las líneas comienzan a emerger y se trazan bordes; la comunicación se romperá

Aproveche sus reuniones diarias de pie. Participe tanto como sea posible; no solo con las pruebas sino también con el producto en su totalidad. Al final del día, un desarrollador y un probador están trabajando en un objetivo y siempre deben mantenerlo enfocado.

Prefiero ver probadores como parte del mismo equipo. En ese sentido no hay problema de comunicación.

Siempre que un probador tenga que hablar con un desarrollador o al revés, simplemente venga y hablemos. Solo una rutina de todos los días.

Sin embargo, ambas partes deben respetarse mutuamente y hacer su trabajo correctamente.

Los probadores deben proporcionar detalles detallados sobre las condiciones del error y no informar algo como un error mientras sea por diseño. Especialmente cuando solo se necesita preguntarle al tipo por algo que parece sospechosamente una característica.

Los desarrolladores deben tomarse en serio un informe de error e investigar en profundidad no solo cerrar el problema si no reproduce el error en cinco clics.

La actitud profesional es todo lo que se necesita.

La herramienta número 1 que he encontrado que yo, como probador (SDET), puedo aprovechar para mejorar las relaciones entre los desarrolladores y los desarrolladores es la adulación honesta, especialmente en la forma de buscar la tutoría de los desarrolladores.

Con suerte, los desarrolladores con los que trabajo son mejores desarrolladores que yo. No son perfectos, o no tendría un trabajo, pero hay muchas cosas que saben mejor que yo. Han sido puro desarrollo, mientras que mi atención se centra parcialmente en las pruebas. Tomo nota de esas cosas que hacen mejor, y las menciono con frecuencia. Cuando leo su código, noto detalles elegantes o usos claros de los patrones de diseño y los menciono en la conversación. Imito a los desarrolladores, usando convenciones de codificación similares cuando es posible, e integrando componentes de producción en mis herramientas de prueba cuando es apropiado (por ejemplo, registro). Reconozco su experiencia y, como resultado, están felices de reconocer la mía. Eso sí, si creo que hay una mejor manera de hacer las cosas, entonces definitivamente hablo, pero pretendo dar más comentarios positivos que negativos, en general. En general, trato de hacer que la retroalimentación negativa sea más formal e impersonal (por ejemplo, informes de errores) y la retroalimentación positiva sea menos formal y más personal (por ejemplo, conversaciones en persona).

Dar retroalimentación positiva sobre la calidad, así como retroalimentación negativa y pedir consejo cambia la relación de ser contencioso a ser sobre trabajo en equipo y aprendizaje mutuo y disminuye la actitud defensiva. Los desarrolladores saben que pueden confiar en mí para que siempre diga más cosas buenas que malas, por lo que se sienten cómodos escuchándome. Además, hacer preguntas perspicaces sobre el desarrollo plantea su opinión sobre mí y rompe el estereotipo "Los SDET son desarrolladores fallidos" (donde todavía existe).

Creo firmemente que una buena comunicación entre desarrolladores y evaluadores es crítica. En cuanto a la mejor manera de hacerlo, estoy seguro de que hay muchos buenos enfoques, pero esto es lo que mejor me ha funcionado.

¡Comunicación directa / personal! He descubierto que la comunicación personal, no por correo electrónico, siempre funciona mejor. Permite al desarrollador y al probador formar una relación personal. Una vez que tienes eso, las cosas parecen funcionar mejor y tienden a fluir. Nunca tienen problemas para realizar una prueba especial o hacer un esfuerzo adicional por usted. Lo mismo ocurre con el desarrollador y siempre me tomo el tiempo extra para ver las cosas en las que necesitan ayuda o con las que tienen problemas. En mi experiencia, hace que la resolución de problemas sea más rápida, hay menos tiempo perdido.