From 1109132f09d75da9a28b649c7677bb6ce07c40c0 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:41:45 -0500 Subject: initial commit --- files/es/qa/bug_writing_guidelines/index.html | 111 +++++++++ files/es/qa/confirming_unconfirmed_bugs/index.html | 44 ++++ files/es/qa/index.html | 252 +++++++++++++++++++++ files/es/qa/organizando_un_testday/index.html | 219 ++++++++++++++++++ files/es/qa/screening_duplicate_bugs/index.html | 157 +++++++++++++ 5 files changed, 783 insertions(+) create mode 100644 files/es/qa/bug_writing_guidelines/index.html create mode 100644 files/es/qa/confirming_unconfirmed_bugs/index.html create mode 100644 files/es/qa/index.html create mode 100644 files/es/qa/organizando_un_testday/index.html create mode 100644 files/es/qa/screening_duplicate_bugs/index.html (limited to 'files/es/qa') diff --git a/files/es/qa/bug_writing_guidelines/index.html b/files/es/qa/bug_writing_guidelines/index.html new file mode 100644 index 0000000000..94641c4a09 --- /dev/null +++ b/files/es/qa/bug_writing_guidelines/index.html @@ -0,0 +1,111 @@ +--- +title: Guía para escribir un Bug +slug: QA/Bug_writing_guidelines +translation_of: Mozilla/QA/Bug_writing_guidelines +--- +
+

Si necesitas ayuda con algún software de Mozilla (por ejemplo con Firefox, Seamonkey o Thunderbird), usa una de las opciones disponibles de ayuda. ¡No modifiques esta página! Por favor, lee esta página para aprender como reportar un bug usando Bugzilla, que es el sistema de seguimiento de bugs de Mozilla.

+ +

Si eres nuevo reportando bugs, puede ser que quieras intentar obtener ayuda de los colaboradores más experimentados. Vaya a la seccion de la comunidad en la página QA para consejos. Si vas a reportar un bug en Firefox, también puedes obtener asitencia en el canal #firefox en irc.mozilla.org.

+ +

Ver también Cómo escribir un bug apropiadamente.

+
+ +

Los reportes efectivos de bugs son los que más probablemente se resolverán. Estos lineamientos explican como escribir reportes efectivos.

+ +

Preliminares

+ +
    +
  1. Asegúrate de que tu software está actualizado +
      +
    • Idealmente, haz las pruebas en las versiones en desarrollo para ver si tu bug ya ha sido solucionado. (Léase Firefox Beta, Aurora, o si estás a la última con Nightly).
      • +
    • Si se reproduce de manera ocaciona, pero no después de seguir pasos especificos, debe proveer información adicional que sea util para el bug.
      • +
    • Si no puede reproducir el problema, es probable que no lo reporte, excepto que provea la información acerca de lo ocurrido.
      • +
    +
    2. +
  2. Haz una búsqueda en Bugzilla para ver si tu bug ya ha sido reportado (tutorial).
    3. +
  3. Abre el formulario para Reportar un nuevo bug, el cual te guiará a través de la mayoría del proceso de reporte del bug. +
      +
    • Si tienes varias cuestiones, llena reportes por separado.
      • +
    +
    4. +
+ +

Escribir pasos precisos para reproducir

+ +

¿Cómo puede el desarrollador reproducir el bug en su propia computadora?

+ +

Los pasos para reproducir un bug son la parte más importante de cualquier reporte. Si el desarrollador está listo para reproducir el bug, el bug es muy probable que sea corregido. Si este paso no está tan claro, no será posible saber si el bug ha sido corregido.

+ +

Describe tu método de interacción con Firefox  además de la atención de cada paso.

+ + + +

Después de tus pasos, describe con precisión los resultados observados y el resultado esperado. Hechos claramente separados (observaciones) de especulaciones.

+ + + +

Si el bug parece enorme, podría ser algo inusual en la configuración necesaria de los pasos para reproducir el bug. Ver si puedes reproducir el bug en un nuevo perfil Firefox. Si el bug solo sucede en tu perfil existente, trata de averiguar que ajustes, extensiones, o archivos en tu perfil se necesitan para reproducir el bug.

+ + + +

Escribiendo un resumen claro

+ +

¿Cómo describirías el bug utilizando aproximadamente 10 palabras? Esta es la primera parte de tu reporte que un triager o desarrollador verá.

+ +

Un buen resumen podría rápida y únicamente identificar un reporte. Esto debe exponer el problema, no tu solución sugerida.

+ + + + + +

Encontrando el producto y componente correcto

+ +

Se te pedirá que categorices tu bug en un "producto" y un  "componente" dentro de ese producto, con el fin de dirigir tu reporte a los desarrolladores correctos.

