¿Por qué las personas de control de calidad no reciben ningún respeto?

Pregunta bastante complicada. Creo que no habrá una sola respuesta correcta en esto.

Mucho depende del contexto.

Veo los siguientes aspectos del problema:

  • Probabilidades Los probadores trabajan casi todo el tiempo con probabilidades. No podemos asegurar realmente que no haya defectos, pero solo que probablemente el usuario final no encontrará ninguno.
  • Variedad No hay una sola prueba válida válida: todos están haciendo cosas diferentes para garantizar la calidad. Y la mayor parte funciona (eso espero). Desde el punto de vista externo, esto puede parecer simplemente una adivinación, sin ningún enfoque sistemático.
  • La gente Hay muchas personas diferentes involucradas en las pruebas. Edad, experiencia, educación, carácter, todo varía mucho. Nuevamente puede parecer que “cualquiera” puede realizar pruebas.
  • No hay salida de material . Las pruebas no proporcionan ningún producto material. Lo ideal sería que ni siquiera se registraran defectos. No trato la documentación de prueba como un producto de prueba.
  • Culpa Al principio los desarrolladores intentan defenderse de los defectos que vienen. Probablemente se sientan culpables. Se necesita tiempo para transformar de la culpa a la gratitud. Tester no es un perro guardián, es más como un escudo. No muerde, sino que defiende a todos.
  • No hay escuelas . Actualmente no hay universidades que enseñen exámenes (al menos a nivel local). Y sin él, algunas personas no tratarán las pruebas como una ciencia (o al menos algún trabajo valioso).
  • En el borde Los evaluadores a veces trabajan en el borde: equilibran las necesidades del usuario, los deseos del propietario, los requisitos analíticos y las posibilidades del desarrollador. Puede llegar a algunos argumentos entre personas. O sentirte demasiado molesto.

No puedo decirles que todos faltan al respeto a los evaluadores, pero a veces puede que se enfrente al principio del trabajo. Después de un tiempo, creo que los demás sentirán su participación y ayuda, y esto le dará el respeto deseado personalmente.

Si usted es un tipo de control de calidad en una compañía de software y ahora tiene la sensación de que lo están descuidando o ignorando, hizo lo mejor que pudo en las pruebas, pero de alguna manera nadie es consciente de este arduo trabajo. Intento adivinar mejor aquí.

Primero, porque esa compañía específica siente que no necesita control de calidad. El Departamento de Calidad está justo ahí para garantizar que el Desarrollo de Software tenga todas las piezas, PM, Desarrollador, Control de Calidad, Control de Calidad, TI, PMO y etc. Cuando alguien venga a verificar o auditar, la compañía podría decir que “Tenemos un Departamento de Calidad para cuidar la calidad del producto “.

Segundo, y lo más importante es que una vez que el control de calidad está allí (ya sea por casualidad o por intención), el control de calidad de alguna manera tiene o absorbe la misma mentalidad anterior y no hace bien su trabajo.

  • No educan al equipo / a ellos mismos sobre la calidad y sobre la idea de que todos deben ser propietarios de calidad, no solo el departamento de control de calidad.
  • No se aseguran de que el equipo proporcione lo que el cliente desea o necesita y el equipo resolverá el problema del cliente. Y una gran cantidad de sobrecarga llegó más tarde para cambios y correcciones de errores.
  • No apuntan a la mejora continua. Siguen haciendo lo mismo pero esperan que el resultado sea mejor.
  • No tienen visión y objetivo en calidad. Además, no tienen la manera de medir el éxito.

Por lo tanto, hacen el trabajo a diario, es suficiente solo para hacer pruebas con respecto a las mejores prácticas industriales y estándar. Es por eso que no tienen respeto. Si el trabajo de control de calidad en este momento es comparar el producto con los resultados esperados, no hay duda de que incluso los adolescentes podrían hacer pruebas.

Si la Calidad es el enfoque principal y crítico, descubrirá que el esfuerzo de calidad de alguna manera será mucho más que el costo de desarrollo / codificación. Si el control de calidad podría aportar valor al equipo y demostrar que la calidad es una necesidad, el control de calidad definitivamente obtendría respeto.

Por cierto, QA es quien trabaja en el proceso y el estándar, QC es quien trabaja en las pruebas de software. El departamento de calidad se ocupará de ambos. Y no estoy seguro de qué quiere decir con control de calidad, así que trato de dar lo mejor de mí para responder a esta pregunta.

