¿Abordar la resistencia del equipo de desarrollo a las soluciones sugeridas por el ingeniero de control de calidad?

Mi problema es que cuando identifico problemas y les digo a los desarrolladores cómo solucionarlos

Creo que está excediendo el alcance de su puesto y no me sorprende la reacción que obtiene. Su trabajo no es decirles a los desarrolladores cómo arreglar las cosas. He estado en este negocio por mucho tiempo, y nunca tuve una persona de control de calidad que me dijera cómo escribir código. Pero nunca he trabajado con personas de control de calidad que analizan el código. Eso está fuera del alcance del control de calidad.

Cuando habla con un desarrollador sobre cómo debería usar funciones de reducción de alto orden y demás, puedo decirle exactamente lo que se le pasa por la cabeza: "Si es tan bueno programando, ¿por qué no está programando ?" Toda tu publicación tiene una actitud como esa. Si eres tan bueno y ellos son tan malos, ¿por qué sigues trabajando allí?

La función principal del control de calidad es, como dijiste, identificar problemas. Lo haces a través de pruebas y análisis. Cualquier información que pueda agregar que ayude a resolver el problema siempre es buena. Pero cuidado con proponer soluciones. Recuerde, su trabajo es identificar problemas, no soluciones. Todo lo que los desarrolladores esperan del control de calidad es la mayor cantidad de información posible para resolver un problema. Si sabe cómo solucionarlo, entonces, por supuesto, proporcione detalles. Pero si todo lo que tiene es una opinión, deje claro que es una opinión, no una directiva. Escriba "Creo que es porque XYZ necesita un token en cada solicitud" o "Sospecho que estamos omitiendo el token".

¿Abordar la resistencia del equipo de desarrollo a las soluciones sugeridas por el ingeniero de control de calidad?

Como "Ingeniero en pruebas", probablemente tenga más habilidades de codificación que la mayoría de los controles de calidad, especialmente en su entorno de trabajo actual según su pregunta. Necesita habilidades de codificación para realizar pruebas automatizadas, y eso le da la falsa impresión de que esas habilidades son aceptadas y respetadas por quienes realizan el desarrollo.

Sin embargo, al hacer sugerencias sobre cómo solucionar los problemas, está sobrepasando sus límites profesionales. Tiene información y conocimiento limitados sobre el proceso de desarrollo completo. Los chicos que escriben el código tienen que ser responsables de las soluciones, así que déjenlos hacer su trabajo.

Una analogía no técnica que me gusta usar es la siguiente: si contrata a un techador para reemplazar su techo, le hará preguntas y lo observará para sentirse seguro de que está haciendo un buen trabajo. Pero si te subes al techo y comienzas a decirle al techador cómo podría estar "haciendo las cosas mejor" o lo que sea, has ido demasiado lejos y probablemente harás enojar a tu techador. Bájate del techo y deja de decirle al tipo qué hacer.

Concéntrese en construir sus sistemas e identificar los errores de los desarrolladores. Permítales identificar y seleccionar soluciones a los problemas que identifique.

Creo que necesita dividir sus comunicaciones con el desarrollo en dos:

• Informes formales de errores detectados.
• Sugerencias informales de usted a los desarrolladores sobre cómo corregirlas o prevenirlas, y sugerencias informales de los desarrolladores a usted sobre cómo probar el software.

Debe intentar construir una buena relación de trabajo con los desarrolladores. Eso puede haber sido más difícil por la forma en que comenzaste, así que retrocede durante unos meses. Comience pidiéndoles su consejo: "Creo que deberíamos hacer más pruebas de estrés del componente X. ¿Qué tipo de carga de trabajo es probable que lo sobrecargue? ¿Alguna área difícil que necesite pruebas adicionales?". Trate de construir una relación en la que el dar y el tomar consejos se vuelve normal y sin importancia.

Una vez que tenga esa relación, intente mencionar casualmente que cree que un grupo particular de fallas de prueba podría corregirse como grupo mediante algún cambio de diseño.

Primero quiero comenzar diciendo que trabajo en un campo muy similar con objetivos casi similares: Auditoría de TI. Si te entiendo correctamente, te sientes frustrado porque sientes que los demás no están prestando atención a tus consejos y que tu jefe no te apoya al insistir en las relaciones por encima de la competencia.

Cuando desea que las personas lo escuchen y tomen en serio sus comentarios, primero debe decirles cómo escucharlo los beneficiará en su trabajo. En su caso, el beneficio será un menor número de errores y un mejor funcionamiento del código que es más probable que cumpla con los objetivos comerciales. Escribir continuamente un código deficiente y negarse a mejorar cuando se le da la oportunidad demuestra desprecio, agresión y casi arrogancia en cierto sentido, como si lo hicieran mejor. Si continúa, tal comportamiento casi garantizará el despido por incompetencia y por no poder trabajar bien con los demás.

Le sugiero que asuma lo positivo: que estos desarrolladores no intentan ser hostiles por despecho. Lo más probable es que no entiendan por qué quieres que cambien . Asuma que las personas son racionales, que por mucho que no quieran cooperar, no pondrán en peligro su propio trabajo debido a este conflicto. Habla con estos desarrolladores cuando todas las partes estén tranquilas y explícales tu proceso de pensamiento: por qué quieres que cambien como lo haces tú y cómo se beneficiarán al hacerlo.