+ +

Si estás usando Firefox, el bug es más probable en "Firefox", "Toolkit", o "Core".

+ + + +

En caso de duda, se deben buscar errores similares y ver en qué componente están.

+ +

Si ninguno de los componentes parece apropiado, busca un componente "General" en el producto más apropiado.

+ +

Bugs específicos

+ +

Si reporta de un bloqueo, porfavor incluir el ID de Breakpad o adjunte el seguimiento de la pila e incluya la firma del bloqueo en el resumen del bug.

+ +

If you are reporting a memory use or leak bug, please attach the output of about:memory (Firefox 6+). Ideally, find steps to reproduce an increase in what is shown in about:memory (even after clicking the "Minimize memory usage" button at the bottom). If you have trouble finding steps to reproduce, try the Firefox Support page titled High Memory Usage. If you are a C++ developer, more precise tools are available.

+ +

If you are reporting a bug involving a specific web page, please try to make a reduced testcase and attach it to the bug report.

+ +

If the bug was recently introduced, finding a regression window can help identify the cause of the bug.

+ +
+

Original document information

+ + +
diff --git a/files/es/qa/confirming_unconfirmed_bugs/index.html b/files/es/qa/confirming_unconfirmed_bugs/index.html new file mode 100644 index 0000000000..deb06950b6 --- /dev/null +++ b/files/es/qa/confirming_unconfirmed_bugs/index.html @@ -0,0 +1,44 @@ +--- +title: Confirmando bugs sin confirmar +slug: QA/Confirming_unconfirmed_bugs +translation_of: Mozilla/QA/Confirming_unconfirmed_bugs +--- +

Los bugs que son de nuevos reporteros van a estar inicialmente marcados como SIN CONFIRMAR. Para cambiar un bug de SIN CONFIRMAR a NUEVO, necesitaremos tu ayuda para verificar si este es válido. Un bug puede ser movido de SIN CONFIRMAR a NUEVO si:

+ +

Nota: No es necesario que puedas reproducir el bug para poder confirmarlo.

+

Para ayudar a confirmar bugs, tienes que hacer lo siguiente:

+

Consigue configurar

+ +

Es recomendable usar los links Atrás/Adelante (Back/Forward) para moverse dentro de las listas, en vez de recargarlas cada vez que quieras buscar un nuevo bug.

+

Consigue los privilegios adecuados

+

Para poder confirmar los bugs necesitas el privilegio "Puedes confirmar".

+

Si has sido activo en Bugzilla, lo mas seguro es que tengas este privilegio. Revisa tus Preferencias en Bugzilla. Si tus permisos dicen "Puedes confirmar un bug" ("Can confirm a bug"), entonces estas listo. 

+

Si no tienes este privilegio, entonces puedes solicitarlo siguiendo estos pasos.

+

Confirma lo inconfirmado

+

1. Intenta determinar si el bug se encuentra duplicado. Use este método para buscar en la base de datos. 

+

2. Intente reproducir el bug.Si es posible reproducir el bug, entonces anota el hecho de que puedes reproducirlo, y agrega este comentario al campo de Comentarios Adicionales:

+
1. Tu versión de Mozilla (el título de la barra del navegador)
+2. Tu plataforma
+3. Tu sistema operativo
+
+

Si no puedes reproducir el bug, entonces anota en los comentarios de que intentaste reproducirlo y no pudiste. Si otros también están de acuerdo de que el bug es irreproducible, puedes marcarlo como INVÁLIDO (INVALID) o WORKSFORME, y decirle al que lo reportó que lo reabra si puede proporcionar pasos para reproducirlo en la nueva versión. Un texto ejemplo para los problemas coumunes de bugs puede ser encontrado al fondo de esta página.

+

3. Has que el bug sea fácil de entender.Mira los lineamientos para la Redacción de Bugs para saber el tipo de información que es de ayuda en un bug, incluyendo pasos para la reproducción y una buena descripción.

+

4. Verifica el Producto y el Componente. Si el reporte de bug es clasificado incorrectamente, muévelo hacia el correcto Producto y Componente. Asegúrate de clickear en el botón que dice "reasignar el bug al dueño del componente seleccionado" ("reassign the bug to owner of the selected component.")

+

5. Verifica el resumen del bug. Actualiza el resumen para que sea descriptivo, y contenga las suficientes palabras claves para que las personas que lo busquen lo encuentren.

+

6. Cambia el estatus a NUEVO. Deberías confirmar un bug cuando no está en el Componente general.

+

Opcional, pero de ayuda

