Control de calidad/Participar

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/GetInvolved and the translation is 95% complete.
    Outdated translations are marked like this.


    Primeros pasos

    ¿Qué es el control de calidad?

    El control de calidad, a veces conocido también como QA (por abreviación de quality assurance), permite identificar problemas en nuestro software, confirmar los problemas de los que nos informan los usuarios y validar las correcciones y mejoras propuestas, de tal modo que cada versión nueva de LibreOffice sea más confiable y robusta y, con ello, los usuarios reciban una herramienta más satisfactoria. Efectuamos control de calidad de diferentes formas durante el desarrollo de una versión nueva.

    Nuestro primer objetivo es encontrar o confirmar los más vergonzosos y urgentes «bugs» y gestionarlos con los desarrolladores para que ellos se encarguen. Por tanto, somos un puente entre los usuarios y los desarrolladores. Tratamos de guiar cada informe de «bug» hacia la resolución apropiada, bajo la premisa de mejorar la experiencia de usuario. Tratamos de reproducir los «bugs», asignarles la correcta prioridad, encontrar duplicados y validar las mejoras propuestas, entre otras tareas.

    Guía de inicio rápido para principiantes

    Si es usted un principiante, es probable que no esté en sus miras sumergirse en una gran cantidad de documentación técnica. Más bien, prefiere poner manos a la obra inmediatamente. Vamos a ello.

    1. Descargue e instale la versión estable más reciente de LibreOffice (de la línea «Fresh», que es la que corresponde al primer enlace)
    2. Descargue e instale una compilación reciente de la rama «master» de LibreOffice
    3. Créese una cuenta en el Bugzilla de la TDF
    4. Abra esta consulta para obtener los informes no confirmados del pasado mes (las solicitudes de mejora se omiten a propósito; algunas otras cosas también se filtran)
    5. Escoja un «bug» que le llame la atención.
    6. Busque duplicados (instrucciones aún en inglés).
    7. Si el «bug» no es un duplicado, pero tiene una descripción confusa o le faltan datos esenciales, marque el estatus como NEEDINFO (instrucciones aún en inglés).
    8. Después de intentar reproducirlo, usando tanto la versión estable más reciente («Fresh») como la compilación más reciente de la rama «master», marque el estatus del bug como NEW o déjelo como UNCONFIRMED (instrucciones aún en inglés).

    Estos pasos intencionalmente describen un triaje incompleto, que se hace así para que los ingenieros no se sientan abrumados por la inmensa cantidad de detalles que uno debe tener en cuenta si uno se enfoca en obtener un triaje perfecto. Una vez que como principiante se sienta cómodo con esta rutina, puede avanzar hacia el triaje mucho más completo (instrucciones aún en inglés). No es eficiente dejar que otros completen el triaje que hemos iniciado.

    Hoja de ruta para el crecimiento personal en QA

    Cada uno tiene su propio camino cuando se acerca al control de calidad en LibreOffice. Sin embargo, hay personas más motivadas porque cuentan con un marco conceptual más claro de lo que se espera que hagan. Aquí presentamos una propuesta de evolución de una carrera en control de calidad:

    1. Realice la sencilla rutina de triaje descrita en la Guía de inicio rápido para principiantes para unos 50 «bugs» no confirmados, más o menos.
    2. Vuelva a validar 50 «bugs», más o menos, que no hayan sido tocados en más de un año. con una compilación diaria de la rama «master» de LibreOffice.
    3. Aprenda los conceptos (instrucciones aún en inglés) más importantes y comience a usarlos: accessibility, bibisectRequest, dataLoss, filter:x, needUITest, perf, regression, text:x, wantBacktrace.
    4. Instale una gran cantidad de versiones anteriores y realice validaciones de regresión (instrucciones aún en inglés) para más de 100 «bugs» sin confirmación.
    5. Aprenda sobre priorización y severidad (instrucciones de ambas secciones aún en inglés) y solicite el acceso al grupo Contribuidores a un administrador de Bugzilla.
    6. Comience de manera crítica la evaluación de solicitudes de mejora, mientras las redirige al equipo de diseño usando la palabra clave needsUXEval (instrucciones aún en inglés).
    7. Comience haciendo bibisecciones. Primero, complete el tutorial de bibisección y marque los informes con la palabra clave bibisectRequest.
    8. Aprenda Python y comience a crear pruebas de UI (interfaz de usuario, por sus siglas en inglés).
    9. Cree pruebas unitarias en Python.
    10. Aprenda C++ y cree pruebas cppunit.

    Confirmar

    Encontrar informes sin confirmación

    • Por sistema operativo:
    All Linux macOS Windows Android
    • Por período:
    últimas 24 horas última semana último mes últimos 6 meses

    Informes sin confirmación y sin comentarios

    Para acelerar el triaje de los informes sin confirmación, automáticamente los marcamos con QA:needsComment en la pizarra, si el informe cumple con estas condiciones:

    • Ha estado inactivo por más de dos semanas
    • No tiene comentarios de un tercero

    Revise la lista aquí

    Tratar de reproducir el «bug»

    Ya que algunos «bugs» son específicos de un sistema operativo, siempre es buena idea verificarlo en el mismo sistema operativo. Sin embargo, si esto no es posible, lleve a cabo la verificación en su propio sistema operativo, ya que la mayoría de los «bugs» no son específicos de un sistema operativo.

    Abajo encontrará comentarios frecuentes que son comunes en ciertos escenarios. Para más sugerencias sobre cómo responder los informes y las herramientas del navegador que pueden ayudar a realizar esta labor eficientemente, vea Respuestas preescritas (instrucciones aún en inglés).

    • Si el «bug» se puede reproducir, marque el estatus como NEW (nuevo) y agregue el siguiente comentario:
    Thank you for reporting the bug. I can confirm that the bug is present in
    
    [los detalles de la versión de LibreOffice con que probó (puede copiarlos del diálogo Ayuda ▸ Acerca de LibreOffice]
    
    • Si el bug no se puede reproducir, deje el estatus como UNCONFIRMED (sin confirmar) y agregue el siguiente comentario:
    Thank you for reporting the bug. I can not reproduce the bug in
    
    [los detalles de la versión de LibreOffice con que probó (puede copiarlos del diálogo Ayuda ▸ Acerca de LibreOffice]
    
    • Si la descripción del informe del «bug» es de difícil comprensión, marque el estatus del «bug» como NEEDINFO (se requiere más información) y agregue el siguiente comentario:
    Thank you for reporting the bug. 
    Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem. 
    Please provide a clearer set of step-by-step instructions on how to reproduce the problem.
    I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested information is provided.
    
    • Si se necesita un documento para confirmar el «bug», marque el estatus del «bug» como NEEDINFO (se requiere más información) y agregue el siguiente comentario:
    Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
    I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
    (Note that the attachment will be public, remove any sensitive information before attaching it.
    See <https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F> for further detail.)
    

    Pasos adicionales

    • En el caso de que el campo Summary (resumen) del «bug» no sea suficientemente claro, actualícelo para que explique de mejor manera el problema principal/actual que se está abordando y para que sea más sencillo encontrar duplicados.
    • El campo Component (componente) también puede ser actualizado para que se especifique mejor en qué componente se encuentra el problema o dónde se origina.
    • Los informes de «bugs» de mejoras, donde se solicite la adición de nuevas características, debe ser primero evaluados por el equipo UX para determinar si deben o no ser implementados; así que simplemente agregue needsUXEval en el campo Keywords y agregue libreoffice-ux-advise@lists.freedesktop.org en la lista CC.
    • Verifique si el «bug» es una regresión (instrucciones aún en inglés).


    Siga el desarrollo actual de los «bugs» sin confirmación (en inglés) y lea las instrucciones detalladas para el triaje de «bugs», para más detalles (instrucciones aún en inglés).

    Probar compilaciones diarias

    1. Descargue la última compilación diaria (asegúrese que la fecha es reciente)
    2. Instálela (instrucciones aún en inglés)
    3. Pruébela. Verifique las Notas de la versión (probablemente no estén traducidas al español) para ver qué hay de nuevo en esta versión.
    4. Si encuentra un «bug», por favor informe de ello siguiendo este enlace y proporcione toda la información disponible (los pasos para reproducirlo, el documento afectado, la descripción detallada, el sistema operativo, …)

    Nota: Para obtener ayuda, únase al canal IRC #libreoffice-qa IRC://.

    Probar los prelanzamientos

    1. Descargue la última versión de prelanzamiento
    2. Instálela (instrucciones aún en inglés)
    3. Pruébela. Verifique las Notas de versión (probablemente no estén traducidas al español) para saber qué hay de nuevo en esta versión.
    4. Si encuentra un «bug», por favor informe de ello siguiendo este enlace y proporcione toda la información disponible (los pasos para reproducirlo, el documento afectado, la descripción detallada, el sistema operativo, …)

    Nota: Para obtener ayuda, únase al canal IRC #libreoffice-qa IRC://.

    Probar de nuevo

    Todos los días volvemos a revisar «bugs» que no se han tocado en más de un año para verificar si ya se han arreglado con las mejoras de cada nueva versión. Puede encontrar más información en el artículo Tareas automatizadas (aún en inglés).

    Encontrar «bugs» para probar nuevamente

    • «Bugs» que se han revisitado hoy:
    All Linux macOS Windows Android
    • «Bugs» que se han revisitado en la semana pasada:
    All Linux macOS Windows Android
    • «Bugs» que se han revisitado en el mes pasado:
    All Linux macOS Windows Android
    • «Bugs» que se han revisitado en los últimos tres meses:
    All Linux macOS Windows Android
    • «Bugs» que se han revisitado en la última mitad del año:
    All Linux macOS Windows Android

    Tratar de reproducir el «bug»

    Si el «bug» se encuentra presente en la última versión de LibreOffice, ponga el siguiente comentario con los detalles de la versión de LibreOffice que está probando (copie los datos desde el diálogo Ayuda ▸ Acerca de LibreOffice).

    This bug is still present in
    
    [los detalles de la versión de LibreOffice que probó (copie los datos desde el diálogo Ayuda ▸ Acerca de LibreOffice).]
    

    Si el «bug» no está presente y usted está seguro que ha seguido correctamente los pasos para reproducirlo, cambie el estatus a RESOLVED WORKSFORME y ponga el siguiente comentario:

    This bug is no longer reproducible in
    
    [los detalles de la versión de LibreOffice que probó (copie los datos desde el diálogo Ayuda ▸ Acerca de LibreOffice).]
    
    Changing status to RESOLVED WORKSFORME
    

    Por favor, no…

    • …actualice el campo de la versión
    • …responda vía correo electrónico; en vez de eso, responda directamente en el rastreador de «bugs»
    • …cambie el campo de Status a RESOLVED - FIXED, ya que ese estatus solo se usa cuando un «commit» específico ha solucionado el problema

    Pasos adicionales

    • Compruebe si el «bug» es una regresión (instrucciones aún en inglés)

    Contacto

    Cualquier ayuda es bienvenida. Puede ponerse en contacto con nosotros (en inglés, solamente, porque es un ambiente multicultural)…