¿Por qué no se gustan los probadores y programadores? [cerrado]

Durante mi carrera como programador, he visto varios programadores y probadores, y muchos de ellos no se querían / ​​no se querían. Quiero decir, los programadores piensan que el trabajo de un probador no es un trabajo "real", y los probadores piensan que los programadores son demasiado "orgullosos".

¿Es esta la decisión correcta que tomé, por qué es así, y qué podemos hacer para evitar estos problemas?

Creo que es una gran generalización y simplificación.

Actualmente soy un probador, escribo casi tanto código como escribí como desarrollador (depende de la fase de prueba) y mi mejor amigo en la compañía es un desarrollador y todos nos llevamos bien.

Es posible que desee echar un vistazo a la cultura corporativa y la forma en que los equipos trabajan entre sí para encontrar su respuesta. En mi experiencia, si tiene flujos de trabajo muy reaccionarios (es decir, los desarrolladores "arrojan una construcción sobre la pared para probar" y prueban "arrojan errores") en lugar de trabajar juntos , solo desde diferentes puntos de enfoque o "vectores de ataque", entonces usted ' Descubriré que a ambos departamentos en general no les gustará el uno al otro.

Donde trabajo, cada equipo de características o equipo de diseño tiene casi tantos probadores como desarrolladores que trabajan juntos para producir resultados. Esa salida es un código de producción que cumple con los requisitos establecidos por el código de prueba.

editar

También tenga en cuenta que creo que la responsabilidad recae en el probador más que en el desarrollador para apoyar la relación entre los dos.

Es mucho más fácil para nosotros mejorar o empeorar la vida de los desarrolladores, pero el objetivo no es simplemente "encontrar errores", sino también encontrar posibles soluciones. Si no puedo, entonces no puedo, y trabajaré con quien se le asigne el error en ese punto para encontrar una solución. Pero si se trata de una solución simple, proporcionaré lo que creo que es una solución potencial que satisfaría los diversos requisitos y la eventual prueba de regresión que escribiré.

Me encantaría mis probadores - que ayudan a localizar averías y Spot cosas que no se le ocurriría como un problema, pero nuestros clientes lo haría. Y lo más importante para mí, me ayudan a asegurarme de no matar a alguien con un código incorrecto.

¿Por qué aparecen los problemas?

• Constantemente juzgan el trabajo de los demás, y algunas personas no pueden recibir ningún tipo de crítica.
• Hacer un mal trabajo desperdicia el tiempo de tu opuesto
• Ambos están bajo presión, al mismo tiempo, por lo mismo y nadie quiere ser el que sostenga las cosas

La combinación de lo anterior junto con la naturaleza de las posiciones significa que es muy fácil eliminar sus enojos y frustraciones actuales, si caen en esa trampa, dejan de trabajar juntos y comienzan a trabajar uno contra el otro. Eso es difícil de romper y no es bueno para nadie.

Supongo que sucede porque los programadores crean un programa y perciben que los probadores luego intentan encontrar fallas en él (a pesar de que los probadores son en realidad parte de la mejora del producto final). Cada vez que alguien encuentra fallas en algo en lo que pones mucho esfuerzo, probablemente sea una reacción natural reaccionar negativamente hacia ellos.

Las formas de mitigar esto serían hacer que los desarrolladores y evaluadores vean el producto terminado como la salida de todo el equipo (incluidos los evaluadores y desarrolladores) y hacerles comprender que las pruebas no son una misión independiente de búsqueda de fallas, sino una parte importante de El proceso de desarrollo . Y si los desarrolladores no creen que la prueba sea un trabajo real , o que sea fácil, pídales que escriban las matrices de prueba, ejecuten cientos de casos de prueba, documenten cada paso y cada resultado.

Sé de programadores y evaluadores particulares que no se quieren, pero no por las razones que usted indicó, sino porque hacen el trabajo el uno para el otro.