+ diff --git a/files/es/qa/index.html b/files/es/qa/index.html new file mode 100644 index 0000000000..b8b4bf82af --- /dev/null +++ b/files/es/qa/index.html @@ -0,0 +1,252 @@ +--- +title: Control de calidad de Mozilla (QA) +slug: QA +tags: + - Ayudar + - Calidad + - Landing + - Pruebas + - QA +translation_of: Mozilla/QA +--- +
Cómo escribir un buen bug
+Al seguir estos lineamientos, aseguras que tus bugs estén en la cima de la pila de trabajo de los ingenieros de Mozilla y por lo tanto, ayudas a resolverlos.
+ +

Hay muchas cosas que puedes hacer para ayudar al proyecto Mozilla en el departamento de Control de Calidad (QA). No todas requieren saber programar, algunas tampoco requieren conocer HTML u otra tecnología Web. Si estás interesado en ayudarnos como testeador o en alguna otra actividad de QA, primero debes leer las siguientes páginas: Mozilla Quality Assurance y Helping with Quality Assurance

+ +

Empezando

+ + + +

Bugs

+ +
+
+

Reportando bugs

+ +
+
Bugzilla
+
Todos los proyectosMozilla usan Bugzilla para rastrear bugs. Necesitarás crear una cuenta con Bugzilla en orden para reportar bugs y priorizarlos.
+
Guías de redacción de bugs
+
Entre más efectivamente se reporte un bug, es más probable que un ingeniero puedo arreglarlo. Siguiendo estas guías, ayudas a asegurar que yus bugs sean nototios en el montón de los ingenieros Mozilla, y sean arreglados.
+
La vida de un bug
+
Este tutorial te dara un vistazo del qué sucede en los estados que un bug pasará, así cómo va desde un estado al otro en su ciclo de vida. También explica el significado de banderas (flags)/términos usados en QA.
+
Presentando crash bugs
+
Este documento enlista las guías y consejos acerca de cómo redactar reported de un bug reports que rompe, de una manera que ayude a depurar y arreglar el asunto reportado.
+
+
+ +
+

Catalogando bugs

+ +
+
Confirmando bugs no confirmados
+
Identifica reportes de bugs útiles y cierra el resto.
+
Catalogando bugs para Firefox
+
Información acerca del proceso completo de clasificación de bugs – desde procesar los bugs entrantes hasta detallar los pasos para recrear bugs.
+
Ocultando bugs duplicados
+
Ayuda a que los bugs sean más faciles de arrgelar al ocultar reportes entrantes acerca de duplicados.
+
Guías generales
+
Qué hacer y qué NO hacer en Bugzilla.
+
+
+
+ +
+

Pruebas manuales

+ +
+
+
+
Complementode la redacción de caso de prueba
+
Cómo escribir casos de prueba correctos
+
+
+ +
+
+
TestRail
+
Casos de prueba del área de QA en Mozilla se encuentran en TestRail. Necesitarás una cuenta LDAP para ingresar y ejecutar casos de prueba. Aprende más en la página wiki de TestRail.
+
+
+
+ +
+

Pruebas automatizadas

+ +
+
+
+
Automatización de pruebas en Mozilla
+
Documentación acerca de la creación y uso de pruebas automatizadas para el código de Mozilla.
+
Ejecutando pruebas automatizadas
+
+

Esta página enlista los pasos requeridos para ejecutar suites de pruebas automatizadas de Mozilla.

+
+
Desarrollando pruebas
+
Asegurar que cambios fúturos en Mozilla no vayan a dañar cosas que funcionan correctamente.
+
Evitar fallas intermitentes en pruebas
+
Sugerencias para hacer rus pruebas más confiables, de tal manera que ayudan a evitar fallas intermitentes y aleatorias en pruebas.
+
Verificación de pruebas
+
Cuando una colección de cambios agrega una nueva prueba, o modifica una prueba existente, la verificación de pruebas (test verification,TV) de un grupo de pruebas realiza evaluación adicional que ayuda a encontrar fallas intermitentes en ñas pruebas modificadas tan pronto como es posible.
+
Mozharness FAQ
+
Respuestas a preguntas comunes de Mozharness.
+
+
+ +
+
+
Robocop
+
Robocop es el sistema de automatización de pruebas usado en Firefox para Android. Aprende sus guías de estilo de codificación. 
+
Marionette
+
Conoce las pruebas de interfaz de usuario con Marionette.
+
Pruebas de plataforma-web
+
Aprende cómo usar el  sistema de pruebas Web en tiempo de ejecución estándar de la industria, multi-navegador, multi-platforma para la organización W3C usedo por Mozilla y otros para asegurar interoperabilidad entre navegadores.
+
Pruebas de Media externa
+
Empieza probando elementos de vídeo en HTML5u sando VideoPuppeteer, una colección de pruebas de Marionette usada probar sitios como YouTube o Netflix.
+
Pruebas de cromo
+
Una prueba de cromo es básicamente una prueba de Mochitest corriendo con privilegios de cromo (código Javascript en la parte front-end del sistema Gecko).
+
+
+
+ +
+