Tu jefe tampoco está siendo razonable aquí al insistir en las relaciones por encima de la competencia. Estoy totalmente en desacuerdo. Tu trabajo se refleja en tu jefe, ya sea bien o mal. Cuando su jefe se retuerce las manos de toda responsabilidad, está poniendo en riesgo su propio trabajo. Al no reconocer que la competencia y el valor agregado a través de la mejora de procesos es por lo que él y los miembros de su equipo (usted entre ellos) serán juzgados en última instancia, está mostrando un juicio notablemente pobre. La situación es desagradable, pero enterrar la cabeza en la arena no hace que el problema desaparezca.

Tu trabajo sirve como control sobre el trabajo de los demás y tienes que aceptarlo debido a este hecho: siempre habrá personas a las que no les gustes. Tome el camino correcto y no vea los comentarios como un asalto personal, sin importar cuán desagradables sean. Desarrolla una piel más dura y aprende a no reaccionar ante la hostilidad/falta de profesionalismo de los demás. A la larga, esta práctica te servirá bien.

Estoy de acuerdo con esta respuesta sobre hacer una separación clara entre los informes de problemas (su trabajo) y las sugerencias informales para abordarlos . A esto añado un enfoque más: hacer preguntas .

Soy un escritor técnico, a menudo responsable de descubrir los casos de esquina en una interfaz antes de documentar porque, como todos sabemos, ninguna especificación está 100% completa. A veces descubro un comportamiento que, digamos, no es del todo deseable: es contrario a la intuición, es inconsistente o es costoso. Me ha ido bastante bien en mi carrera explicando lo que pensé que sucedería y lo que vi en cambio, diciendo por qué me importa (si no es obvio por el contexto), compartiendo cualquier especulación que tenga sobre la causa y pidiendo información o ayuda . Puede hacer una sugerencia o plantar una semilla sin decirle a nadie qué hacer, después de todo.

He aquí un ejemplo de lo que quiero decir:

Estaba haciendo algunas pruebas de seguridad. Pensé que la solicitud de un cliente de datos del servicio sería rechazada si el usuario no está autorizado, pero pude leer los datos de todos modos. Específicamente, inicié un cliente, leí algunos datos, revoqué la autorización de ese usuario en el servidor y luego leí algunos datos más, y funcionó. ¿No revisamos en cada llamada? Si lo estamos almacenando en caché, ¿especificamos cuánto tiempo entre las nuevas comprobaciones o no se especifica? Quiero asegurarme de explicar esto claramente en la documentación de administración.

Supongamos que la respuesta es que el estado de autorización se almacena en caché en el servidor y el desarrollador no quiere ofrecer más garantías. Para continuar la conversación:

Gracias; Entiendo. Entonces, si un administrador del servidor quiere asegurarse de que una revocación surta efecto de inmediato, porque tal vez sea una situación de alto riesgo, ¿hay alguna forma de que pueda vaciar el caché? ¿O necesita abandonar la sesión y hacer que el cliente se vuelva a conectar?

Lo que hemos hecho aquí es describir el problema del usuario y pensar en voz alta sobre las formas en que, con el software tal como está, puede resolverlo. Un desarrollador que pensó que un pequeño retraso en la actualización de la autorización no es gran cosa podría pensar de nuevo si la respuesta es reiniciar una sesión de cliente, tal vez eso sea demasiado pesado. O tal vez eso está perfectamente bien, y aprenderá que las sesiones con los clientes deben ser breves, efímeras y renovadas con frecuencia, en cuyo caso habrá aprendido algo sobre el diseño.

Usted y el desarrollador son compañeros con diferentes especialidades. Ninguno de los dos debe dictar al otro cómo hacer su trabajo, pero ambos deben estar abiertos a compartir, aprender y trabajar juntos para resolver los problemas de sus clientes.

Como se ha sugerido, la mejor estrategia puede ser dar un paso atrás y contener su afán de decirles a todos cómo arreglar las cosas y, en cambio, centrarse en identificar, documentar y probar las soluciones a los problemas.

También en este caso particular, la cultura del lugar de trabajo podría priorizar la antigüedad y la división del trabajo sobre la competencia. Ganarse el respeto en un entorno así puede ser un proceso a largo plazo y una batalla cuesta arriba, que requiere más tiempo y esfuerzo del que se hubiera necesitado en un lugar de trabajo diferente. Parece que la gerencia es cómplice, valorando el statu quo sobre la adaptación y el cambio.

Me pregunto si este patrón habría cambiado si la necesidad comercial impulsara la velocidad de las correcciones de errores, es decir, si los errores estuvieran causando retrasos evidentes y medibles y quejas de los clientes. Esto sería difícil de abordar hasta que cambien los incentivos, pero es probable que esté fuera de su control. Si cree que esto indica una disfunción en el lugar de trabajo actual y continúa desmotivándolo sin esperanza de revertir la tendencia, hasta el punto de renunciar, puede ser el momento de considerar otras opciones de empleo.

Sin embargo, hay una serie de cambios en su comportamiento que parecen valer la pena probar antes de descartar la situación actual como irreparable. Lo animo a que primero dé un paso atrás y revise su propio enfoque de este proceso, y preste atención a los consejos sobre cómo evitar dar demasiados consejos sobre las correcciones a menos que lo solicite el equipo de desarrollo.