El Departamento de Garantía de Calidad (QA) busca errores en el software. Los métodos varían de una compañía a otra, pero esto generalmente lo hacen empleados que están familiarizados con el software. Lo usan de varias maneras e intentan encontrar errores que los desarrolladores no han visto.
El término QA puede referirse al proceso en sí, a la organización, así como a un probador individual dentro de esta organización. Típicamente, los probadores en una organización de garantía de calidad se denominan "QA". En este artículo, para mayor coherencia, utilizaremos la abreviatura común QA en lugar del "probador de garantía de calidad" más preciso.
Diferentes empresas tienen diferentes responsabilidades de control de calidad para la calidad general del producto. A veces, el término "garantía de calidad" no es completamente aplicable a este departamento si solo busca errores y cuenta su número.
Los siguientes son individuos problemáticos en el departamento de control de calidad:
Manguera de fuego
Un probador que informa tantos informes de errores tan rápidamente que el equipo de desarrollo nunca terminará.
- Puede mutar en alarmistas
- Es peligroso en combinación con un gerente de proyecto como estadísticas
- Probabilidad de corrección: alta
- Peligro para el proyecto: alto
El problema
Si se encuentra un error, es importante hacer un informe claro e inmediatamente asignarlo al desarrollador apropiado. Sin embargo, algunos probadores pueden encontrar errores más rápido de lo que el equipo de desarrollo los soluciona. Debido a esto, la lista de errores está en constante crecimiento, y todos ellos nunca se pueden cerrar.
A primera vista, puede parecer que hay un problema con la calidad del producto, pero este no es siempre el caso. A diferencia de un probador convencional, que funciona con un programa muy defectuoso, una manguera contra incendios genera una avalancha de informes con una o más propiedades características:
- Sus informes son poco detallados, lo que permite un informe más rápido de más errores.
- Muchos errores son duplicados de otros, ya que son solo variaciones de una razón principal.
- No hay tiempo para reproducir el error, ya que es suficiente verlo una vez para escribir un informe.
Los probadores de mangueras contra incendios a menudo aparecen bajo presión directa o indirecta de la compañía:
cuantos más errores encuentre, mejor hará su trabajo . Esto lleva al hecho de que los evaluadores de control de calidad, que controlan cuidadosamente la causa raíz real de los errores y los informan de manera clara y concisa, se consideran menos productivos que las mangueras de incendios que emiten el número máximo de informes por unidad de tiempo.
Las actividades de dichos evaluadores pueden causar pánico en el proyecto, porque parece que el producto es de baja calidad y el proyecto ahora está retrasado. Su influencia en la moral puede ser inmediata y dramática: el equipo de desarrollo reza para interrumpir el flujo de informes de errores.
Solución
Antes de arreglar una manguera contra incendios, es vital identificarla con precisión y no confundirla con un control de calidad efectivo que colisiona con un sistema con muchos errores. La evidencia más clara proviene de las quejas de los desarrolladores:
- La mayoría de los errores son duplicados.
- Muchos errores tienen las mismas causas raíz obvias, por lo que podrían informarse como un error.
- Los mensajes de error no contienen detalles.
Para remediar la situación, se debe explicar a la manguera contra incendios que no hay incentivo para informar una gran cantidad de errores, y el objetivo es mejorar la calidad del sistema y ayudar a los desarrolladores. Después de eso, la calidad del producto debería mejorar al mismo (o mejor) ritmo, pero sin pánico.
El fiscal
Control de calidad, que después de cada error encontrado acusa a los desarrolladores de no probar su programa.
- Puede mutar en alarmistas
- Es peligroso en combinación con un gerente de proyecto como estadísticas
- Probabilidad de corrección: alta
- Peligro para el proyecto: bajo
El problema
Teóricamente, un desarrollador puede encontrar y corregir cualquier error antes de transferir el producto al departamento de control de calidad. Por lo tanto, algunos evaluadores perciben cada error encontrado como otra prueba de que los desarrolladores no prueban su trabajo lo suficientemente bien. Este argumento irrefutable le permite al fiscal expresar aún más en voz alta una opinión despectiva sobre el equipo de desarrollo.
El fiscal se come la moral del equipo. En lugar de ayudar a mejorar la calidad del producto, intenta demostrar que el equipo de desarrollo no está haciendo el trabajo. Cada error se agrega al montón de evidencia de que los desarrolladores confían excesivamente en el control de calidad en lugar de identificar los errores por su cuenta.
Desafortunadamente, los fiscales se crean como resultado de un proceso típico y bastante predecible:
- Se ha detectado un error crítico en la producción.
- El probador está acusado de perder este error.
Esto sucede con demasiada frecuencia y, por lo tanto, el control de calidad se defiende naturalmente utilizando un argumento irrefutable.
Solución
Antes de corregir a un acusador, una organización debe dejar de culpar a QA por errores de producción. Quienes hacen esto deben recibir capacitación en métodos más productivos para mejorar la calidad del software.
Cuando la organización dejó de culpar al control de calidad por errores en la producción, puede arreglar el probador-acusador invitándolo a cambiar de opinión y de actitud.
Se le debe indicar que los desarrolladores son solo personas, y todas las personas tienden a cometer errores. El departamento de control de calidad debe compensar esta propiedad humana natural de los desarrolladores, actuando como protección contra los errores que afectan a los clientes. Además, debido al proceso de codificación tedioso y tedioso, es muy fácil para un desarrollador no ver el bosque detrás de los árboles: está tan concentrado en resolver un problema específico que se olvida de buscar cosas aparentemente obvias.
Cambio de actitud: debemos recordar que todos trabajamos en equipo, los camaradas no deben culparse mutuamente por cometer errores, sino que deben ayudar a corregirlos por el bien del equipo. Es especialmente importante para QA establecer asociaciones con el equipo de desarrollo por el bien del proyecto, y el proceso ininterrumpido de detección de errores, informes y el ciclo de vida de su reparación es crucial para la calidad del producto.
Alarmista
QA, que establece que todo el producto tiene un nivel de calidad inaceptable, mientras que su opinión se basa solo en una impresión superficial.
El problema
En esencia, las diferentes características de la aplicación tienen una calidad diferente. Algunos pueden ser relativamente simples o desarrollados por desarrolladores altamente calificados y, por lo tanto, hay pocos o ningún error. Otros son relativamente sofisticados o desarrollados por desarrolladores menos experimentados y, por lo tanto, están llenos de errores. El alarmista no tuvo la suerte de encontrarse de inmediato con un área de mala calidad, y
sin más investigación, anunció que todo el producto no era adecuado .
Puede hablar mucho sobre cómo los desarrolladores de neumáticos QA y perder su tiempo (vea un probador del tipo
engañoso ), pero esta es una situación doble. De hecho, con demasiada frecuencia, el desarrollador da conscientemente un software de control de calidad deficientemente probado para obtener una recompensa por el trabajo realizado o para afirmar que cumplió con la fecha límite. Cuando QA comienza a probar dicho sistema, inmediatamente encuentra muchos errores que el desarrollador debería haber visto. Por lo tanto, está claro que extrapola lo que vio a todo el producto y reclama una calidad críticamente baja.
Un alarmista generalmente tiene cierta autoridad en el departamento de control de calidad y se respeta su opinión. Cuanto mayor sea el nivel de su autoridad, más destructivo será el impacto en el proyecto. Un escenario típico es el siguiente:
- El producto se transfiere a QA.
- Un alarmista comienza a probar un área de calidad terrible.
- El alarmista detiene todas las pruebas e informa a las autoridades sobre un problema grave con la calidad del producto.
Este es un caso clásico de arrojar a un niño con agua. A veces, el control de calidad toma la decisión correcta, especialmente cuando el equipo de desarrollo tiene la reputación de transferir software no verificado al control de calidad. Pero sucede que la alarma se activa debido a un desarrollador débil, cuyo código fue el primero en llegar a un fabricante de pánico.
Solución
Un probador se convierte en alarmista si ha sido decepcionado repetidamente por un equipo de desarrollo. Si ella siempre suministrara software de alta calidad, no habría razón para desconfiar. Pero si el probador se volvió alarmista, será difícil para el equipo de desarrollo recuperar la confianza, especialmente si el equipo realmente tiene desarrolladores
en la tienda de porcelana e
incompetentes .
Por lo general, en grandes equipos de desarrollo, el código de baja calidad surge de desarrolladores individuales, no de todo el equipo. Por lo tanto, es imperativo que el trabajo de los desarrolladores menos competentes se pruebe al final, o que no caiga en el alarmista. Sin embargo, esto oculta el verdadero problema de que hay
desarrolladores en el equipo
que afectan negativamente el proyecto .
Científico
Un probador que pasa la mayor parte de su tiempo documentando errores, sin encontrar nuevos.
- Puede mutar en los oprimidos.
- Peligroso cuando se combina con un gerente de producto como autor de patentes
- Probabilidad de corrección: alta
- Peligro para el proyecto: bajo
El problema
Encontrar problemas en el sistema puede ser tan emocionante como buscar tesoros. Y cuando encuentre este tesoro, no es menos interesante resolver el rompecabezas. Se puede argumentar que un probador que considera el proceso de encontrar errores de esta manera es ideal. Pero surge un problema si busca documentar cuidadosamente su fascinante viaje. En lugar de centrarse en el problema principal, el desarrollador se ve obligado a leer una larga historia con muchos detalles inútiles, tratando de seleccionar la información relevante.
El científico literalmente percibe el requisito de "documentar cuidadosamente los errores". Los describe en forma de una historia de texto, y no una breve descripción con una secuencia clara de pasos para la reproducción. La lectura de dichos informes lleva mucho tiempo, y al final todavía no está claro cuál es exactamente el problema. Por lo general, dicha descripción incluye varios errores, al tiempo que se refiere a un área amplia del sistema y no a un problema específico.
La principal queja de los desarrolladores al recibir mensajes de error de los científicos es que la relación señal-ruido es demasiado baja. Pasan el tiempo examinando la corriente de conciencia, buscando detalles específicos. Esto es una pérdida de tiempo tanto para el desarrollador como para el probador.
Solución
Un científico de control de calidad es fácil de corregir enseñándole cómo escribir los informes correctos. A menudo, la corrección se lleva a cabo instantáneamente tan pronto como explican lo que se requiere de él. La forma más efectiva de enseñar el estilo correcto es reescribir uno o más informes en el formato correcto, lo que servirá como modelo para el futuro. Como resultado, un probador entusiasta escribirá informes claros y concisos de errores que no pueden hacerse más ideales.
Engañoso
Un control de calidad, que a menudo informa errores incorrectamente, lleva al desarrollador por el camino equivocado cuando intenta reproducir y solucionar el problema.
- Puede mutar en alarmistas
- Es peligroso en combinación con un gerente de proyecto como estadísticas
- Probabilidad de corrección: alta
- Peligro para el proyecto: alto
El problema
El informe de error debe incluir lo siguiente:
- La capacidad de determinar que realmente hay un error
- Capacidad para definir pasos para jugar un error
- Una descripción completa del error, a menudo con una causa raíz.
- Pasos claros para jugar un error
En cualquiera de estas etapas, el informe puede engañar al desarrollador, como resultado de lo cual perderá tiempo:
- Si no hay ningún error, el desarrollador pasa tiempo buscando un problema que no existe
- Si no se puede reproducir el error, el desarrollador pasa tiempo en su reproducción
- Si el error no se describe correctamente, el desarrollador pasa tiempo buscando una causa raíz demasiado específica o demasiado amplia.
- Si los pasos para la reproducción son inexactos, el desarrollador pasa tiempo tratando de interpretarlos o puede declarar que no hay errores, aunque lo hace
A veces, un desarrollador se confunde debido a un simple error de prueba. Pero un probador engañoso a menudo genera tales informes, causando considerable descontento entre los desarrolladores. Si la situación continúa, el probador eventualmente perderá la confianza de los desarrolladores, y estos dejarán de corregir incluso errores reales, rechazando dichos informes de error.
Solución
El control de calidad engañoso a menudo es bueno para encontrar errores, solo los documenta mal. Por lo tanto, vale la pena el esfuerzo para entrenarlo.
Uno de los métodos más efectivos es monitorear al desarrollador, quien, según su informe, intenta identificar el problema. Simplemente siéntese al lado del desarrollador que recibió uno de sus informes y observe con calma (sin interferencia) cómo el desarrollador está tratando de resolverlo. Por lo general, esto conducirá a una conversación saludable sobre la mejor manera de informar errores, lo que beneficiará tanto al desarrollador como al control de calidad.
Oprimido
QA, que es superado por los desarrolladores hasta el punto de que es poco probable que informe algún error, por temor a la intimidación de su parte.
El problema
Quizás no haya mayor manifestación de indulgencia que la actitud típica de los desarrolladores hacia el control de calidad. Además, a menudo se puede ver que los desarrolladores agresivos intimidan abiertamente al probador, incluso si informa un error natural en su código. Para contrarrestar esto, un control de calidad exitoso cuando se trabaja con desarrolladores agresivos debe tener las siguientes características:
- Ya ganó la gran confianza de los desarrolladores, por lo que sus errores siempre se toman en serio.
- Capaz de mostrar no menos agresión y perseverancia en una disputa con un desarrollador que no reconoce el error.
Desafortunadamente, no muchos probadores tienen tales características, por lo que los desarrolladores a menudo limpian sus pies sobre ellos y acusan principalmente a QA de detectar un nuevo error. No importa cuán ilógico pueda parecer, esta es una imagen típica en las siguientes condiciones:
- El desarrollador tiene un alto sentido de importancia personal (vea un desarrollador como una prima donna )
- El desarrollador cree que sabe mejor que el probador cómo funciona el sistema (vea a un desarrollador como un secuestrador )
Después de que el control de calidad se supera por completo con el tiempo, generalmente evita la confrontación con desarrolladores hostiles para reducir el estrés. Como resultado, raramente se informan errores de estos desarrolladores específicos, aunque pueden existir. Como regla general, una situación se detecta solo cuando surgen problemas en la producción y comienza una investigación de por qué el departamento de pruebas no detectó un error. Un probador deprimido proporcionará cualquiera de las siguientes explicaciones:
- Habló con el desarrollador y dijo que esto no es un error.
- Presentó un informe de error, pero el desarrollador lo rechazó.
- Encontró un error, pero "no creía que fuera lo suficientemente importante".
Un carácter pasivo a menudo dificulta el reconocimiento de un control de calidad oprimido. La clave será analizar a los desarrolladores con los que trabaja este control de calidad, buscando signos obvios de hostilidad.
Solución
Los desarrolladores a menudo se burlan directamente de los probadores. Por lo tanto, deben ser tratados como cualquier hooligans:
- Exija que deje de burlarse inmediatamente del control de calidad y se abstenga de comportamientos agresivos.
- Entrenar la comunicación profesional.
- Descarte si el desarrollador no puede arreglar su comportamiento.
En casos especialmente severos, el departamento de personal tendrá que intervenir, especialmente si la situación se ha degenerado en hostilidad abierta.
Es triste que esta situación sea la norma más que la excepción. La única diferencia es el grado de hostilidad.
Clicker aleatorio
Control de calidad que busca errores mediante el método de clic aleatorio.
El problema
La búsqueda de errores en el sistema se lleva a cabo por dos métodos principales:
- De acuerdo con el plan de prueba procesando metódicamente la lista de casos de prueba.
- Recorrido aleatorio por la aplicación en un intento de emular las acciones del usuario.
Escribir un plan de prueba es una tarea que requiere mucho tiempo, y no hay garantía de que para cuando comience la prueba, el plan seguirá siendo relevante después de cambiar los requisitos. Esto puede llevar al hecho de que el probador abandona por completo los planes de prueba y, en cambio, solo interactúa con la aplicación con la esperanza de encontrar errores.
De hecho, la interacción accidental con la aplicación revela errores, especialmente en una etapa temprana del desarrollo del producto. Sin embargo, a medida que el producto envejece, encontrar errores de esta manera será mucho más difícil, ya que los errores restantes están ocultos en los casos límite. Esto lleva a una falsa sensación de seguridad, como si la aplicación no tuviera errores, aunque simplemente no se ha probado como debería.
Es importante recordar que la interacción aleatoria con la aplicación sigue siendo una metodología aceptable, ya que puede revelar situaciones no documentadas en el plan.
Pero esto es solo una adición al plan de prueba, no un reemplazo.Solución
Un clicker aleatorio puede aparecer en uno de dos casos:- No le enseñaron cómo probar la aplicación correctamente.
- Evita activamente escribir un plan de prueba.
Si el problema es la falta de capacitación, debe proporcionarla. Sin embargo, en este caso, el probador aún puede caer en la segunda categoría, no queriendo hacer un plan de prueba, incluso si sabe que debe hacerlo.Escribir un buen plan de prueba requiere un nivel raro de organización, diligencia y concentración. Como resultado, ciertos tipos de personas disfrutan de ese trabajo, pero la mayoría no. Si tiene mucha suerte, un clicker aleatorio encontrará las características necesarias para escribir buenos planes de prueba, pero la probabilidad es pequeña.Audazmente atrevido
, -, .
El problema
Informar correctamente un error es un proceso que requiere mucho tiempo y es cognitivamente difícil, y algunos QA no quieren hacer un esfuerzo suficiente. Como regla, estos son probadores con algunos derechos: creen que no tienen que tratar de elegir la redacción. También a menudo miran con desprecio a los desarrolladores y no creen que valga la pena dedicar tiempo a algún tipo de análisis de errores: una declaración general es suficiente para que los desarrolladores se atrevan a averiguar cuál es el problema.Los informes de errores típicos de un probador descuidado contienen las siguientes frases:- "No funciona".
- "Está roto de nuevo".
- "El problema sería obvio si realmente utilizaras esta función".
- "No sé por qué se lo perdieron".
- “Compruébalo cuidadosamente la próxima vez”
- "No sé por qué no podemos implementarlo correctamente"
Obviamente, los desarrolladores no están muy contentos con los informes que usan frases similares en lugar de pasos para reproducir el error. Raramente lo hace un analista de control de calidad profesional, pero a menudo se encuentra si otro empleado de la empresa a quien se le pidió que buscara errores informaba de un error. Esto generalmente ocurre cuando queda poco tiempo antes del lanzamiento y no hay suficientes evaluadores. Como resultado de tal "ayuda", el caos generalmente ocurre, ya que los informes son rechazados por los desarrolladores, causando aún más controversia en el equipo, lo que profundiza aún más la indignación.Solución
En general, los evaluadores profesionales deben ser responsables de encontrar errores. Desafortunadamente, existe una opinión en la industria de que todos pueden buscar errores, pero esto no es así. Es más exacto decir que cualquiera puede detectar un error, pero como regla general, solo los especialistas en control de calidad profesionales pueden identificar errores importantes ocultos en situaciones límite e informarlos de tal manera que el desarrollador pueda comprender, reproducir y, por lo tanto, corregir este error de inmediato.Un probador que actúa descuidadamente cree que tiene todo el derecho a informes tan frívolos. Si ingresa al departamento de control de calidad, se le debe advertir que corrija su comportamiento contraproducente. Si la búsqueda de errores no es su responsabilidad directa, entonces se le debe prohibir informar errores hasta que aprenda a hacerlo profesionalmente.A menudo es mucho más eficiente simplemente quitar el probador descuidadamente atrevido que tratar de arreglarlo. Por sus acciones, definitivamente deja en claro que no quiere participar en las pruebas, por lo que eliminarlas es de interés común.Ver también: