Menú

Tres estrategias para lidiar con un defecto de bloqueador

3 strategies dealing with blocker defect

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Los defectos del bloqueador agregan toneladas de drama a los días de prueba que de otro modo serían regulares.

En este artículo, quiero cubrir algunos pasos que un evaluador puede tomar al tratar con ellos.

Voy a asumir que nuestros queridos lectores ya comprenden profundamente la severidad y la prioridad de los defectos. ¿Necesitas un resumen rápido? Mira esto.

Ahora, ¿significa siempre que debemos dejar de probar por completo si nos encontramos con un problema de bloqueo?

En algunos casos 'Sí', pero tal vez no siempre. Podría haber casos en los que sea posible realizar alguna actividad de prueba.

Lidiar con el defecto del bloqueador

imagen fuente

A continuación se muestran algunas situaciones que he vivido en mi carrera como tester. Creo firmemente que se deben seguir los pasos que se describen a continuación (luego se consolidarán en un diagrama de flujo) para simplificar este proceso.

Entremos de inmediato.

Pasos que debe seguir cuando se encuentra con un defecto de bloqueo

Paso 1: Cuando se encuentre con un problema, invierta tiempo para encontrar la causa raíz.

Creo firmemente que, como tester, nuestro trabajo no termina en informar defectos . Si el tiempo lo permite, deberíamos explorar qué pudo haber causado el problema. Es posible que no siempre podamos señalar el área exacta del problema, pero trate de solucionar el problema tanto como sea posible. Los mismos detalles se pueden actualizar en el defecto como comentarios adicionales.

He hecho esto mucho en mis proyectos y esto ha resultado en una solución rápida. Los beneficios del análisis de la causa raíz son:

  • Al ser un valor agregado, definitivamente puede proporcionar una mejor dirección al desarrollador para corregir errores.
  • Además, el probador de control de calidad puede reconocer si este problema es de creación propia (problemas de entrada de datos o de uso humano) y, de ser así, puede solucionarlo el probador mismo. Cuando estos errores se informan a los desarrolladores sin que nosotros verifiquemos desde el control de calidad, son considerado un problema y podría crear una reputación negativa para el evaluador.

Por lo tanto, sugiero que siempre verifiquemos dos veces antes de registrar un defecto.

Aquí hay algunos ejemplos en tiempo real de mis proyectos que reforzarán los puntos anteriores:

Trabajé en un proyecto en el que nuestras pruebas requerían que soltáramos un archivo en una ubicación específica. Cambie el nombre para que coincida con el nombre en la configuración. Un trabajo programado recogería el archivo de datos y cargaría los datos en el sistema. Después de lo cual, validaríamos los datos en la base de datos y en la interfaz.

que es loadrunner en pruebas de software

Solíamos encontrar problemas en los que el trabajo se ejecutaba pero los datos no se cargaban y, tras la investigación, era porque el evaluador no había cambiado el nombre mientras dejaba el archivo en la ubicación.

Esto fue un bloqueador para nosotros, pero no algo que requiriera la atención del desarrollador. Teníamos que prestar atención a los detalles y evitar errores tan pequeños.

Las siguientes son algunas categorías comunes, causas fundamentales y soluciones:

# 1) Archivo de hosts Asunto - Digamos, su archivo de hosts tiene parámetros que son incorrectos y están causando el problema. En este caso, puede actualizar el archivo de host usted mismo o buscar ayuda de alguien con acceso para actualizar y continuar con la ejecución de la prueba.

Se debe plantear un defecto para el mismo para que los desarrolladores investiguen, pero con la solución alternativa, las pruebas funcionales aún pueden continuar.

Nota: Consulte con sus equipos de proyecto si está bien que el equipo de control de calidad realice estos cambios antes de hacerlo.

# 2) Configuración - A menudo, hemos notado problemas de configuración, como no apuntar al entorno correcto u otros problemas de configuración, que son problemas de bloqueo. También en tales casos, los evaluadores pueden realizar cambios y continuar con las pruebas.