Yo mismo he sido ingeniero de control de calidad y estoy de acuerdo con lo que ha pedido hasta cierto punto. Antes de responder por qué sucede esto, primero permítame decirle que esto no sucede con todos los ingenieros de control de calidad. Muchos QAs son altamente recomendados, pagados y respetados sobre los Desarrolladores.

Permítame explicarle primero 1 de la experiencia del proyecto del que formé parte:
– Se suponía que iba a probar un Drupal CMS. El flujo del proyecto fue tal que, hay un servidor de ingestión que ingerirá datos a un servidor de aplicaciones y, a través de MySQL, Drupal mostrará los datos. Necesitábamos validar que los datos ingeridos y curados estaban siendo mostrados.
– El desarrollo se realizó bastante bien, debo decir, solía llevar una semana completa encontrar 10 errores en toda la funcionalidad después de cada nuevo sprint. Un nuevo control de calidad se unió al equipo para realizar las pruebas en el CMS. Desde que era nueva, me resistía a ofrecerle acceso a la línea de comandos. El nuevo miembro del equipo presentó milagrosamente 32 errores en el primer día simplemente probando el CMS.

Nos preguntaron cómo podría ella encontrar 32 errores en 1 día y no pudimos localizar ni siquiera 10. Como solo estaba probando la ingesta basada en la línea de comandos, no tenía ni idea, pero el otro miembro del equipo dijo que eran errores estéticos de la interfaz de usuario. El gerente luego gritó de nuevo diciendo “cada error es importante”. Todavía me estaba preguntando cómo alguien podría potencialmente encontrar errores en el Backup de Drupal.

Al día siguiente recibimos un informe donde todos los 32 errores se marcaron como no válidos, ya que no eran errores y formaban parte de la interfaz de usuario de Drupal y no había nada que nadie pudiera hacer al respecto.

Dos cosas para notar aquí:
1. Nadie sabía que no eran errores reales (puede incluirme a mí). De lo contrario, podríamos haber evitado que ella los archivara.
2. De repente, 32 errores nuevos deberían haber hecho que al menos uno de nosotros pensara que algo estaba terriblemente mal.

Probablemente fue un sentido común, pero 1 día de trabajo estúpido nos costó una enorme pérdida de respeto, si no otra cosa.

¿Cómo ser un buen y respetable QA?
1. Dar la importancia adecuada a los errores apropiados.
2. No seas un QA cosmético siempre. Problemas de funcionalidad de archivos basados ​​también. No siempre presente el mismo tipo de problemas. Si en todo lo que hace, recomiende soluciones o referencia del problema similar presentado anteriormente.
3. Ver el código, sugerir cambios si es posible.
4. No pelee / discuta con el desarrollador si se encuentra un error. Probar con hechos y documentos por qué es un error sin ser arrogante.
5. Hable con los desarrolladores muy a menudo para comprender su mentalidad y localizar las diferencias, infórmeles si hay algo que pueda hacer con la documentación suministrada pero que el desarrollador no pudo
6. Haz preguntas inteligentes
7. Desarrolle sus habilidades para pruebas de automatización, pruebas de rendimiento, etc.
8. Sé educado.

El control de calidad es un papel muy importante en el desarrollo de software. Desafortunadamente, también es uno que a menudo está infravalorado.

Muchos desarrolladores consideran erróneamente que sus colegas de control de calidad tienen habilidades inferiores o habilidades inferiores. Y, de hecho, a veces ocurre que las personas que no tienen un buen desempeño en un rol de desarrollador pueden terminar desempeñándose muy bien en un rol de control de calidad. Pero también he conocido a desarrolladores que solo podían escribir código nuevo y otros que solo podían depurar código antiguo. La diferencia es que tenemos un título de trabajo diferente para el rol de control de calidad, pero no un título de trabajo diferente para los desarrolladores que crean y los que mantienen. Eso te hace miembro de una tribu diferente.

El rol de control de calidad en el ciclo de vida del desarrollo de software a menudo los coloca en una posición crucial cerca del final de un proyecto. A medida que se aproxima la fecha límite de lanzamiento, las actividades del proyecto pasan de agregar características a encontrar y corregir errores, luego a la estabilización y, finalmente, a corregir solo errores críticos. El control de calidad está en el asiento caliente para probar y validar cada corrección de errores. Si continúan encontrando muchos errores, a menudo se los percibe erróneamente como la fuente del problema. Es, lamentablemente, un caso de ser portador de malas noticias.

