Configuraciones y recomendaciones de uso de TestLink (versión 1.8.4)

Nomenclatura y Organización

Organización

En TestLink se dan de alta tantos Test Proyect como aplicaciones distintas vayan a incorporarse al proceso de verificación. Para cada Test Proyect se crea un primer nivel de subcarpetas o Test Suite, formado por los distintos módulos que componen la aplicación. Dentro de cada módulo encontraremos los Test Case, en ocasiones organizados dentro de otro nivel de subcarpetas o Test Suite que los agrupe, por ejemplo, por funcionalidad o por servicios para los que han sido diseñados. Finalmente la estructura de carpetas (Test Suite) dentro de un Test Proyect debería tener el siguiente aspecto:

Nomenclatura TestCase con módulos

Nomenclatura

Los Test Case que se encuentran dentro de las subcarpetas deben seguir la siguiente nomenclatura:

<nombreProyecto> - <nº de la prueba> - <Código en el Plan de Pruebas> - <nombreDescriptivo>

donde:

• nombreProyecto: es el nombre del Test Proyect.
• nº de la prueba: a cada prueba se le asigna un número correlativo que la identifica dentro del Test Proyect
• Código en el Plan de Pruebas: en ocasiones el Test Case se basa en un caso de prueba contenido en un Plan de Pruebas entregado por el equipo de desarrollo, el código se conserva para tenerlo identificado.
• nombreDescriptivo: eescripción corta del caso de prueba.

Los Test Plan van a servir para agrupar los casos de prueba o Test Case que se van a ejecutar en un servicio para una versión determinada de la aplicación. La nomenclatura que se debe seguir para la definición de los Test Plan es la siguiente:

<nombreProyecto> - <nombreMódulo> - <nº versión: 9.9.9.99> - <Servicio> - <Nivel>

donde:

• nombreProyecto: es el nombre del Test Proyect.
• nombreMódulo: se corresponde con los nombres de los módulos en que se divide la aplicación objeto del proyecto.
• nº versión: se refiere a la versión del producto software que se pretende probar.
• Servicio: código identificativo del servicio para el que son requeridas las pruebas contenidas en el Test Plan.
• Nivel: hace referencia al nivel de certificación elegido para la ejecución del servicio.

Los Builds constituyen cada una de las ejecuciones de los Test Plan efectuadas en los distintos entornos, y en ellos se recogen los resultados de cada Test Case que componen el Test Plan. La nomenclatura que se debe seguir para su definición es la siguiente:

<SO> - <JVM> - <Ser. Apl.> - <Ser. BD> - <navegador> - <versionNavegador>

donde solo se deben especificar las características diferenciadoras entre los distintos entornos de ejecución de las pruebas.

Usuarios y Permisos

Vamos a distinguir entre los siguientes grupos de usuarios:

• Directores Técnicos y Gestores de Proyectos
• Equipo de Gestión de Servicios
• Equipo de Testing
• Jefes de Proyecto

Directores Técnicos y Gestores de Proyectos

Los usuarios pertenecientes a este grupo tendrán un rol denominado Oficina Proyectos que constará de los siguientes permisos:

• En Test Plan: Métricas del Test Plan
• En Gestión de Test Cases: Ver Test Cases (acceso sólo lectura)
• En Requerimientos: Ver Requerimientos (acceso de sólo lectura)
• En Campos Personalizados: Ver Campos Personalizados (acceso de sólo lectura)

Con esta configuración, los usuarios podrán ver los Test Cases disponibles, así como poder acceder a la Gestión de Requerimientos, donde podrá asociar los distintos Test Cases a un determinado requerimiento.

Equipo de Gestión de Servicios

Los usuarios pertenecientes a este grupo tendrán un rol denominado Oficina Testing que constará de los siguientes permisos:

• En Usuarios: Gestión de Usuarios, Gestión de Roles, Asignación de Roles
• En Test Plan: Asignación de roles
• En Gestión de Test Cases: Ver Test Cases (acceso sólo lectura)
• En Requerimientos: Ver Requerimientos (acceso de sólo lectura)
• En Keywords: Ver Keywords (acceso de sólo lectura)
• En Campos personalizados: Ver Campos Personalizados (acceso de sólo lectura)
• En System Rights: Event management

Con esta configuración, los usuarios podrán realizar la gestión de usuarios de la aplicación, además de ver los Test Cases creados , así como los requerimientos.

Equipo de Testing

Para estos usuarios se ha pensado en la creación de dos roles diferenciados que pasamos a describir:

Usuario Avanzado

Los usuarios pertenecientes a este grupo tendrán un rol denominado "Oficina Ejecución Testing - Avanzado" que constará de los siguientes permisos:

• En Test Plan: Ejecutar Test Plan, Crear/Editar Build, Métricas del Test Plan, Planificación del Test Plan
• En Gestión de Test Cases: Ver Test Cases (acceso de sólo lectura), Crear/Editar Test Case, Crear/Editar Test Plan
• En Requerimientos:Ver Requerimientos (acceso de sólo lectura), Gestión de Requerimientos
• En Test Project: Gestión de Test Projects
• En Keywords: Ver Keywords (acceso de sólo lectura), Gestión de Keywords
• En Campos Personalizados: Ver Campos Personalizados (acceso de sólo lectura),Gestión de Campos Personalizados

Con esta configuración, los usuarios podrán realizar todas las tareas que necesiten, a excepción de las relacionadas con la Gestión de Usuarios.

Usuario Tester

Los usuarios pertenecientes a este grupo tendrán un rol denominado "Oficina Ejecución Testing - Tester" que constará de los siguientes permisos:

• En Test Plan: Ejecutar Test Plan
• En Gestión de Test Cases: Ver Test Cases (acceso de sólo lectura)
• En Keywords: Ver Keywords (acceso de sólo lectura)
• En Campos Personalizados: Ver Campos Personalizados (acceso de sólo lectura)

Con esta configuración, los usuarios únicamente podrán ejecutar los Tests asociados a un build.

Jefes de Proyecto

Los usuarios pertenecientes a este grupo tendrán un rol con una nomenclatura del tipo "PE - Empresa - Proyecto", que constará de los siguientes permisos:

• En Gestión de Test Cases: Ver Test Cases (acceso de sólo lectura), Crear/Editar Test Case.
• En Requerimientos:Ver Requerimientos (acceso de sólo lectura).
• En Keywords: Ver Keywords (acceso de sólo lectura).
• En Campos Personalizados: Ver Campos Personalizados (acceso de sólo lectura).

Por defecto, cuando se crea un rol, este tiene visibilidad sobre todos los proyectos, por lo que habrá que limitar la visibilidad del proveedor únicamente a la de su proyecto.