Ingeniería de calidad Firefox

+ +
+
+
+
Catalogando bugs para Firefox
+
Información acerca del completo proceso de clasificación de bugs – desde el procesamiento de bugs entrantes hasta reducir los pasos para replicar un bug.
+
+ +
+
Consejos y trucos
+
Estos consejos y trucos harán tu vida más fácil cuando estés probando.
+
+Descargando ramas de builds o nocturnos + +
+
Cada 24 horas, un build "nocturno" es creado para que los testers de todo el mundo lo descarguen y prueben, reportando como van encontrando los defectos.
+
+
+ +
+
+
Opciones de línea de comandos
+
Opciones de la línea de comandos son usadas para especificar varios ajustes de arranque en Firefox.
+
Reportando un problema de desempeño
+
Este artículo te guiará en el reporte de un problema de desempeño usando la extensión Gecko Profiler.
+
Informe de accidentes
+
Firefox incluye un sistema de código abierto para informar accidentes.
+
+
+
+ +
+

Firefox para Android

+ +
+
+
+
Firefox móvil
+
Firefox para Android es la versión móvil de Firefox con una apariencia nativa de Android.
+
Pruebas de compatibilidad
+
Ayudanos a identificar sitios web que no funcionen bien en Firefox al reportar  las cuestiones especificas que encuentras en tu investigación.
+
+
+ +
+
+
Registrando con Android Debug Bridge y Logcat
+
Este artículo proveerá un recorrido en descargar y establecer un ambiente al cual se puede obtener acceso y ver los registros del sistema de Android.
+
Habilitando la Consola de Error
+
Vee el artículo Mozilla Hacks en Depurando Remotamente en Firefox para Android para contenido web. Si necesitas depurar el mismo navegador Firefox  usa adb logcat de Android.
+
+
+
+ +
+

Firefox OS

+ +
+
+

Pruebas manuales

+ +
+
Simulador vs Emulador vs Dispositivo
+
Éstas son las tres opciones cuando viene a conseguir un ambiente Firefox OS en orden para trabajar, o desarrollar para, Firefox OS.
+
Depurando
+
Descubrir las diferentes herramientas a nuestra disposición para depurar tu código Firefox OS.
+
Reportando bugs
+
Este artículo proporciona una guía para archivar bugs acerca del proyecto Firefox OS, incluyendo Gaia y B2G.
+
+
+ +
+

Plataforma (Gecko)

+ +
+
Pruebas Automatizadas
+
Aprende varios aspectos de pruebas Firefox OS, incluyendo ejecutar diferentes pruebas, automatización, y reporte y seguimiento de resultados.
+
Pruebas de desempeño Gaia
+
Este artículo proporciona información acerca de ejecutar pruebas de desempeño en Gaia, así como el cómo crear nuevas pruebas.
+
Gráfico de soporte de funciones
+
Hay varios builds diferentes de Firefox OS que se pueden descargar o construir tú mísmo, y hay algunas diferencias entre los tipos de características disponibles en cada dispositivo.
+
+
+
+ +
+

Web QA

+ +
+
+
+
Refinando casos de prueba
+
Mejorando los reportes de defectos al convertir páginas web rotas en simples casos de prueba, los cuales pueden ayudar a desarrolladores entender el defecto y también pueden ser usados para crear pruebas automatizados.
+
Gestionando XFails
+
Uno de las tareas en marcha del departamento de Web QA es gestionar xfails. Este documento expliacrá que son las xfails, y describe los pasos que uno puede tomar para investigar y actualizarlos.
+
+
+ +
+
+
Ejecutar pruebas automatizadas
+
¿Así que estás interesadx en contribuir en los proyectos de automatización Mozilla Web QA pero no sabes por dónde empezar? Este documento te ayudará a preparar y ejecutar un conjunto de pruebas locales.
+
+
+
+ +
+

Glosario

+ +
+
+
Smoke Test
+
+
+
+ +

Ver también

+ + diff --git a/files/es/qa/organizando_un_testday/index.html b/files/es/qa/organizando_un_testday/index.html new file mode 100644 index 0000000000..25a0d5b818 --- /dev/null +++ b/files/es/qa/organizando_un_testday/index.html @@ -0,0 +1,219 @@ +--- +title: Organizando un Testday +slug: QA/Organizando_un_Testday +tags: + - Evento + - Organizando + - QA + - Testdays +translation_of: Mozilla/QA/Organizing_a_Testday +--- +
+

