Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Sv translation
languagees

Table of Contents

Propósito

QA significa Aseguramiento de la Calidad. En este contexto, la misión de la QA es principalmente descubrir y reportar errores en el software, verificar los arreglos de estos errores y comprobar posibles regresiones. Las regresiones son funcionalidades que funcionaron en versiones anteriores pero están rotas en la versión actual.

Pre-requisitos para participar

Requerido - Se requiere una cuenta en Jira. Inscríbase en https://jira.sakaiproject.org

RequeridoUnase a la lista de correo Sakai QA (sakai-qa@collab.sakaiproject.org) o a Sakai Dev (sakai-dev@collab.sakaiproject.org) para estar informado de los últimos anuncios y de las distintas formas de ayudar en las iniciativas comunes de testeo.

Opcional - Grupo JIRA QA - permisos especiales - No son necesarios permisos especiales para testear arreglos y para comentar en los tickets de Jira. En JIRA hay un botón "Tested" que indica el testeo con éxito del ticket. Este botón sólo está disponible para los miembros del grupo Jira QA. El permiso se proporciona a testers experimentados. Contacte con neal.caidin@apereo.org para más información.

Trucos - Nuestras principales herramientas son JIRA, hojas de cálculo de Google Docs y servidores QA. Aprender cómo usar JIRA y qué función tiene cada campo de un ticket merece la pena.

Formas de participar

  • Verificando errores que han sido arreglados.
  • Probando nuevas funcionalidades.
  • Test de regresión de funcionalidades existentes.
  • Creando scripts de Regresión (p.ej. instrucciones paso a paso para comprobar una regresión).
  • Testeo de Releases - Probar versiones alpha, beta y RC (Candidatas para ser Releases) antes de que el software esté disponible públicamente (donde "Disponible públicamente" significa "Listo para ser usado en producción").
  • Ayudando a mantener la documentación de QA en Confluence. Correcciones. Sugerencias. Creación de vídeos cortos.
  • Preguntando y respondiendo a preguntas en las listas de correo.
  • Reuniones con el equipo QA. Acudir a las reuniones QA para discutir de problemas que requieran atención, para ayudar a planificar el testeo de releases, etc.
  • Conocimiento experto de QA necesario - Algunos tipos de QA necesitan de habilidades especiales por parte del testeador.

Anchor
VerifyingBugs
VerifyingBugs
Verificando errores arreglados

La mayor parte del testeo debería hacerse en el servidor Trunk QA nightly server. Debe tenerse en cuenta que este servidor se actualiza a la última versión de Sakai cada 4 horas, comenzando cada medianoche en horario Eastern (-4 o -5 GMT). Por ello, debe planificarse el testeo apropiadamente. Cuesta unos 20 minutos que Sakai se recompile y se despliegue. Así que, por ejemplo, entre las 12:20 pm y las 3:59 pm (en horario Eastern) sería una buena hora para trabajar en él.

Los tickets de JIRA que tienen "Fixed" en el campo resolution y "Resolved" en el campo status están listos para ser testeados. Si el testeo es exitoso se debe pulsar el botón Tested, tras lo que el status cambiará a "Verified". Si el botón Tested no es visible, incluso con los campos status y resolution correctos, es probable que se deba a una falta de permisos para ver dicho botón. Es necesario contactar con neal.caidin@apereo.org para solicitar este permiso.

Al documentar un ticket, se deben incluir los navegadores y sistemas operativos en los que se ha producido el testeo y el número de revisión de la versión trunk. El número de Revisión es importante porque el código de la versión trunk cambia frecuentemente. El número de revisión aparece en el fondo de la ventana del navegador.

Nota: Algunos problemas pueden requerir testeo en más de una combinación de S.O. y navegador.

Un error que supuestamente está arreglado, ¿no?