Nota: Una vez más, solicite permiso antes de hacer esto.

# 3) Problema de código - Si cree que el problema se debe al código, los evaluadores no pueden hacer mucho. Registre un defecto de bloqueador y espere a que la solución continúe con la prueba.

# 4) Problema de implementación - Una mala implementación es otra causa común de problemas con los bloqueadores y estos pueden detectarse durante la prueba de cordura. Aquí también, las pruebas deben detenerse inmediatamente hasta que se reciba una nueva compilación.

# 5) Medio ambiente abajo - Si el entorno no funciona, digamos que la base de datos no se conecta al servidor o que la URL no funciona en el caso de los sitios web; Los probadores no pueden hacer mucho en estos casos más que informar un defecto y esperar a que el sistema esté en funcionamiento.

Por lo tanto, si existe una solución alternativa, úsela para continuar con la prueba. La única forma de encontrarlo, si existe dicha solución, es investigando la causa raíz. La mayoría de las veces, puede haber una alternativa.

Paso 2: Es muy fácil caer en un bucle infinito cuando se investiga la causa raíz. Por lo tanto, asegúrese de no consumir todo el día y todo el esfuerzo.

Aquí hay algunos consejos:

cómo escribir casos de prueba uat
  • Encuentre un equilibrio y reconozca el punto de parada cuando llegue allí.
  • La experiencia y los conocimientos de un evaluador son fundamentales para un RCA exitoso. Sin embargo, es una buena idea involucrar al equipo y al líder del equipo, cuando sea necesario.
  • Cuando sienta que la RCA requiere mucho tiempo, primero informe el problema de inmediato y proporcione toda la información que pueda. Una captura de pantalla siempre es útil.
  • Si es necesario, haga un seguimiento. Envíe un correo electrónico al administrador o al desarrollador para llamar la atención sobre el problema crítico.
  • Continúe con la resolución de problemas después de alertar a las partes necesarias.

Razón por la que los defectos del bloqueador deben notificarse de inmediato:

  • La gerencia debe estar al tanto de todos los tiempos de inactividad si el problema resulta ser un defecto espectacular. Esta información debe transmitirse al cliente y también puede requerir actualizaciones del plan del proyecto (cronogramas de control de calidad), cambios en los entregables, etc.
  • Cualquier retraso en los entregables de QA debe estar respaldado con evidencia. Por lo tanto, siempre es mejor comunicarse lo antes posible en lugar de esperar hasta el final del día.

Paso 3: Ahora, pasando al último paso, ya que hemos terminado de analizar el problema y comunicarlo, ¿qué sigue?

  • Si el problema es bloquear el acceso a un área funcional, verifique si esto tiene un impacto en otras áreas
  • Si la aplicación de front-end no funciona, compruebe si se pueden continuar las pruebas de backend / middleware / base de datos.
  • Si no se puede realizar ninguna actividad de ejecución de prueba, intente trabajar en alguna documentación relacionados con su proyecto.
  • También puedes intentar identificar áreas para la automatización si está repitiendo manualmente mucho trabajo. La automatización no siempre tiene que utilizar una herramienta. Digamos, la generación de informes es una tarea monótona para usted, esa es un área que se puede automatizar con simples macros de Excel y demás.
  • Dedique tiempo a conocer las herramientas de código abierto que se pueden implementar en su proyecto
  • Por último pero no menos importante , trabajar por la innovación, el mantra que gobierna el mundo actualmente.

Finalmente , el diagrama de flujo que resume toda la discusión.

Diagrama de flujo: Pasos para manejar un defecto de bloqueador

defecto del bloqueador

Autor : Este increíble artículo está escrito por Priya R., miembro del equipo de STH.

¿Qué pasos sigue cuando se encuentra con algún defecto de bloqueo?

Lectura recomendada

^