Esta página necesita una revisión técnica del Equipo QA de Mozilla en Q4 2014. (Asignada a Aaron Train.)

+
+ +

Por favor recuerda que lo mostrado en este artículo es solo una guía aproxmada. Cuanto mayor esfuerzo pongas en la preparación de un Testday, tendrás mayor probabilidad de éxito. Dá de tu parte, y de la comunidad, suficiente tiempo para preparar el evento. Sobre todo, experimenta y diviertete con tu Testday.

+ +

Planeando Tu Evento

+ +
Lo siguiente debe ser hecho en no más de una semana antes de tu evento:
+ +
 
+ +
    +
  1. Una vez tengas un tema en mente, elige un día para agendar tu evento — revisa el calendar on QMO para ver la disonibilidad.
    2. +
  2. Crea un plan de pruebas para definir el criterio de éxito,  establecer un lugar designado para la suscripción de mentores, establece un esquema (ej., past event test-plan)
    3. +
  3. Publica y postea el evento en QMO (de ser necesario, preguntar al staff de QA en  IRC para asistencia) — una valiosa publicación debe contener una solicitud para  inscripción de tutoría y  enlaces a documentación disponible (ej., see past event notice)
    4. +
  4. Difunde tu evento — Seguir nuestras sugerencias de comunicación listadas abajo ayudará a difundir y publicar el evento.
    5. +
  5.  Contar cno mentores para ayudar a facilitar y educar durante todo el evento — reunir información de contacto para asegurar la asistencia al evento.
    6. +
+ +

El Día "D"

+ +
    +
  1. Asegurate que el tema del canal IRC esté actualizado para señalar a las personas al plan de pruebas.
    2. +
  2. Ser proactivo en dar la bienvenida a las personas y eliminar las barreras para que puedan constribuir - hacer preguntas e interactuar con las personas que se unen al canal.
    3. +
  3. Recomendar suscribirse al dev-quality y mozillians a los asistentes para notificaciones de futuros eventos.
    4. +
  4. Proporcionar una encuesta de opinión a los participantes, clonar o copiar este documento de ejemplo
    5. +
+ +

Después del Evento

+ +
    +
  1. Proporcionar un post de seguimiento en tus canales de comunicación agradeciendo a quienes asistieron.
    2. +
  2. Planear un futuro evento.
    3. +
+ +

Consejos para el Éxito

+ +
Lo siguiente es una lista de consejos con lo que esperamos que tu evento sea más exitoso.
+ +
 
+ + + +

Canales de Comunicación

+ +

Lo siguiente es una lista de varios canales de comunicación que deberiamos usar para anuncios. Elige los que veas conveniente.

+ +
Listas de Correo
+ + + +
Redes Sociales
+ + + +
Foros
+ + + +
Páginas de Reuniones
+ + + +
Otros Sitios Web
+ + + +
+
+

Esta página necesita una revisión técnica del equipo Mozilla QA Team in Q4 2014. (Asignado a Aaron Train.)  Este artículo ha sido creado de esta página de QMO: Roles and Tips

+
+ +

Moderadores

+ +

Lo siguiente son algunos consejos para que los moderadores tengan un Testday exitoso.

+ + + +

Colaboradores

+ +

Lo siguiente son algunos consejos para que los colaboradores tengan un testday exitoso.

+ + + +
+

Información Original de Documento

+ + +
+ +
+
+

Esta págna necesita una revisión técnica del Equipo Mozilla QA Team en Q4 2014. (Asignado a Aaron Train.) Este artículo ha sido creado de esta página de QMO: Testday Template

+
+ +

Págna de Evento QMO

+ +

La semana antes al testday necesitamos crear una página de evento QMO.

+ + + +

Este es un ejemplo de una exelente página de Evento QMO. Antes de postear asegurate de:

+ + + +

Publicación en QMO

+ +

El día antes al testday, simplemente crea un post que recuerde a las personas que el testday será mañana.

+ + + +

Este es un buen ejemplo de un Recordatorio a un evento QMO. Tu publicación debe ser sindicada en el Planet dentro de 30 minutos a una hora.

+ +

Publicación de Resultados QMO

+ +

El día después del testday, elavora otra publicación que resalte los resultados.

+ + + +

Este es un buen ejemplo de una Publicación de Resultados QMO. Tu publicación debe estar sindicada en el Planet en 30 minutos a una hora.  

+ +
+

Información Original de documento

+ + +
+ +

 

