Plan de testing de software

Contenido del documento

Convenciones del documento

En el presente Documento se utilizan convenciones estándar de texto, con el objetivo de facilitar su comprensión y uso. En esta Sección se procede a detallar las instrucciones necesarias para que el usuario del documento sustituya la información genérica provista en esta plantilla con la información de su propio proyecto. El usuario del documento deberá evaluar la información genérica suministrada en este plan de Gestión de la Configuración y ajustarla a las necesidades de su proyecto.

[[texto]] Cambios globales: Los textos que aparecen en modo regular, y encerrados con dobles corchetes [[]], representan cambios que pueden realizarse de manera global (Por ej. en [[Modifique en “Asunto” el nombre del Proyecto]] el usuario podrá modificar la propiedad indicada (Archivo→Propiedades→Descripción) en el procesador de texto, lo que le permitirá hacer un cambio a todas las ocurrencias del proyecto.

\ Guías de uso: El texto que aparece encerrado entre los símbolos \ representa instrucciones o guías de ayuda al usuario del documento. Este texto sólo será visible e impreso en formato Markdown. De todas maneras, si lo considera necesario, puede borrar estas instrucciones.

Introducción

Las pruebas son el único instrumento que puede determinar la calidad de un producto software, es decir, es el único método por el que se puede asegurar que un sistema software cumple con los requerimientos.

El presente plan describe las actividades vinculadas con Testing Estático y Dinámico del Software del producto MoSimPa, con el objetivo de verificar y validar los componentes basados en software. En él se describen los requerimientos y componentes a ser probados, los roles y responsabilidades relacionados con el proceso, las actividades, los tipos de pruebas a ejecutar, la administración de los artefactos generados, los circuitos y sus entornos, el cronograma de tareas de testing dentro del proyecto y la forma de mantener trazabilidad entre los resultados de componentes/elementos testeados, los requerimientos y riesgos asociados.

1.1. Organización del documento

A continuación se describirá brevemente cada una de las secciones que componen el presente Documento. Se sugiere al lector una lectura secuencial, siguiendo el orden propuesto.

Sección 1: Introduce al lector al contenido del Plan.

Sección 2: Describe los objetivos del Plan.

Sección 3: Identifica los documentos relacionados con el Plan.

Sección 4: Identifica los lectores a los cuales está dirigido el Plan.

Sección 5: Identifica los roles y responsabilidades relacionados con el proceso de Testing.

Sección 6: Describe las actividades del proceso de Testing.

Sección 7: Describe los requerimientos especificados que serán puestos bajo proceso de Testing.

Sección 8: Describe los tipos de Testing que serán llevados a cabo.

Sección 9: Menciona y describe las herramientas utilizadas en las actividades de Testing.

Sección 10: Describe los procesos de identificación de la configuración de Testing.

Sección 11: Describe los procesos para el control de la configuración de artefactos de Testing.

Sección 12: Describe las características del entorno de Testing.

Sección 13: Describe cómo se garantiza la trazabilidad de las pruebas del proceso de Testing.

Sección 14: Describe los indicadores usados en el proceso de Testing y cómo se generan los reportes de estado de las pruebas.

Sección 15: Contiene el cronograma de las actividades de Testing.

Sección 16: Contiene los apéndices del Plan, incluyendo un glosario de términos y definiciones empleados en el presente documento, además de una subsección de historial de cambios.

2. Objetivos del documento

El propósito de este documento es detallar las actividades relacionadas al proceso de testing (estáticas y dinámicas) a ejecutarse sobre el software del producto MoSimPa, indicando el proceso a seguir, las estrategias de testeo a utilizar, el soporte herramental y los indicadores utilizados para medir la calidad del producto.

3. Documentos relacionados

A continuación se indican los documentos relacionados con el presente:

4. Destinatarios del plan

A continuación se procede a listar a los destinatarios de este documento, quienes forman parte del registro de stakeholders del Proyecto MoSimPa.

Lector/Actor Rol
MANDOLESI, Pablo Líder de Proyecto / Ingeniero de D&D de Hardware
PÉREZ MEYER, Lisandro Ingeniero de D&D de Software / Líder de Testing / Integrador
AYMONINO, Andrés Ingeniero de D&D de Hardware
POUSO, Marcelo Ingeniero de D&D de Software
CASANOVA, Alejandro Ingeniero de D&D de Software
VALLASCIANI, Luis Guillermo Ingeniero de D&D de Hardware
COPPA, Guillermo Ingeniero de D&D de Hardware
ROSSI, Esteban Líder Consultor de Procesos – RRHH externo
ALBORNOZ LAFERRARA, Josué Ingeniero Consultor de Procesos Sr. – RRHH externo
GRAMAJO, Rodrigo Ingeniero Consultor de Procesos Jr. – RRHH externo
CARDOSO, Paula Ingeniera Consultora de Procesos Jr.– RRHH externo

5. Organización

5.1. Roles y responsabilidades

La siguiente tabla lista todos los miembros del Proyecto responsables de las actividades de testing para el software del producto MoSimPa.

Rol Recurso Responsabilidad Reemplazo de recurso
Líder de Testing PÉREZ MEYER, Lisandro

  • Confeccionar y mantener actualizado el plan de testing.

  • Diseñar casos de prueba.

  • Ejecutar las pruebas.

  • Registrar los resultados de las mismas.

 TBD
Desarrollador PÉREZ MEYER, Lisandro

  • Desarrollar el software y control del producto.

  • Corregir defectos al software identificados durante la actividad de testing.

 TBD
Integrador PÉREZ MEYER, Lisandro

  • Planificar e implementar la integración del sistema software.

 TBD

6. Proceso de testing

A continuación se dispone de un diagrama que refleja cada una de las actividades que componen el proceso de testing sobre los requerimientos del producto MoSimPa alcanzados. Se establecen además las relaciones entre estas actividades y los roles responsables en su ejecución.

Diagrama de actividades de testing

Seguidamente, se procede a describir cada una de las actividades antes definidas:

  • Planificar Testing: El Líder de Testing planifica las > actividades de prueba sobre el software que constituye el producto > MoSimPa, teniendo en cuenta el modelo de ciclo de vida del > Proyecto y la WBS establecidos en el Plan de Gestión de Proyecto. > La planificación incluye el armado del Plan de Testing, la > actualización de las actividades en la herramienta de gestión de > proyectos (GitLab), la priorización en el diseño de los casos de > pruebas para las estrategias de testing a probar (funcional y no > funcional sumada a las estrategias de regresión, test de > integración/sistema y de aceptación), la planificación del > intercambio de los artefactos de testing para coordinar las > actividades de diseño y ejecución, frecuencia de reportes e > indicadoras a obtener, cronograma de la prueba.

  • Generar Paquete y Ejecutar Testing Unitario: Una vez concluidas > las actividades de especificación y desarrollo de requerimientos, > según cronograma preestablecido, o al corregirse defectos de > ciclos anteriores de pruebas, el Integrador de Software genera el > paquete correspondiente con lo que el Líder de Testing ejecuta > testing unitario en el entorno de prueba.

  • Diseñar Casos de Prueba: El Líder de Testing diseña los casos de > prueba del software (tanto funcionales, como no funcionales y de > regresión). Se basa en el modelo de casos de uso y demás > requerimientos definidos en el Documento de Especificación de > Requerimientos. Cada caso de prueba funcional está asociado a uno > o más casos de uso. Estos, a su vez, especifican primordialmente > los cambios o nuevas características del software. Los casos de > prueba no funcionales se diseñan a partir de lo relevado en las > reuniones con el equipo de Proyecto MoSimPa.

  • Ejecutar Test Funcional/No Funcional: El Líder de Testing > ejecuta los casos de prueba diseñados, siguiendo el cronograma de > testing. Por cada caso de prueba ejecutado se registra su > resultado. Para aquellos casos en los que se identifican defectos, > los mismos son registrados en la herramienta correspondiente y > asociados al caso de prueba en el que se detectó.

  • Ejecutar Test de Regresión: Cada vez que el Líder de Testing > finaliza la ejecución de un ciclo de pruebas (funcional o no > funcional) selecciona y ejecuta un subconjunto de casos de prueba > adicionales, los cuales también vuelve a ejecutar. Estos casos > tienen dos particularidades: 1- Son casos de prueba que no tenían > defectos asociados; 2- Son casos de prueba de funcionalidad > emparentada con los defectos. El Líder de Testing busca comprobar > que no se han inyectado nuevos defectos al corregir otros. Por > cada caso de prueba ejecutado se registra su resultado. Para > aquellos casos en los que se identifican defectos, los mismos son > registrados en la herramienta correspondiente y asociados al caso > de prueba en el que se detectó.

  • Corregir Defectos: El Desarrollador recibe los defectos que se > van identificando a lo largo de las pruebas.

  • Ejecutar Test de Integración/Sistema: El Líder de Testing > ejecuta los casos de prueba para verificación de la > integración/sistema del software. Por cada caso de prueba > ejecutado se registra su resultado. Para aquellos casos en los que > se identifican defectos, los mismos son registrados en la > herramienta correspondiente y asociados al caso de prueba en el > que se detectó.

  • Ejecutar Test de Aceptación: El Líder de Testing y la persona > designada por el equipo de Proyecto MoSimPa, para dar conformidad > al software del producto MoSimPa, seleccionan los casos de pruebas > a ser ejecutados para la aceptación.

  • Monitorear e Informar Estado: el Líder de Testing monitorea el > avance de las pruebas (diseño y ejecución) en relación al > cronograma establecido. Periódicamente, obtiene las mediciones > sobre las ejecuciones realizadas y en curso. Finalmente elabora > informe de estado para realizar un análisis conjunto con el equipo > del proyecto MoSimPa.

7. Requerimientos de alcance de testing

Los requerimientos alcanzados por el proceso de testing se encuentran listados en el Documento de Especificación de Requerimientos, cuyo link es: Especificación de requerimientos.

8. Tipos de testing

Los tipos de pruebas que serán ejecutadas serán: Test Funcional, Test No Funcional, Test de Regresión, Test de Integración/Sistema y Test de Aceptación.

8.1. Test funcional

Describir...

8.2. Test no funcional

Describir...

8.3. Test de regresión

Describir...

8.4. Test de integración/sistema

Describir...

8.5. Test de aceptación

Describir...

9. Herramientas de uso en las actividades de testing

Como parte del proceso de testing sobre el software del producto MoSimPa se utilizarán las herramientas que se detallan a continuación:

  • Planilla de Casos de Prueba e issue tipo Testing que relaciona > casos de prueba con sus vínculos a los script de las pruebas a > ejecutar: Para registrar los casos de prueba con sus respectivos > escenarios, evidenciar las ejecuciones de dichos casos, los > resultados y la obtención de reportes.

  • GitLab: Para registrar y gestionar las actividades de testing, > los casos de pruebas, como así también los defectos y anomalías > identificados en las pruebas.

  • GIT: Para administrar los ítems de configuración > correspondientes a los artefactos de testing.

10. Identificación de la configuración de testing

Los ítems de configuración que serán puestos bajo proceso de Testing, su nomenclatura y lugar de almacenamiento constan en el Plan de Gestión de la Configuración General del Proyecto MoSimPa.

11. Control de la configuración de artefactos de testing

Los flujos de trabajo correspondientes a los issues abarcados por las actividades de testing se encuentran plasmados en la Sección 8.1 del Plan de Gestión de la Configuración General del Proyecto MoSimPa, y siguen la definición establecida allí. Estos workflows serán gestionados a través de la herramienta GitLab. Cada diagrama describe los diferentes estados para los diferentes tipos de cambios.

12. Entorno de testing

Describir...

…

13. Trazabilidad de las pruebas

La trazabilidad entre los requerimientos, los casos de prueba y los defectos asociados serán evidenciados como se detalla a continuación:

  1. Los requerimientos de usuario que constan en el modelo de desarrollo > en Enterprise Architect (EA) son cargados en GitLab. La > trazabilidad se mantiene a través del ID del EA y GitLab.

  2. La especificación de requerimientos, fundamentalmente funcionales, > es cubierta por el modelo de Casos de Uso (CUs) y trazados a los > requerimientos correspondientes (requerimientos de usuario, no > funcionales, requerimientos de negocio, etc.).

  3. Por cada CU existirán casos de prueba asociados, que a su vez > constarán de escenarios de prueba. Tanto los casos de prueba como > sus escenarios serán diseñados y documentados en el EA, y trazados > a los CUs.

  4. La evidencia del diseño y ejecución de los casos de prueba constará > en GitLab a través del issue de tipo Testing.

  5. Todo defecto (Bug) que surgiera como consecuencia de la ejecución > de las pruebas será dado de alta en el EA, exportado a GitLab y > relacionado como petición hija de acuerdo al workflows > especificado en apartado 8.1 del Plan de Gestión de la > Configuración General del Proyecto MoSimPa.

  6. El registro de resultados de los test será efectuado en el EA para > posteriormente generar un reporte de testing, el cual se exportará > desde el EA y vinculará al issue testing, de acuerdo a > planificación.

14. Indicadores de testing y reporte de estados

Para cada ciclo de ejecución de pruebas, se generará un informe de testing que permitirá reportar los estados de las pruebas ejecutadas, y que contendrá información referida a los casos de prueba, condiciones de entradas, requerimientos asociados, escenario probado, tipo de test realizado, responsable de la ejecución del test, ciclo de testing correspondiente, fecha de realización de la prueba, resultados (esperados y obtenidos), estado de Pasa/Falla o Bloqueado, observaciones y defectos asociados, si los hubiere. Dicho informe se vinculará al issue de tipo Testing que guiará las ejecuciones de las pruebas.

Cada informe contendrá además las métricas que permitirán evaluar los hallazgos y la evaluación final de esos resultados.

14.1. Hitos de informes

Hito de reportes Descripción Link

1.

2.

3.

14.2. Criterios de aceptación para la verificación de los entregables

A continuación se procederá a establecer los niveles de aceptación para los entregables verificados:

  • No Aprobado: el elemento verificado tiene errores catastróficos > (uno o varios) que impiden su uso, o tiene errores críticos (uno o > varios) que hacen que el elemento verificado no sea confiable. El > usuario no puede depender de él para realizar el trabajo.

  • Crítico: un error cuya presencia causa la pérdida de una > funcionalidad crítica del sistema. Si no se corrige, el sistema no > satisfará las necesidades del cliente.

  • Aprobado con Observaciones: el elemento verificado no tiene > errores catastróficos, ni errores críticos, pero tiene errores > marginales (uno o varios) que hacen que el elemento de software se > degrade en algunas situaciones.

  • Aprobado: el elemento verificado no tiene errores o tiene errores > menores, que no afectan el normal funcionamiento del elemento.

15. Cronograma de actividades de testing

El cronograma de actividades de testing seguirá lo especificado en el diagrama de Gantt que fue diseñado y plasmado en el Plan de Gestión de Proyecto.

16. Apéndices

16.1. Glosario y definiciones

Ver Glosario de Términos y Definiciones.

16.2. Historial de cambios

El historial de los cambios puede consultarse en la historia de las revisiones del Proyecto MoSimPa, o bien mediante la identificación de las versiones taggeadas según el sistema de control de versionado empleado. La descripción de los cambios estará especificada en los comentarios del commit correspondiente.