Cuanto más alto asciendes en una organización de software, más amplias serán tus responsabilidades. A nivel de director, como lo fui durante muchos años, sus responsabilidades abarcan el desarrollo y el control de calidad porque usted también es responsable de la calidad de lo que esté produciendo su equipo y de lidiar con las consecuencias de un lanzamiento de baja calidad. Entonces, mientras que un gerente de desarrollo puede frustrarse cuando el control de calidad ralentiza las cosas al encontrar problemas, el director entiende que es necesario. Eso no significa que el director no presionará a los equipos de control de calidad para que trabajen más rápido, o que trabajen los fines de semana, o tal vez incluso para recortar esquinas. Podrían. Están bajo mucha presión para cumplir con la fecha límite de su propio administrador de la línea ascendente. Pero es probable que sean más comprensivos y aprecien el esfuerzo adicional y el papel clave que desempeña el control de calidad.

Desearía poder decir que estabas completamente equivocado en tu percepción. Pero en mi propia experiencia, tiene un anillo de verdad. Trate de no tomarlo demasiado personalmente. La gente se lleva su frustración a los agentes de boletos de avión cuando los vuelos se retrasan, aunque saben muy bien que no fue culpa del agente. Es la naturaleza humana.

Lo que se cuestiona puede ser su experiencia y también para muchos otros, pero ¿eso debería significar que es el estado real?

El hecho de que hayas contado todos los árboles, no significa que hayas estado en la naturaleza.

Las situaciones no son las mismas en todas partes, pero para aquellos que sienten que realmente está sucediendo, estas son situaciones que nosotros mismos hemos creado.

Hay muchas respuestas a continuación que tienen el razonamiento perfecto detrás de la causa. La única razón por la que el estado no ha cambiado en algunos lugares es que solo nos hemos quejado pero nunca hemos tratado de cambiar esta situación.

Como experto ingeniero de pruebas, solo para mantener altos los puntajes individuales no queremos enseñarle a la otra persona nuestras habilidades, sino que nos burlamos, disminuimos su confianza, hacemos una broma. Como un par respeta al otro individuo, ayuda, entrena, trabaja colectivamente para ser un cambio si esta situación persiste.

No todos los gerentes de proyecto entienden la necesidad, solo están preocupados por entregar a tiempo y no les importa el deslizamiento en la calidad. Solo tienen un equipo de pruebas y una cabra escapada por cualquier falla. No entendemos la causa, pero seguimos esforzándonos, lo que no ayuda. Intenta cambiar las cosas y cambiar la perspectiva.

Realmente no tiene que ser así.

¿Qué significa primero la pregunta? “QA personas”, “cualquier respeto”. ¿Cuándo y dónde sucedió esto?
Desarrollador o control de calidad: un profesional que obtiene respeto depende en gran medida de la persona y la personalidad.
El título y la profesión no tienen nada que ver con el respeto.
En ciertas organizaciones, los desarrolladores reciben “pagos” más que los QA. Esto tiene que ver con el valor y las asignaciones presupuestarias en las que opera la organización. Nada que ver con el respeto !!
Para una respuesta más divertida – En desarrolladores confiamos. El resto lo probamos.

Los evaluadores son vistos como un obstáculo para lanzar porque las personas no calculan el costo de la mala calidad.

https://en.wikipedia.org/wiki/Co

Está claro cuál es el beneficio de una parte de la funcionalidad, pero las personas no aprecian ni cuantifican la falta de beneficios, si una pequeña parte de esa funcionalidad no funciona, cuando llega al cliente.

Por lo tanto, aquellos que encuentran tales faltas son considerados como recolectores de liendres, si no pueden expresar los beneficios de su trabajo.

Porque no lo necesitan.
Esta cita de The Dark Knight se eleva lo explica bien

“porque puede soportarlo … porque no es un héroe … es un guardián silencioso, un vigilante protector … un Caballero Oscuro”

Suena como un entorno de trabajo bastante duro. Donde trabajo, el control de calidad y el desarrollo trabajan juntos para garantizar que el mejor producto posible sea lanzado a nuestros clientes. Eso significa que ocasionalmente tenemos que bloquear un lanzamiento, pero mejor que pedir disculpas a los clientes por haberles enviado algo problemático.

Bueno, el control de calidad va por ahí señalando los errores cometidos por todos los demás, por lo que es fácil no gustarles.

(Es incorrecto y tonto también, por supuesto).