Es la naturaleza de la bestia. Conozco a algunos de los evaluadores particulares que no se preocuparon por programadores particulares porque sentían que su código era propenso a errores por descuido / pereza / etc. Algunos de los codificadores particulares que conozco que no se preocuparon por los evaluadores en particular sintieron que usaban condiciones de prueba ridículamente inventadas (nits de selección) o solicitarían revisiones al código basadas en el estilo.

Creo que mantener a las personalidades fuera de esto y enfocarse en la tarea en cuestión ayuda mucho a reducir las tensiones. Si una organización es lo suficientemente grande, la prueba doble ciego es una gran idea.

Un probador que puede expresar claramente los problemas, y los codificadores que claramente implementan soluciones son un gran equipo.

En los equipos en los que he trabajado estrechamente con los evaluadores, nos hemos llevado fantásticamente. Los evaluadores entienden las decisiones que se tomaron en varias decisiones tomadas, saben cómo son los horarios de los desarrolladores y se establece una relación entre los dos grupos.

En equipos donde la prueba es una entidad amorfa offshore, este no ha sido el caso. Los resultados de los evaluadores son menos relevantes porque no saben tanto sobre lo que está sucediendo, los desarrolladores comienzan a temer la avalancha de lo que consideran detalles intrascendentes que se encuentran en partes del programa que no se han tocado en dos meses, el equipo de prueba se molesta porque ninguno de los errores archivados se está solucionando (porque el cronograma está arruinado y los desarrolladores están ocupados preparándose para demostraciones o agregando características solicitadas, etc.), y en general ambos grupos se ven como antagonistas "otros" en oposición a los miembros del equipo.

Trabaja de cerca y las cosas estarán bien. Alguien debe asegurarse de que ambos equipos estén coordinados y en la misma página. Mi mejor experiencia, el equipo de prueba fue invitado a cualquier reunión de alto nivel a la que se invitó al equipo de desarrollo (todos ellos) y todos conocíamos el cronograma, teníamos una lista de prioridades unificada, y los desarrolladores y las pruebas tenían lo mismo (up- a la fecha) documento de requisitos. Mi peor experiencia (aparte de ninguna prueba) básicamente empacamos nuestras cosas, las enviamos al extranjero para que las revisemos, luego recuperamos todo un mes después con cosas marcadas como incorrectas que ni siquiera eran nuestras (complemento de terceros que conoció el nuevo requisitos, pero no las expectativas del equipo de prueba).

Ni el desarrollador ni la prueba tendrán éxito sin el otro. Si trabajas como dos mitades de la misma máquina y respetas al otro lado tanto como a los miembros de tu equipo más inmediato, todo estará bien. Comportarse como dos máquinas separadas y asumir que su máquina es mejor, las cosas serán terribles.

Cuando los programadores y los probadores no se quieren, a menudo es porque imaginan erróneamente que sus objetivos entran en conflicto.

Descubrí que estos problemas se mitigan en gran medida cuando los probadores y desarrolladores están en el mismo equipo, en lugar de un "equipo de prueba" y un "equipo de desarrollo". Creo que es por eso que, como probador, prefiero trabajar en equipos ágiles en lugar de desarrollar en cascada. Hay más comunicación, la entrega es más rápida y los desarrolladores aprecian más el tiempo y el talento que se dedican a las pruebas cuando ese trabajo es más transparente.

Individualmente, también se puede hacer mucho. Como probador, descubro que soy capaz de reducir esta fricción proporcionando comentarios positivos y encontrando errores. Todavía tengo que probar un desarrollador que no pueda enseñarme mucho , y encuentro que los desarrolladores aprecian a un probador que realmente trabaja para entender el código. Los desarrolladores están orgullosos, como cualquier buen artesano. Es importante hacerles saber que tener errores no los hace menos admirables

