Difference between revisions of "OOoES/Calidad/Gestion de la Calidad: Anatomia de un Bug"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
 
Line 55: Line 55:
  
  
[[Category:ES]]
+
[[Category:OldES]]
 
[[Category:Quality Assurance]]
 
[[Category:Quality Assurance]]

Latest revision as of 21:52, 4 October 2012

Anatomía de un Bug

Para poder tener un mayor conocimientos sobre los elementos que conforman el reporte de un bug, aquí esta la explicación de los elementos que intervienen en este proceso.


1.- Producto y componente: Los bugs estan divididos por producto y componente, con un producto teniendo uno o mas compoenentes en el. Por ejemplo, el producto Bugzilla de bugzilla.mozilla.org esta compuesto de muchos componentes. Administración: La administración de una instalación de Bugzilla.

Bugzilla General: Todo lo que no cabe en los otros componentes, o se extiende por varios componentes. Creación / Modificación de Bugs: La creación, modificación y visualización de errores.
Documentación: La documentación Bugzilla, incluyendo la guía de Bugzilla.
Email: Todo lo relacionado con el correo electrónico enviado por Bugzilla.
Instalación: El proceso de instalación de Bugzilla.
Consulta / Buglist: Todo lo relacionado con la b&uacuet;squeda de errores y ver la buglists. Informes / Gráficos: Cómo los informes de Bugzilla. Cuentas de usuario: Todo sobre el manejo de una cuenta de usuario desde la perspectiva del usuario. Las consultas guardadas, crear cuentas, cambiar contraseñas, acceder al sistema, etc. Interfaz de usuario: temas generales que tienen que ver con la cosmética de interfaz de usuario (no funcionalidad), incluyendo problemas estéticos, plantillas HTML, etc.

2.- Estado y la Resolución: Estos definen exactamente el estado en el que esta el error - ni siquiera de ser confirmado como un error, a través de ser arreglado y el arreglo confirmado por Aseguramiento de la Calidad. Los diferentes valores posibles para el estado y la Resolución de la instalación debe estar documentada en la ayuda contextual para esos elementos.

3.- Asignado a: La persona responsable de corregir el error.

4.- Contacto Control de calidad: La persona responsable de la garantía de calidad en este error.

5.- URL: Un URL asociada con el error, en su caso.

6.- Resumen: Un resumen de una sentencia del problema.

7.- Pizarra de Estado: (también conocido como pizarra) Una forma libre del área de texto para agregar notas breves y las etiquetas a un error.

8.- Palabras clave: El administrador puede definir palabras clave que puede utilizar para etiquetar y clasificar los errores - por ejemplo, El Proyecto Mozilla tiene como palabras clave accidente y la regresión.

9.- Plataforma y sistema operativo: Indican el entorno informático, donde se encontró el error.

10.- Versión: El campo de "versión" se utiliza generalmente para las versiones de un producto que han sido liberados, y se fija para indicar qué versiones de un componente sobre el cual un reporte de bug tiene un problema particular.< br>
11.- Prioridad: El cesionario de errores utiliza este campo para priorizar sus errores. Es una buena idea de no cambiar esta situación en los errores de otras personas.

12.- Gravedad: Esto indica que tan grave es el problema - de bloqueo ("aplicación inservible") a lo trivial ("cuestión estética menor"). También puede utilizar este campo para indicar si un error es una solicitud de mejora.

13.- Objetivo: (Milestone objetivo aka) Una versión futura por la cual  el bug sera arreglado. por ejemplo Los hitos del proyecto Bugzilla, Bugzilla para las versiones futuras son 2.18, 2.20, 3.0, etc hitos no se limitan a los números, el pensamiento - puede utilizar cualquier cadena de texto, como las fechas.

14.- Reportero: La persona que presentó el error.

15.- Lista de CC: Una lista de las personas que reciben correo electrónico cuando cambia el error.

16.- Time tracking:  Este formulario se puede utilizar para el seguimiento del tiempo. Para utilizar esta función, tienes que ser bendecido pertenencia a un grupo especificado por el parámetro "timetrackinggroup".

17.- Adjuntos: Se pueden adjuntar archivos (por ejemplo, casos de prueba o parches) para los bugs. Si hay algn archivo adjunto, que se enumeran en esta sección. Los archivos adjuntos se almacenan normalmente en la base de datos Bugzilla, a menos que están marcados  como archivos grandes, que se almacenan directamente en el disco.

18.- Dependencias: Si este error no se puede solucionar a menos que los errores son fijos (depende), o este error deja de otros bugs  que se fija (bloques), sus números se registran aquí.

19.- Votos: Si este error se ha asignado ningn voto.

Personal tools