Manual de levantamiento de defectos en Bugzilla.

Control de Cambios

Nombre del archivo Versin Fecha Autor Comentarios

Manual de

levantamiento de

Defectos en

Bugzilla.docx

0.1 01/04/2014 Gerardo Marn Versin Inicial

Contenido

Control de Cambios ............................................................................................................................. 2

1. Descripcin .................................................................................................................................. 4

2. Propsito ..................................................................................................................................... 4

3. Objetivos. .................................................................................................................................... 4

4. Proceso ........................................................................................................................................ 4

4.1. Prerrequisitos. .......................................................................................................................... 4

4.2. Crear un defecto. ...................................................................................................................... 4

1. Descripcin Este manual define la secuencia de pasos para crear un defecto en Bugzilla.

2. Propsito El propsito de ste manual es definir la secuencia de pasos a seguir para crear

un defecto (bug) en Bugzilla

3. Objetivos. Facilitar a un grupo colaborativo de desarrolladores y testers la creacin de

defectos con criterios unificados de atributos del mismo.

4. Proceso

4.1. Prerrequisitos.

Bugzilla deber estar instalado y operando, para fines de ejemplo se usar

servidor.dominio.tld como url base de ejemplo.

El usuario deber tener una cuenta registrada en ese servidor.

El usuario deber tener privilegios de creacin y edicin de defectos.

Deber tener una cuenta de correo activa y accesible.

La aplicacin (producto en la jerga de Bugzilla) deber estar registrada por un

administrador. Si la aplicacin tiene ms de un componente, debern estar

registrados en el producto.

Los valores por defecto (desarrollador por defecto, QA por defecto) debern estar

preparados por el administrador.

4.2. Crear un defecto.

4.2.1 Ingresar al sistema:

Aunque las instalaciones de Bugzilla pueden variar presentando diferentes pginas

de login, la instalacin por defecto la presenta la pgina principal de la forma

siguiente (notar que la versin puede estar traducida, pero por defecto se

presenta en ingls):

Figura 1. Pgina principal de Bugzilla.

Home: Redirige a la pgina principal de Bugzilla (que es la que se muestra en la figura) New: Crear un defecto.