Los desarrolladores que he encontrado más fáciles de trabajar con buena calidad apreciada, y lo demostraron haciendo un esfuerzo por escribir un código de alta calidad antes de que el probador lo viera, incluida la realización de pruebas preliminares (principalmente pruebas unitarias automáticas y pruebas de humo manuales). Estos desarrolladores también solicitaron a la prueba que realizara revisiones de código para comprobar su capacidad de prueba, e incluyeron a los evaluadores en el proceso lo antes posible, incluida la presentación de diseños desde el principio (lo que permite a los evaluadores comenzar a planificar estrategias de prueba temprano, cuando la prueba tiene una carga más ligera). Los desarrolladores pueden ayudar a los evaluadores a encontrar áreas débiles en su código diciéndoles qué áreas se desarrollaron rápidamente o qué áreas fueron difíciles de probar. En general, cualquier cosa que los desarrolladores puedan hacer para facilitar el trabajo de un evaluador es apreciado y demuestra que valoran tanto el tiempo del evaluador como el suyo. Cuando los desarrolladores hacen esto,

Otro problema es que el control de calidad a menudo es un pensamiento posterior de muchas empresas. Muchas veces se le informa sobre proyectos en el último minuto y tiene una escasez de personal en comparación con el equipo de desarrollo. En algunos lugares, el camino hacia el desarrollador es el soporte técnico, el control de calidad y luego un desarrollador. Entonces, a veces cuenta con personas que desearían ser desarrolladores ... Y luego, cuando encuentran un defecto, su actitud es cómo esa persona puede ser un desarrollador y no yo, nunca cometería tal error, etc.

En general, me encantaría un equipo de control de calidad. También creo que las pruebas unitarias deberían ser una parte necesaria del desarrollo de software aparte del control de calidad. Entonces, a medida que QA encuentra errores, las pruebas unitarias se cambian para probar eso. Además, creo que los desarrolladores que realizan pruebas unitarias pueden comprender mejor qué es el control de calidad.

Además, muchos equipos de control de calidad tienen que hacer las cosas manualmente, en cuyo caso es un trabajo REALMENTE aburrido. En algunos lugares, QA escribe scripts y usa programas de automatización que incluso permiten guiones de GUI (a través de algún tipo de reconocimiento de imagen en la pantalla para botones / etc.). Entonces todavía es difícil cuando ocurren cambios importantes al principio, pero luego todo está automatizado y parece más divertido ...

También algunos desarrolladores desprecian el control de calidad. Aún así, prefiero que QA encuentre un defecto que el cliente ...

Aquí amamos a nuestros evaluadores, pero muchos de nosotros recordamos cómo era antes de tenerlos. Es mucho mejor que los probadores encuentren problemas que hacer que el cliente los encuentre después de que haya pasado a producción. No hay un desarrollador vivo que no haya creado un error o haya malinterpretado un requisito.

La clave es tratar a todos los profesionales con cortesía y respeto, ya sea que hagan lo que usted hace o no. Una vez que empiezas a pensar que tu trabajo es mejor o más importante que el de ellos, entonces has perdido.

Basado en esta pregunta: Técnicas o categorías de pruebas de software Sospecho que necesita un ajuste de actitud hacia los probadores y las pruebas en general.

Como desarrollador, he experimentado mi parte de tensión con los probadores.

En un trabajo, los probadores rara vez estarían probando lo "correcto". Implementaría una nueva función para el servidor de nuestro producto, y los evaluadores informarían un montón de errores sobre la interfaz de usuario. Dado que, en ese producto, la interfaz de usuario se configuró sin codificar , la presencia (o no) de problemas en nuestra IU de desarrollo no tenía absolutamente ningún vínculo con respecto a si los usuarios finales tendrían una IU con problemas similares. Los probadores sabían esto, pero persistieron en registrar errores sobre áreas extrañas.

Dicho esto, los buenos probadores valen su peso en oro: cambiaría un mal desarrollador por un buen probador en un instante. Un buen probador es un socio en la entrega de un producto de calidad.

También he conocido algunos desarrolladores que tratan a los probadores como el enemigo, como si los probadores estuvieran introduciendo las fallas. Es importante que los desarrolladores se den cuenta de que los evaluadores nunca introducen la falla, simplemente la descubren.