diff --git a/files/es/qa/screening_duplicate_bugs/index.html b/files/es/qa/screening_duplicate_bugs/index.html new file mode 100644 index 0000000000..b6480d53cb --- /dev/null +++ b/files/es/qa/screening_duplicate_bugs/index.html @@ -0,0 +1,157 @@ +--- +title: Screening duplicate bugs +slug: QA/Screening_duplicate_bugs +translation_of: Mozilla/QA/Screening_duplicate_bugs +--- +
+ Por Sean Richardson
+

Si has estado confirmando bugs SIN CONFIRMAR o viendo nuevos bugs, te habrás dado cuenta de que todos los bugs que son enviados por reporteros inexperimentados son bugs DUPLICADOS. A pesar de que menos de la mitad resultan ser duplicados, lo mejor es asumir que cada uno lo es hasta que uno se convenza de lo contrario.

+

Esto es una guía que sirve para ayudarle a identificar la máxima cantidad posible de bugs duplicados que llegan de la manera mas eficiente. Se asume que siente cierta comodidad usando Searching Bugzilla.

+

Este tutorial está escrito como si fueras a sentarte y a buscar bugs DUPLICADOS (DUPs) uno tras otros, pero muchos de estos se aplican, no importa como llegues a un bug potencialmente duplicado. Si quieres intentar identificar los bugs DUPLICADOS uno por uno al final de la lista hay una lista de bugs, que indica los tipos de bugs que usualmente están DUPLICADOS.

+

Mientras que estés revisando los reportes de bugs para ver si hay DUPLICADOS, por favor confirma los bugs SIN CONFIRMAR, agrega o simplifica casos de prueba, mejora los pasos para reproducirlo, mejora el resumen, reporta si lo has reproducido en otra plataforma, y/o si has hecho algo mas que tenga sentido antes de moverte al próximo, si el bug no parece ser un DUPLICADO.

+

Para marcar a un bug como DUPLICADO, tu necesitas el permiso "Puedes editar todos los aspectos de cualquier bug". Si no tienes este permiso, manda un e-mail a Gerv o a bugmaster@mozilla.com, y pregunta si lo pueden agregar a tu cuenta de Bugzilla. Mientras tanto, agrega un comentario a cualquier bug mencionando de que es, o puede ser un duplicado.

+

 

+

Los bugs rápidos y obvios

+
+
+ Si no lo has hecho todavía, por favor tomate tu tiempo con la lista de los bugs más frecuentemente reportados de Mozilla y la sección de los Problemas Conocidos en notas de versiones de Firefox.
+
+  
+
+ Si el reporte se parece a una regresión reciente, fijate en los bugs recientemente reportados por el equipo de QA team, y en el newsgroup (netscape.public.mozilla.builds) para ver si el problema ya es conocido.
+
+  
+
+ También puedes ver más en la lista de bugs de hoy para Firefox y Thunderbird. Mira la página de smoketesting si quieres concentrarte en esta área.
+
+ Tendrás menos dicultades escogiendo los bugs duplicados que tu ya cononces que se han reportado. En lugar de ir a través de la lista de bugs en orden, busca en ella bugs cuyos resúmenes parecen familiares, para que puedas tener tantos duplicados como se pueda sin reordenar las busquedas no guiadas.  Los DUPs que tu has reportado o que has encontrado deberían de ser los más fáciles de encontrar, y los más productivos al resolverlos, desde que eres capaz de reconocer y evaluar los identicos rápidamente. 
+
+  
+
+ Some ways to narrow down the query based on what you remember: +
    +
  • If you can remember an e-mail address associated with the existing bug, enter it into one of the Email sections and set the appropriate role(s). Do the same if you think you added a comment to the existing bug.
    • +
  • If you can remember roughly when the bug entered the system, choose "[Bug Creation]" in the Where the field(s) field, and set a date range in the dates and to fields.
    • +
  • If you know you've seen some mail from bugzilla-daemon@mozilla.org on the subject of an existing bug that's a candidate for a match lately, enter a number in the Changed in the last [ ] days field.
    • +
+
+
+ If you get no matches, your recall may be fallible, so try the search again without the restriction.
+  
+
+ If you were able to quickly find the correct bug report to mark a new bug a DUP of, but its summary contains none of the words the reporter of the new bug might have tried to search with, consider adding those words to the summary, or, if you can't do that, including them in a comment suggesting that they be added to the summary -- especially if the bug looks likely to get more duplicates.
+
+

Searching

