OOoES/Desarrollo/Aseguramiento de la calidad
From OpenOffice.org Wiki
Contents |
Inicio
La comunidad del proyecto OpenOffice.org en español debe realizar una serie de pruebas sobre las versiones traducidas (localizadas) al español. Este proceso de verificación es obligatorio para que las versiones traducidas puedan ser distribuidas mundialmente a través de la red de servidores espejo (mirrors) de OpenOffice.org.
Las pruebas que se llevan a cabo durante el proceso de desarrollo pueden clasificarse básicamente en tres tipos: pruebas funcionales, pruebas de localización, y pruebas de versiones. La siguiente tabla muestra las diferencias entre estos tipos de pruebas:
| Objetivos | Destinatarios | Criterios | Periodo | Requisitos | |
|---|---|---|---|---|---|
| Pruebas funcionales | Asegurar que todas las funciones trabajan bien | Funciones añadidas o modificadas | Las funciones deben trabajar bien en los lenguajes localizados. | Continuo | Información sobre las funciones, tales como especificaciones |
| Pruebas de localización | Alcanzar un grado aceptable de traducción | Textos traducidos que se han añadido o revisado | Las traducciones deben ser apropiadas al contexto | Una o dos semanas | Información para visualizar los diálogos con las traducciones, cómo llegar a las páginas relevantes de la ayuda en línea |
| Pruebas de versiones | Distribución de versiones de buena calidad | Cada paquete de instalación | Sin defectos críticos (show-stoppers); buenas para el uso diario | Una semana | Conocimiento del lenguaje local |
OpenOffice.org tiene un proyecto dedicado al aseguramiento de la calidad (Quality assurance). No es necesario participar en las pruebas de funcionalidad del software, si bien se agradecen las contribuciones. Lo que se necesita es probar la versión localizada en español. El proyecto de aseguramiento de la calidad (QA) tiene muchas herramientas, que están disponibles en el sitio de OpenOffice.org y otros lugares.
La comunidad de OpenOffice.org en español realiza, por lo tanto, las pruebas de localización y las pruebas de versiones Release Candidate (candidatas para lanzamiento, o RC por sus siglas en inglés).
El proceso de QA de la localización
Las pruebas de localización están relacionadas íntimamente con el proceso de traducción (localización) en el que también participa la comunidad de OOoES.
Durante los procesos de localización para las versiones que están en preparación, la comunidad colabora en la traducción de cadenas, tanto de la interfaz de usuario (UI) como de la ayuda en línea (helpcontent2), desde el inglés al español.
Existe un breve periodo de verificación, generalmente de dos semanas, desde que se publica la versión que integra las nuevas cadenas traducidas o modificadas, hasta que se realiza el congelado del código (code freeze) donde ya no se aceptan modificaciones a la traducción. En este periodo hay que verificar velozmente que las traducciones realizadas se adapten al contexto en el que son utilizadas, que no queden cadenas sin traducir, y que la integración se haya realizado correctamente.
El proceso de QA de las versiones RC
- Se anuncia la disponibilidad de una nueva versión en español para pruebas a través de la lista de correo releases/AT/openoffice.org.
- El líder del proyecto de lenguaje nativo (Alexandro Colorado) o el encargado de QA (Santiago Bosio) cargan esos enlaces en la herramienta de seguimiento del proceso de QA: QATrack.
- El encargado de QA notifica a los verificadores sobre la disponibilidad de la nueva versión de pruebas, y les asigna pruebas a realizar a través de la heramienta de administración de pruebas: La herramienta TCM.
- El líder de QA actualiza el estado en la herramienta QATrack para indicar que se encuentra en proceso de verificación.
- Los verificadores realizan las pruebas e ingresan sus resultados en la herramienta TCM.
- Después que se completan los tests asignados, el líder de QA actualiza la página de estado de QATrack y registra un issue en IssueZilla, indicando que el paquete está listo para la distribución.
- El líder del proyecto de lenguaje nativo actualiza la página de descargas del proyecto para anunciar la disponibilidad de la nueva versión aprobada y definitiva.
Actualmente las pruebas asignadas corresponden al escenario Release sanity disponible en TCM, debido a que no existen suficientes verificadores en las distintas plataformas para realizar mayor cantidad de pruebas. Este tipo de pruebas sirven para verificar rápidamente una versión que se va a lanzar, y es lo mínimo que se exige para poder aprobar dicha versión.
Las pruebas en el escenario Release sanity están diseñadas con el propósito de asegurar que no se hayan producido errores en el proceso de compilación del paquete. No se busca profundizar en la funcionalidad de la aplicación, sino que hay que enfocarse en los problemas que hubieran podido surgir durante los procesos de compilación o integración de la traducción dentro del paquete.
Cómo colaborar en el proceso de QA
Las necesidades actuales son las siguientes:
- Incorporar nuevos verificadores para las siguientes plataformas:
- Solaris/Sparc
- Mac OSX/PPC (X11/Aqua)
- Incrementar la cantidad de verificadores para las plataformas:
- Linux x86 (distros basadas en RPMs o DEBs)
- Windows32 (Windows 98/NT/XP/Vista)
- Linux x86_64 (RPM/DEB)
- Solaris/Intel
- Mac OSX/Intel (X11/Aqua)
Para colaborar como verificador deberás estar registrado en el sitio de TCM. Envía una solicitud por correo electrónico al líder de QA indicando tu nombre, el nombre de usuario que quieres usar en el sitio, la/s plataforma/s para la que deseas realizar pruebas, y la disponibilidad de tiempo que puedes dedicar a esta tarea. Ten en cuenta que los cronogramas para realizar las pruebas son muy ajustados, así es que debes indicar tu disponibilidad real para que no queden pruebas sin realizar.
El equipo de verificadores
- Santiago Bosio, líder de QA para OOoES.
- Alexandro Colorado, co-líder de QA y líder del proyecto OOoES.
- Freixo, verificador, plataforma Windows.
- Francisco Alcaraz, verificador, plataforma Linux x86.
- Omar Concepción, verificador, plataforma Windows.
- Luis Vasquez, verificador, plataformas Windows / Linux x86.
- Mauricio Baeza, verificador, plataforma Linux/x86_64.
- Richard Holt, verificador, plataforma Linux/x86_64.
- Nicolás Alonso, plataforma Solaris/Intel.
- Gonzalo Higuera Díaz, plataforma Mac OSX/Intel.
Estado actual del proceso de QA
- 21 de febrero al 17 de marzo de 2008
- Pruebas de los paquetes RC de la versión 2.4.0
- Estado de pruebas para la versión 2.4.0rc1: Aprobada de acuerdo al escenario Sanity Check.
- Estado de pruebas para la versión 2.4.0rc2: No concluyente, faltan pruebas debido a la liberación de la RC3.
- La versión 2.4.0rc3, no llegó a distribuirse completamente, porque presentaba errores críticos.
- Estado de pruebas para la versión 2.4.0rc4: En proceso...
Asignación de escenarios de prueba en TCM
Tabla de pruebas TCM asignadas, verificando versión 2.4.0RC:
| Verificador | Plataforma | Escenario de pruebas | Avance |
|---|---|---|---|
| Santiago Bosio | Win32 (XP) | Sanity Check | rc1: 100%, rc2: 25% |
| Santiago Bosio | Linux x86 (DEB) | Sanity Check | rc1: 10%, rc2: 5% |
| Freixo | Win32 (XP) | Base | rc1: 100%, rc2: 0% |
| Francisco Alcaraz | Linux x86 (RPM) | Base | rc1 58%, rc2: 0% |
| Mauricio Baeza | Linux x86_64 (RPM/DEB) | Sanity Check | rc2: 0% |
