¿Por qué los desarrolladores de software generalmente subestiman el trabajo de los probadores? ¿Qué se puede hacer para mejorar esta relación?

La próxima vez que presente ese error, junto con él, adjunte el parche para la solución también. 😛

Bromas aparte, creo que solo se puede hacer exigiendo respeto mutuo el uno al otro. Es más un rasgo de personalidad conductual.

• Los gerentes / desarrolladores senior deben asesorar a los desarrolladores jóvenes sobre esto. Si ven jóvenes desarrolladores arrogantes, necesitan llevarlos a un lado y explicárselos.
• No se presente como un demonio frente al desarrollador, sino como un colaborador. Intenta responder, cuál es el bien mayor, y retrata el error / defecto desde esa perspectiva.
• Nunca lo conviertas en un ataque personal. En el momento en que se vuelve personal, no se trata del código / aplicación sino de la persona.
• Muestra tu inteligencia cuando puedas. La triste percepción general es ese ligero complejo de superioridad intelectual que tienen los desarrolladores. (No voy a debatirlo), pero si quieres disipar esa duda, muestra tu inteligencia. ¡Se innovador!

Recuerde, solo está en manos de Devs y QA tener una relación saludable.

Pienso en el control de calidad como asistencia de calidad.
Dejo en claro que estoy allí para ayudar al desarrollador a través de mis acciones.
Le predico a mi equipo de control de calidad que estamos allí para ayudar al desarrollador a hacer un mejor trabajo. No trabajamos contra el desarrollador. No les decimos que su código apesta, nunca. Si realmente lo hace, todavía no es asunto nuestro. Solo nos importa cómo funciona y hace el trabajo.
En cada empresa en la que he trabajado, los desarrolladores fueron mis mejores amigos. Y ellos me aman. Puedo darte ejemplos de cuándo mis desarrolladores lucharon para mantenerme en el equipo (se sintió increíble).
También he trabajado en empresas donde los equipos de control de calidad y DEV son archirrivales. Por ejemplo: cuando había algunas instrucciones no actualizadas en las notas de la versión, el equipo de control de calidad simplemente enviaba las notas de la versión y retrasaba la fecha y creaba una escena en la que perdía su valioso tiempo. El desarrollador tardó solo 2 minutos en corregir las instrucciones (honestamente, estaba claro qué pasos también debían actualizarse al control de calidad). Pero el control de calidad volvió a las tareas solo después de un día. En momentos como este, el hecho de ser QA socavaría totalmente a todo el equipo de QA. ¿Contra qué diablos estamos trabajando? ¿El uno al otro? ¿No sabemos que unidos estamos y divididos caemos?
Oh! Por cierto, cuando estaba a cargo, y sucedió el mismo incidente, simplemente me acerqué al desarrollador y reparé las instrucciones y completé las pruebas a tiempo y encontré más errores y los solucioné también. Pero se corrió la voz de que hablé con el desarrollador en lugar de crear una escena. Y me dieron una conferencia sobre los procedimientos.
Puedes trabajar con imbéciles que no conocen mejor, pero no puedes trabajar con oxímoron, ellos saben lo que es mejor pero no lo harán.

Los evaluadores manuales generalmente son menospreciados a menos que muestren una atención perfecta a los detalles porque incluso un chico de 13 años puede hacer el mismo trabajo (74% de los niños de Bangalore ~ ​​13 tienen una cuenta de Facebook)

Pero los probadores que automatizan las cosas, siento que son lo mismo que los desarrolladores.

También los evaluadores encuentran fallas en el trabajo de los desarrolladores. En una empresa, si un desarrollador es calificado por la cantidad de errores que los probadores encuentran en su código, se convierten en enemigos naturales de los desarrolladores. El salario mensual que gano depende de lo estúpido que sea un probador. Y aparentemente los evaluadores no pueden hacer un trabajo lo suficientemente completo, es decir, no prestan suficiente atención a los detalles.

Consulte los puntos mencionados aquí: http: //enjoytesting.files.wordpr …

Esto podría ayudar a mejorar la relación entre los dos equipos 🙂