Browse: Presenta una lista de defectos que puede ser personalizada. Search: Presenta la pgina de bsqueda simple y avanzada. Reports: Presenta los reportes varios de defectos. New Account: Presenta la pgina de crear una cuenta en esa instalacin de Bugzilla. Login: Ingresar a Bugzilla con usuario y contrasea. Forgot Password: Enva un correo para cambiar la contrasea de una cuenta. EN | ES-ES : Idiomas que soporta esa instalacin de Bugzilla. Al hacer click sobre uno de los idiomas, presenta casi todos los mensajes en ese idioma (puede Hacer click en la liga de login, aparecern el campo de usuario y contrasea y un

botn de ingreso.. Por defecto los usuarios de Bugzilla deben ingresar con una

direccin de correo vlida y completa (cuenta@servidor.dominio.tld) que

normalmente es validada para permitir el ingreso. Indicar el usuario, contrasea y

oprimir el botn de Log in. Si las credenciales son vlidas, aparecer una liga de

Log out y su nombre de usuario en la barra de men. En la parte inferior

aparecer una liga My Bugs que redirige a una lista de los defectos creados o

vigilados por, o asignados a el usuario que acaba de ingresar.

4.2.2. Ingresar a la pgina de Crear un Bug (New, o el icono en la parte central

de File a Bug.)

Si se tiene asignado un nico producto, la seleccin es automtica. Si no existe esa

asignacin nica, aparecer la lista de productos en una pgina:

Figura 2. Seleccin de productos.

Una vez seleccionado el producto, presenta la pantalla principal de creacin de bug.

Figura 3. Bug bsico.

Note que en la parte superior izquierda se encuentra la liga Show Advanced Fields.

Todo tester deber activar los campos avanzados y la pantalla se presentar de la

siguiente forma. Si tiene activadas las galletas del navegador, la seleccin de

presentacin ser permanente cada vez que ingrese.

Una vez seleccionado que muestre campos avanzados, la ventana presentar los datos

de la siguiente figura:

Figura 4. Datos de bug, modo avanzado.

Todos los campos marcados con un asterisco rojo son obligatorios.

Product: Producto, seleccionado en el paso anterior. Si se tienen permisos, se presentar una lista de todos aquellos productos sobre los que se tengan permisos, estando seleccionado por defecto el que se escogi en el paso anterior. Component: Componente que presenta el defecto. Al lado derecho se presenta su descripcin, seleccione el componente de la lista. Si no est seguro del componente haga un estimado.

Version: Versin del producto en la que se presenta el defecto. Si existe ms de una, seleccione aquella en la que ocurri. Severidad: Es una definicin de cunto y cmo impacta un defecto en el sistema (que tan grave es el defecto) desde el punto de vista tcnico (requerimiento y codificacin). Deber ser asignada con alguna de las siguientes severidades: Enhancement/Mejora: Deteccin de una propuesta de funcionalidad, usabilidad, esttica y completitud del sistema. Valor numrico: 0. Trivial: Defecto de tipo cosmtico que no afecta la funcionalidad del componente. Por ejemplo una falta de ortografa menor (como un acento). Valor numrico: 1 Minor/Menor: El defecto no inhibe la funcionalidad del componente ni incumple con un requerimiento, sin embargo el comportamiento no es natural. Valor numrico: 2 Normal: El defecto inhibe una funcionalidad o incumple parcialmente un requerimiento del sistema, sin embargo no se requiere de un rodeo al defecto para obtener la salida deseada. Valor numrico: 3 Major/Mayor: Inhibe una funcionalidad o requerimiento del sistema, sin embargo es posible dar un rodeo al defecto de manera que se obtenga la salida final esperada. Valor numrico: 5 Critical/Crtico: Inhibe completamente una funcionalidad, no hay manera de rodear el problema, existe prdida de datos o falla general del sistema. Valor numrico: 8. Blocker/Bloqueador: Inhibe completamente una funcionalidad, no hay forma de rodear el problema, bloquea el avance en mltiples frentes (pruebas y desarrollo), corrompe informacin. Valor numrico: 13. Hardware: Existen defectos que pueden ser especficos de una plataforma, por ejemplo un elemento que se ve bien en PC y Mac, pero no en una tablet de baja resolucin. Seleccione una plataforma de hardware especfica nicamente si slo sucede en ella. OS: Sistema operativo en el que se presenta la falla, al igual que en el caso anterior, especifique cuando el bug se presente exclusivamente en un sistema operativo y no sea generalizado, por ejemplo Android 2.3.3. Priority/Prioridad: Es una clasificacin basada en la importancia de negocio de cliente y urgencia de tener una solucin (que tanto se necesita que se resuelva), por ejemplo la presencia de un logotipo errneo del cliente en las pginas de un sistema visible al pblico tiene alta prioridad a pesar de ser cosmtico. Regularmente se tienen de 3 a 5 categoras de prioridad desde Highest/Ms Alta a Lowest/Ms baja. El valor por defecto es Normal. Target Milestone/Versin Objetivo: es aquella en la que se espera que el defecto sea corregido. Status: Inicialmente un defecto tiene un status de Confirmed/Confirmado (por defecto, para el perfil de tester), pero puede ser Unconfirmed/Sin Confirmar si el bug fue

encontrado por un usuario y su existencia no ha sido verificada por el tester o desarrollador. Asignee/Asignado: Persona que se har cargo de la correccin del bug. Regularmente el administrador asigna las personas por componente por defecto, la persona deber estar registrada en Bugzilla. Si se desea cambiar la persona por defecto, comience a escribir su direccin de correo y Bugzilla autocompletar presentando aquellos usuarios registrados que cumplan con el nombre conforme se escribe. QA Contact /Contacto de QA: Persona del rea de testing que estar encargada por defecto de verificar la evolucin de la correccin. El campo se autocompleta como el de asignado CC: Copia al carbn: lista de personas separadas por comas, que recibirn un correo cada vez que el bug sea modificado. Debern estar registrados en bugzila y el campo se autocompleta como el de asignado o QA. Original Est. / Est. Original: Tiempo estimado para la correccin. Regularmente el tester no llena este campo. Deadline/Fecha Lmite: Fecha mxima en la que debe estar corregido. Regularmente el tester no llena este campo a menos que exista un acuerdo para fijar esa fecha. URL: La direccin de la pgina que presenta la falla, tratndose de un sistema basado en web. Summary/Resmen: Descripcin concisa del defecto, no extenderse demasiado, pero evitar toda ambigedad, por ejemplo El campo telfono en pgina de contactos acepta caracteres alfabticos Descripcin: Secuencia detallada de pasos a seguir para replicar el defecto, as como los detalles funcionales, mensajes de error o detalles tcnicos accesibles al tester, por ejemplo:

1. Ingresar al sistema. 2. Dar click en la liga de contactos. 3. Llenar la informacin de todos los campos. 4. En el campo telfono, ingresar caracteres no numricos, ABCD con

o sin las comillas. 5. Oprimir el botn de guardar. 6. El valor es almacenado en la base de datos, tabla tel_persona,

campo telefono y es visible en la pgina de consulta de contactos. No se deben almacenar datos no numricos de acuerdo a la especificacin.

Attachment/Anexos: Evidencia anexa como pueden ser imgenes, video u otro tipo de archivos (por ejemplo, un reporte en PDF que presente el error) Depends on/Depende de. Si existe un bug que debe ser corregido antes, sealarlo. Por ejemplo si el bug 123 es El campo telfono de la tabla tel_persona debe ser numrico es probable que dependa, de manera que se ingresara 123. Blocks/Bloquea: Es la contraparte de la dependencia, es un defecto que tiene que corregirse antes de corregir aquellos a los que bloquea. Finalmente, se oprime el botn Submit Bug / Enviar Bug. Si la informacin fue adecuadamente ingresada (incluyendo todos los campos obligatorios), el defecto ser almacenado.