+
+
+ The first field, Status, is normally preset to find NEW, ASSIGNED, and REOPENED bugs. Add UNCONFIRMED (use Ctrl-click in Windows, Command-click in MacOS) to find duplicates among newly-entered bugs too.
+  
+
+ To cast a wider net, add RESOLVED and VERIFIED, or deselect everything in the Status field. Do this if you wouldn't otherwise expect a long bug list, or when trying again if you got a relatively short list with no matches. It can be easier to find earlier DUPLICATE bugs (which will be RESOLVED) and follow them to the "real" bug, especially if there are several DUPs already. The existing bug you are hunting for may also have been fixed already.
+  
+
+ To exclude obviously extraneous bugs, narrow the search by making a choice under Product. Usually it will be "Core" (for Browser, HTML composition, and text-editing bugs) or "Firefox" or "Thunderbird".
+  
+
+ If the proper component for previously reported bug is obvious (as could be expected for, as an example, most "Bookmarks" bugs), choose that component. You can select multiple components at once. Be prepared, though, to retry you query without specifying a component if you don't find a match - not all bugs end up where you'd expect.
+  
+
+ The same will apply to the Keywords field. Not all bugs that should be labelled "fonts", for instance, necessarily are.
+  
+
+ Beside each of the Summary, Description entry, and URL fields. There is a drop-down that lets you choose the type of matching. Choose among "case-insensitive substring","case-sensitive substring", "all words", "any words", or "regular expression", as appropriate (hints on which work best for several common search scenarios are available in the Text Searching tutorial). Although searching within the Description entry is much slower than any other field, go ahead and use it if it makes sense or the search terms available might not show up in the summary, but try to restrict the search with other fields at the same time if you can.
+  
+
+ Boolean Charts are an advanced feature that can let you do searches that are otherwise impossible. You can use any kind of match with almost any field, and set up boolean ands and ors. The first chart always ands with the rest of the query form. As a trivial example, to search for bugs about the tab key and exclude bugs about tables, add [Summary] [Does not contain (case-insensitive) substring] ["table"] after putting "tab" in the Summary field.{C}
+  
+
+ If you don't find a match on the bug list generated by your first query, it is usually worth trying at least one or two more queries.
+
+

Matching

+
+
+ When the bug list appears, scan it for anything that looks like a possible match. It's useful to open bugs in a new window to preserve the list. At the top of each column, clicking on its name will sort the bugs by that field. You can add other fields to the bug list by clicking on Change columns; for some searches, the Components column can be very useful.
+  
+
+ If you find a clear and certain match, add a comment stating which bug the duplicate bug is a DUPLICATE of (if the bug report that matches is itself a DUP, follow the trail of "This bug has been marked as a duplicate of 00000" comments). If you had to read deep into the existing bug or puzzle out the connection, mention the date of the comment that explains the match or describe the connection.
+  
+
+ If you are not certain of the match, but it looks probable or even possible, add a comment, but also say how sure you are. Even if you are not completely certain that a new bug is a DUP at all, if you think it probably is or even might be, add a comment saying that.
+  
+
+ If the original report is deficient enough that you had to try to reproduce the bug before you could understand what the report was saying, please add enough detail so that the next person reading the bug won't have that problem, and will have an easier time confirming or verifying the match. Even if you don't find a match at all, please do this to make it easier for the next person, who might make the connection immediately given your improved description.
+  
+
+ If the existing bug that the DUPLICATE matches to is in a different component, change the Component field to match the existing bug.
+  
+
+ Finally, if you are sure that the bug is a DUPLICATE, go ahead and click on the radio button beside Resolve bug, mark it as duplicate of bug # [     ] and enter the bug number of the existing bug. Be sure to check for a typo or transposition error before clicking on [Commit].
+  
+
+ If, to the best of your knowledge, a new UNCONFIRMED bug is not a DUP, please follow the steps outlined in the Confirming Unconfirmed Bugs guidelines before moving on to the next.
+
+

Which is the Duplicate?

+
+
+ Other things being equal, newer bugs should be made DUPLICATES of older bugs, but, more importantly, whichever bug is further along in the process of getting fixed should not be made a duplicate. Signs that progess has been made include: +
    +
  • the bug is marked FIXED, a patch is attached or a fix is promised soon
    • +
  • the bug is ASSIGNED to the right Component and developer
    • +
  • the bug has been analyzed by developers
    • +
  • the bug has been given a higher priority (e.g., [PDT+], beta2) or an imminent milestone
    • +
  • the bug report has a explanation of how to reliably reproduce the bug and/or it has a simplified testcase
    • +