Si se verifica un arreglo y no funciona, entonces debe reabrirse el ticket con el botón Reopen. Esto indica al desarrollador que falta trabajo por hacer. Si no se está seguro de si el ticket debería ser reabierto, puede ponerse un comentario para que otros lo decidan. En el comentario se deben incluir los pasos exactos de cómo falló, en qué servidor, el número de revisión de dicho servidor, navegador/S.O., etc.

Anchor
TestNewFeatures
TestNewFeatures
Pruebas de Nuevas Funcionalidades

Probar nuevas funcionalidades funciona básicamente igual que probar arreglos de errores. También se pulsa el botón Tested para que el ticket pase a estar con estatus Verified si el testeo es correcto y el botón Reopen (o el comentario oportuno) si no lo es. A veces sucede que se debate sobre si un ticket es un error o una nueva funcionalidad. Estos debates suceden en los comentarios del ticket y a veces se trasladan a grupos como el Sakai Core Team para una discusión más amplia.

Anchor
RegressionTest
RegressionTest
Testeo de Regresiones

El testeo de regresiones consiste en probar al detalle una herramienta comprobando si tiene "regresiones". Las regresiones son funcionalidades de la herramienta que funcionaban en versiones anteriores de Sakai pero que no lo hacen en la versión actual. El testeo de regresiones busca descubrir estos fallos, repitiendo manualmente una serie de pasos en la herramienta que deben dar un determinado resultado.

La lista más actualizada de herramientas para las que existen scripts de regresiones (pasos para comprobar manualmente las funcionalidades) y de sus scripts se almacena en un documento Tools Google doc.

Testeo de Releases - Centros de Pruebas QA

El objetivo principal es tener el máximo testeo posible a lo largo del ciclo de vida de una versión de Sakai (verificar arreglos de errores en trunk, testear nuevas funcionalidades y testeo de regresiones en la versión más actual). Sin embargo, cuando se acerca el momento de que se lance una release etiquetada (p. ej. 2.9.0, 2.9.1, 2.9.2, 2.9.3, etc) se planifican periodos de tiempo específicos para testear, utilizando un Plan de Testeo y concentrando a los testeadores en él. A estos esfuerzos colaborativos se les llama "Test Fests".

Hay multiples Test Fests en una Release. A menos que se especifique lo contrario, hay una Test Fest por cada fase de la Release. Por ejemplo, podrían publicarse varias versiones Beta del software antes de que el Sakai Core Team apruebe que dicho software está lo suficientemente maduro.  Tras ello, habitualmente se sacan dos o tres versiones Release Candidate del software. Una versión Release Candidate es una versión del software que, si pasa el testeo QA y el escrutinio de los desarrolladores, se convertirá en la siguiente versión etiquetada de la Comunidad Sakai. Cada versión Beta y RC es una fase del proceso de Publicación de Software del Proyecto Sakai.

Lo que hace especial una Test Fest es que se crea un Plan de Testeo que guía a los testeadores, un periodo de tiempo definido para completar el testeo y un proceso de revisión que evalúa los resultados del testeo. Las Test Fests normalmente concentran los esfuerzos y necesitan de la ayuda de tantos testeadores como sea posible, a veces con muchos testeadores enfocándose en la misma área funcional, de forma que se alcance el máximo nivel de confianza posible sobre el testeo. Las Test Fests casi siempre son celebradas en los servidores QA especiales que son actualizados a la versión correcta del software que se pretende testear. El Plan de Testeo indicará qué servidores QA están disponibles para trabajar en cada momento.

Anchor
QATeamMeetings
QATeamMeetings
Reuniones del equipo QA

Se debe estar atento a la lista de correo. Más información sobre este tema será proporcionada.

Anchor
ExpertQAKnowledge
ExpertQAKnowledge
Conocimiento Experto de la QA

  • Testeo de accesibilidad
  • Testeo de la Localización (diferentes lenguajes)
  • Revisión de parches y arreglos
  • Testeo local
  • Testeo automático
  • Testeo de seguridad (requiere un permiso especial)

Consejos Generales de Testeo

Include Page
General Testing Tips
General Testing Tips