¿Cómo evitar estos problemas? ¿Qué tal ser amable el uno con el otro? Uno necesita al otro para obtener una aplicación de software de calidad, entonces, ¿por qué no respetar lo que cada parte debe hacer para lograr esto? Conozca lo que hace cada lado y realmente podría apreciar el trabajo involucrado.

La terquedad en ambos lados de cuál es la interpretación correcta de un requisito sería donde tendí a ver el conflicto entre desarrolladores y evaluadores en general. Si bien puede haber una apariencia de esnobismo o arrogancia, es solo que cada lado se adhiere a sus armas y quiere estar en lo cierto.

Una buena manera de evitar este problema es hacer que 3 partes, el desarrollador, el evaluador y algún mediador, ya sea un analista de negocios o un gerente de proyecto, analicen cómo se deben manejar los diversos casos límite. Algo a considerar es qué tipo de egos pueden surgir cuando hay un desacuerdo entre desarrolladores y evaluadores.

Los malos sentimientos generalmente son el resultado de una mala comunicación, que generalmente es el resultado de que los programadores y los evaluadores tienen diferentes perspectivas del código. El programador conoce los bits en los que ha estado trabajando íntimamente, pero puede que no sepa cómo encajan en el sistema general (más allá de lo que la especificación le dice). Los evaluadores ven el panorama general, pero no conocen el código en detalle. Los grupos pueden usar diferentes terminologías y procedimientos para las mismas cosas.

Esto puede llevar a que se presenten defectos contra el componente incorrecto (porque el componente responde a una falla en sentido ascendente), o que los desarrolladores cierren defectos legítimos porque no pueden reproducir el problema en su entorno (porque realmente no entienden cómo reproducir El problema correctamente). Si esto sucede mucho, puede tensar las relaciones entre los grupos.

Luego está la alegría de obtener un lote de defectos a la hora 11; Se avecinan los plazos, la presión viene de su gerente inmediato en la cadena, y obtiene un nuevo lote de defectos en un problema que sabe que ya ha solucionado y que realmente no quiere tener que tomarse el tiempo para ir a través del proceso para probarlo.

Una forma realmente buena de cabrear a su equipo de control de calidad es cerrar de forma sumaria varios cientos de defectos legítimos pero de baja prioridad (principalmente archivados contra interfaces de usuario feas o inconsistentes que de otro modo funcionarían) con el razonamiento de que su acumulación de defectos de mayor prioridad es tan grande que " nunca llegaremos a esos ". Pasas de rojo a verde en la hoja de cálculo del administrador del programa y obtienes un ataboy de la alta gerencia, mientras que el equipo de control de calidad se ve afectado por sus métricas por presentar un montón de defectos falsos.

Bad juju.

Esto a menudo surge de tres factores:

• Preguntas como estas apuntan a la existencia de un 'folklore' en la industria que a los desarrolladores y probadores no les gusta. La gente trata de encontrar aspectos que refuercen esto, incluso cuando tal sentimiento no exista en su equipo.
• Gerentes de proyecto incompetentes que miden el progreso por métricas como la cantidad de errores registrados.
• Un equipo disfuncional (y una falta de líderes que se preocupan lo suficiente como para arreglarlo).

Me gustan los probadores, pero en dos casos he encontrado conflictos.

1. Cuando la gerencia juega probadores y desarrolladores entre sí.

2. Cuando se envían problemas constantemente que carecen de detalles, es decir, "la pantalla x no funciona".

Creo que si este es realmente el caso, es un signo de inmadurez. A veces puedes hablar de eso como una broma. Pero si usted (desarrolladores y evaluadores que trabajan en el mismo proyecto) no se siente como un equipo, el resultado sería un desastre.

Las pruebas son una parte bastante importante del ciclo de vida del desarrollo de software (sea ágil o no). Por lo tanto, no debe pensar en los evaluadores como personas que viven para molestarlo con errores, sino como un compañero de equipo que lo ayuda a enviar software de calidad.