Que Computadora Comprar

Pruebas de Software – Cómo registrar un bug (defecto)

Ampliar imagen

Como las pruebas de software mejora la calidad de software y ofrece una solución rentable que satisfaga las necesidades del cliente, se hace necesario iniciar una sesión de un defecto de forma adecuada, realizar el seguimiento del defecto, y mantener un registro de defectos para futuras referencias, etc

Como probador, prueba una aplicación y si él / ella encuentra algún defecto, se inicia el ciclo de vida del defecto y se vuelve muy importante para comunicar el defecto a los desarrolladores que te lo arreglen, hacer un seguimiento de la situación actual del defecto, encontrar Si cualquier defecto (defecto similar) nunca se encontró en los intentos pasados ​​de pruebas, etc Con este fin, ha creado previamente los documentos manuales se utilizaron, que se distribuyeron a todos los asociados con el proyecto de software (desarrolladores y probadores). Hoy en día, muchas herramientas de informes de errores están disponibles, que ayudan en el seguimiento y la gestión de los errores de una manera efectiva.

¿Cómo informar de un error?

Es una buena práctica para tomar capturas de pantalla de ejecución en cada paso durante las pruebas de software. Si alguna prueba falla durante la ejecución, que debe ser fallado en la herramienta de informes de errores y un error tiene que ser reportado / registrado para el mismo. El probador puede elegir al primer informe de un error y luego no el caso de prueba en la herramienta de informe de errores o no un caso de prueba y de informar de un error. En cualquier caso, el ID del error que se genera para el bug reportado debe ser fijado a la caja de prueba que ha fallado.

En el momento de informar de un error, todos los campos obligatorios de los contenidos de error (como el Proyecto, resumen, descripción, Estado, detectado por, Asignado a la misma, ha detectado, de cables de prueba, detectado en la versión, en la versión cerrada, fecha prevista de de Clausura, fecha real de cierre, gravedad, y la prioridad ID de error, etc) están llenos y la descripción detallada del problema se da junto con los resultados esperados y los reales. Las capturas de pantalla, tomadas en el momento de ejecución de caso de prueba, se adjuntan al fallo de referencia por el desarrollador.

Después de informar de un error, un único ID de error es generado por la herramienta de notificación de errores, que luego se asocia con el caso de prueba fallido. Esto ayuda a los ID de error de asociar el error con el caso de prueba fallido.

Después de que el error se informó, se le asigna un estado de ‘Nuevo’, que va cambiando a medida que avanza el proceso de fijación de errores.

Si más de un probador está probando la aplicación de software, existe la posibilidad de que algún otro probador podría ya han informado de un error por el mismo defecto encontrado en la aplicación. En tal situación, se vuelve muy importante para el comprobador de averiguar si cualquier error se ha informado de un tipo similar de defecto. Si es así, el caso de prueba tiene que ser bloqueado con el error planteado anteriormente (en este caso, el caso de prueba tiene que ser ejecutada una vez que el error se corrige). Y si no hay errores como se informó anteriormente, el auditor puede informar de un nuevo y no el caso de prueba para el bug recién levantado.

Si no hay ninguna herramienta de informes de errores se utiliza, entonces en ese caso, el caso de prueba está escrita en forma de tabla en un archivo con cuatro columnas que contienen el paso de pruebas sin resultado, Descripción de la prueba Paso, Resultados esperados y los reales. Los resultados esperados y los reales se escriben para cada paso y el caso de prueba se hace para dejar para la etapa en la que el caso de prueba falla.

Este archivo contiene casos de prueba y las capturas de pantalla tomadas se envían a los desarrolladores de referencia. A medida que el proceso de seguimiento no está automatizado, es importante para mantener la información actualizada del error que se elevó hasta el momento en que se cierre.

(Nota: El procedimiento anterior de notificación de un error es general y no sobre la base de cualquier proyecto en particular la mayoría de las veces, los procedimientos de notificación de errores, los valores utilizados para los diversos campos utilizados en el momento de la presentación de informes de un sistema de seguimiento de fallos y errores,. etc, puede cambiar de acuerdo con el proyecto de pruebas de software y requerimientos de la empresa.)