+
+
+ UNCONFIRMED and "General" bugs should never have another bug made a duplicate of them unless the other bug is also an UNCONFIRMED or "General" bug. Even then, the bug reports that have less detail and work should be made duplicate of the bug reports that are further along, even if those are older. At that point the bug that receives the DUP should normally be confirmed, if it is not already.
+  
+
+ If you are stumped, add a comment resembling the following: + 
This bug appears to be a duplicate of bug nnnnn, but
+I'm not sure which should be made DUPLICATE of which.
+
+
+

One Down, or, Keeping in the Groove

+
+
+ Take another look at the bug list after making a match: there may well be another DUPLICATE of the same bug lurking there. You might also see two bugs on the list that look suspiciously similar even though neither matches the bug you started with.
+  
+
+ After some time you will naturally become much more familiar with some types of issues and some components than others. Go with that, focus on the areas you can make sense of quickly. You might also have some existing expertise or experience that makes it easier for you to evaluate some bugs. If you know javascript well, for instance, it makes sense to check over new-to-you DOM bugs before identifying duplicates in any other area.
+  
+
+ Similarly, let your tools guide you, to some extent at least. If you know how to use a Debugger, you can make more of a contribution to evaluating Crashers than others can, so it makes sense to look at them. Similarly, some bugs that are reported on Linux, Macs, or other platforms are specific to the platform or platform/OS combination that they were reported on. Someone unfamiliar with that platform won't be as efficient, so if you regularly use something other than Microsoft Windows, please look at bugs reported on your platform first, by selecting it on the query page. Use the Edit this query link at the bottom of a bug list to get back to the query form if you can't use the [Back] button.
+  
+
+ By concentrating on the bug reports that you have the skills and experience to evaluate quickly and surely, you will be able to help more in the time you can contribute.
+
+

Specific Types of Duplicates

+

Some types of bug reports need or can benefit from special handling:

+
    +
  1. Bug reports about a particular URL: Check first for a substring (usually just the domain name is appropriate) of the URL in the URL field, matching against bugs with any Status. Obvious exact DUPs should show up easily that way, so long as the reporter filled in the URL field. In case that was not done, check in the Description entry field if there is no match in the URL field.
    2. +
  2. Reports of Crashes: Crashes are identified by what specific code crashed, not how they are reproduced, so some sort of debugging output may be required before a determination can be made whether a crash report is a DUP. If you reproduce a crash on a previously unreported platform or OS, or using a current binary when the reporter was using a milestone release, please add as much detail as you can. If a module name is reported or you can generate a stack trace, search in Bugzilla for bugs with the crash keyword. If you don't find a match, add "crash" to the keywords field, so long as you were able to reproduce the crash.
    3. +
  3. Multiply-DUPLICATE reports: Some bug reports describe a number of often unrelated problems. If all of the problems mentioned are clearly duplicates of existing bug reports, mark the new bug report as a DUPLICATE based on the first issue. If it is clear that all but one of the problems have already been reported, state that, citing the bug numbers if possible, and adjust the Summary to refer to the remaining problem.
    4. +
  4. "General" bug reports: Be sure to move the bug to the appropriate Component if you can identify it, and copy over the QA contact, at the same time that you mark it as a DUP, so that it can be verified by someone familiar with the existing bug report.
    5. +
  5. Same Exact Bug, two bug numbers: Sometimes a bug report ends up in the Bugzilla database twice in a row. If you see two bugs with the same summary and adjacent bug numbers, mark one as a DUP of the other immediately, before both get comments -- but look at both first, in case one has comments already.
    6. +
  6. An ASSIGNED bug may be a DUP: It does sometimes happen that one assigned bug is a duplicate of another. If both are assigned to the same engineer, add a comment to the one that is not as far along as the other; if two different engineers are involved, add a comment to both, pointing out the existence of the other and why it appears to be a DUP. Do not resolve ASSIGNED bugs as DUPs yourself; the assignee should do that.
    7. +
+

Lists Where Duplicates Lurk

+
+
+ The greatest concentration of duplicate bugs is in those that enter the database as UNCONFIRMED, although plenty of NEW bugs also turn out to be DUPs. Bugs do occasionally get ASSIGNED before being found to be a DUP, but that is what duplicate-screening is meant to prevent, so please concentrate on UNCONFIRMED and NEW bugs.
+  
+
+ The bug lists below are displayed in rough descending order of prevalence of duplicates. They will appear in new windows; you may want to open bugs from the list in new windows too, to preserve the list. Happy matching; if you find only one DUP, you'll have earned the thanks of a busy software enginner.
+  
+
+ + +
+
+

(Thanks to Jan Leger, Eli Goldberg, David Baron, John Morrison, Matthew Thomas, Gervase Markham, Liz Henry, and Terry Weissman for contributing to this document. Additional suggestions welcome.)

-- cgit v1.2.3-54-g00ecf