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 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 lanzamientos Releases - Probar versiones alpha, beta y RC (Candidatas para lanzamientoser Releases) antes de que el software esté disponible públicamente (donde "Disponible públicamente" significa "Lista Listo para ser usada 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 lanzamientosreleases, 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 Lanzamientos - 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 produzca lance una release etiquetada (p. ej. 2.9.0, 2.9.1, 2.9.2, 2.9.3, etc) se eligen planifican periodos de tiempo específicos para testear, utilizando un Plan de Testeo y concentrándose 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 (las fases pueden ser Alfa, Beta, RC. ..). Por ejemplo, podrían publicarse varias versiones Beta del software antes de que el Sakai Core Team apruebe que el mismo está listo para el lanzamiento.  Habitualmente dicho software está lo suficientemente maduro.  Tras ello, habitualmente se sacan dos o tres versiones Release Candidate del software. Una versión Release Candidate (Candidata a Lanzamiento) es una versión del software la cualque, si pasa el testeo QA y el escrutinio de los desarrolladores, se convertirá en el siguiente lanzamiento oficial etiquetado la siguiente versión etiquetada de la comunidadComunidad Sakai. Cada lanzamiento versión Beta y RC es una fase del proceso de Lanzamiento Publicación de Software .

Our goal is to have testing happen as much as possible throughout the Sakai version lifecycle (verifying bug fixes in trunk, testing new features, and regression testing the latest release). However, when we are getting close to having a tagged release (e.g. 2.9.0, 2.9.1, 2.9.2, 2.9.3, etc) we choose specific periods of time to test, with a Test plan and focus. We call these testing efforts "Test Fests". We have multiple Test Fests to get out a release. Unless otherwise specified we have one "Test Fest" per phase of the release. For example, we might have several Beta versions of the software before the Sakai core team feels confident that it is ready for release. Typically, we then have two or three Release Candidates of the software. A Release Candidate is a version of the software, which if it passes QA testing and Developer scrutiny, will become the next official community release. Each of these Beta releases and Release candidates is a phase of our Software Release process. 

What makes a Test Fest unique is that we create a Test plan to guide our testing, a defined period of time to complete the testing, and a review process to assess the state of our testing results. Test Fest's typically take a concentrated effort and we like to have as many testers as possible helping in the effort, sometimes with multiple testers focusing on the same functional areas to provide the highest confidence level we can reasonably achieve. Test Fests are almost always carried out on special QA test servers which have been updated with the correct version of the software which needs testing. The Test Plan will indicate which QA servers are available for testing. 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
QA team meetings

Stay tuned for more information. 

Anchor
ExpertQAKnowledge
ExpertQAKnowledge
Expert QA knowledge

  • Accessibility Testing
  • Localization Testing (different languages)
  • Review of patches and fixes
  • Testing locally
  • Automated testing
  • Security testing (requires special permission)

General Testing Tips

Include Page
General Testing Tips
General Testing Tips