Plan de aseguramiento de la calidad¶
| Proyecto | SuiteSET3 |
| Descripción | Plantilla para proyectos basada en ReadySET y Métrica 3. |
| Desarrollo | project:suiteset3-dev versión suiteset3-dev:version#1 |
| Plazos vigentes | FECHA INICIO - FECHA FINALIZACIÓN |
| Fecha edición | 13/09/2024 |
| Relacionados | |
| Referencias |
|
- Table of contents
- Plan de aseguramiento de la calidad
Introducción¶
¿Por qué es necesario un plan de aseguramiento de la calidad?
"Calidad" se refiere a todas las cosas buenas que nos gustaría ver en nuestro producto. Construimos un producto teniendo en cuenta la calidad durante todo el proceso, realizando las actividades indicadas más adelante. Las pruebas son una actividad de aseguramiento de la calidad, pero no es la mejor ni la única, otras actividades de aseguramiento de la calidad incluyen el uso de guías de estilo y listas de verificación, reuniones de revisión, uso de herramientas de análisis y cuidadosas mediciones con indicadores y estimaciones de calidad. Es necesario un plan para seleccionar y coordinar todas las actividades de aseguramiento de la calidad.
¿Qué lecciones de aseguramiento de la calidad hemos aprendido de entregas anteriores?
- Ninguna. Esta es la primera entrega.
- Diferentes navegadores interpretan la misma página HTML de forma diferente, por lo que debemos probar cada versión en cada uno de los navegadores soportados.
- En anteriores entregas, los clientes encontraron que los signos de puntuación (por ejemplo, comillas y otros símbolos similares) fueron procesados adecuadamente, pero no fueron impresos de forma correcta. A partir de ahora hay que probar y validar la salida de caracteres especiales.
- Los bloques de datos muy grandes pueden algunas veces causar que el sistema falle si el espacio usado para datos temporales se agota. Los planes de pruebas deberán incluir más pruebas con grandes volúmenes de datos.
¿Cuál es el alcance de este plan de aseguramiento de la calidad?
Todos los componentes y aspectos del sistema se evaluarán en esta entrega.
Existen muchos objetivos de calidad y enfoques para lograrlos. Debido a que estamos limitados por el tiempo y los recursos asignados para esta entrega, nos concentraremos en los siguientes componentes y aspectos:
- COMPONENTE-1
- COMPONENTE-2
- COMPONENTE-3
- CARACTERISTICA-1
- FUNCIÓN-2
¿Cuál es el resumen de este plan?
En esta entrega continuaremos usando prácticas de desarrollo que respalden todos nuestros objetivos de calidad, pero nos concentraremos en la corrección y la robustez de las funcionalidades. Lo haremos con las siguientes actividades principales:
- usando sentencias
ifpara probar condiciones previas; - realizando revisiones frecuentes;
- realizando pruebas automatizadas de regresión unitarias con JUnit;
- llevando a cabo pruebas manuales estructuradas del sistema;
- manteniendo todos los problemas actualizados en una base de datos de seguimiento de problemas.
Objetivos de calidad para esta entrega¶
-
Esenciales
- Funcionalidad > Corrección
- Funcionalidad > Robustez
-
Esperados
- Funcionalidad > Precisión
- Funcionalidad > Compatibilidad
- Funcionalidad > Datos correctos
- Usabilidad > Comprensibilidad y legibilidad
- Usabilidad > Aprendizaje y retención
- Usabilidad > Soporte a tareas
- Usabilidad > Eficiencia
- Usabilidad > Seguridad
- Usabilidad > Consistencia y familiaridad
- Usabilidad > Satisfacción subjectiva
- Securidad
-
Deseados
- Confiabilidad > Consistencia bajo carga
- Confiabilidad > Consistencia bajo concurrencia
- Confiabilidad > Disponibilidad bajo carga
- Confiabilidad > Durabilidad
- Eficiencia
- Escalabilidad
- Escalabilidad > Rendimiento bajo carga
- Escalabilidad > Grandes volúmenes de datos
- Operabilidad
- Mantenibilidad > Comprensible
- Mantenibilidad > Extensible
- Mantenibilidad > Capacidad para ser probado
Estrategia de aseguramiento de la calidad¶
| Actividad | Cobertura o Frecuencia | Descripción |
|---|---|---|
|
Precondiciones |
|
Usaremos las instrucciones |
|
Aserciones |
|
Las aserciones se utilizarán para validar todos los argumentos a métodos privados. Dado que estos métodos solo se llaman desde otros métodos nuestros, los argumentos que se les pasen deben ser siempre válidos, a menos que nuestro código sea defectuoso. Las aserciones también se usarán para probar invariantes de clase y algunas postcondiciones. |
|
Análisis estático |
|
Usaremos herramientas de análisis de código fuente para detectar errores automáticamente. Los verificadores de estilo ayudarán a que todo nuestro código sea consistente con nuestros estándares de codificación. La validación de XML garantiza que cada documento se ajusta a su DTD. Otras herramientas pueden ayudar a detectar errores comunes de programación. Por ejemplo: lint, lclint / splint, jlint, checkstyle, Jcsc, PyLint, PyChecker, Tidy. |
|
Revisión por pares |
|
Cada vez que se realicen cambios en el código de una rama de lanzamiento (por ejemplo, para preparar un lanzamiento de mantenimiento), otro desarrollador revisará el cambio antes de que se confirme. El objetivo es asegurarse de que las correcciones no introduzcan nuevos defectos. |
|
Revisar reuniones |
|
Celebraremos reuniones de revisión donde los desarrolladores realizarán inspecciones formales de los códigos o documentos seleccionados. Elegimos dedicar una pequeña cantidad de tiempo predeterminada e intentar maximizar los resultados seleccionando cuidadosamente los documentos de revisión. En el proceso de revisión usaremos y mantendremos una variedad de listas de verificación. |
|
Examen de la unidad |
|
Desarrollaremos y mantendremos un conjunto de pruebas unitarias utilizando el marco JUnit. Consideraremos las condiciones de límite para cada argumento y probaremos ambos lados de cada límite. Las pruebas se deben ejecutar y aprobar antes de cada confirmación, y también serán ejecutadas por el equipo de pruebas. Cada método público tendrá al menos una prueba. Y, el conjunto de pruebas general ejercerá al menos el 75% de todas las declaraciones ejecutables en el sistema. |
|
Pruebas manuales del sistema |
|
El equipo de control de calidad creará y mantendrá un conjunto escrito detallado de pruebas manuales para probar todo el sistema a través de la interfaz de usuario. Este plan será lo suficientemente detallado para que una persona pueda realizar repetidamente las pruebas del documento de la suite de pruebas y otros documentos asociados. |
|
Pruebas automatizadas del sistema |
|
El equipo de control de calidad utilizará una herramienta de automatización de pruebas del sistema para crear y mantener un conjunto de scripts de prueba para probar todo el sistema a través de la interfaz del usuario. |
| Pruebas de regresión |
|
Adoptaremos una política de repetición frecuente de todas las pruebas automatizadas, incluidas aquellas que han tenido éxito anteriormente. Esto ayudará a capturar regresiones (errores que pensamos que estaban arreglados, pero que aparecen de nuevo). |
|
Pruebas de carga, estrés y capacidad |
|
Utilizamos una herramienta de prueba de carga y / o scripts personalizados para simular un uso intensivo del sistema. La carga se definirá mediante parámetros de escalabilidad, como el número de usuarios concurrentes, el número de transacciones por segundo o el número / tamaño de los elementos de datos almacenados / procesados. Verificaremos que el sistema pueda manejar cargas dentro de su capacidad sin fallar, producir resultados incorrectos, mezclar resultados para distintos usuarios o corromper los datos. Verificaremos que cuando se exceden los límites de capacidad, el sistema rechaza, ignora o desvía de forma segura las solicitudes que no puede manejar. |
|
Pruebas del Beta |
|
Involucraremos a personas externas en un programa de prueba beta o de acceso temprano. Le daremos instrucciones a los evaluadores beta para que se centren en las características específicas del sistema. Haremos un seguimiento activo con los evaluadores beta para alentarlos a reportar problemas. |
|
Instrumentación y monitoreo |
|
Como parte de nuestro SLA, supervisaremos el comportamiento de los servidores para detectar automáticamente las interrupciones del servicio o la degradación del rendimiento. Tenemos políticas y procedimientos implementados para notificación de fallas, escalado y corrección. |
|
Reportes de fallas de campo |
|
Queremos entender cada falla del sistema posterior a la implementación y tomar medidas para corregir el defecto. El sistema tiene capacidades incorporadas para recopilar información detallada de cada falla del sistema (por ejemplo, mensaje de error, rastreo de pila, versión del sistema operativo). Esta información nos será transmitida para que podamos analizarla y actuar en consecuencia. |
Evaluación de la estrategia de aseguramiento de la calidad¶
| Objetivo | Precondiciones | Aserciones | Revisión de compañeros | Juntas de evaluación | Pruebas por unidades | Pruebas la sistema | Aseguramiento general |
|---|---|---|---|---|---|---|---|
| Funcionalidad | Media | Media | Media | Alta | Alta | Alta | Fuerte |
| Consistencia | Alta | Alta | Alta | Alta | Alta | Media | Fuerte |
| Robustez | Alta | Alta | Media | Media | Alta | Media | Fuerte |
| Usabilidad | Ninguna | Ninguna | Ninguna | Alta | Ninguna | Media | Fuerte |
| Seguridad | Media | Ninguna | Media | Alta | Ninguna | Media | Fuerte |
| Confiabilidad | Ninguna | Media | Baja | Media | Media | Media | Débil |
| Eficiencia | Ninguna | Ninguna | Baja | Media | Ninguna | Baja | Arriesgada |
| Escalabilidad | Ninguna | Ninguna | Baja | Media | Baja | Baja | Arriesgada |
| Operabilidad | Ninguna | Ninguna | Ninguna | Baja | Ninguna | Baja | Arriesgada |
| Mantenibilidad | Media | Baja | Media | Alta | Baja | Ninguna | Débil |
Los valores en las celdas de la tabla anterior son estimaciones subjetivas de la efectividad de cada actividad. Esta tabla ayuda a identificar objetivos de calidad que no están siendo asegurados adecuadamente.
Valores de las celdas de evaluación:¶
- Alta: Esta actividad da un alto aseguramiento de que el objetivo se ha cumplido en desarrollo.
- Media: Esta actividad da un aseguramiento medio de que el el objetivo se ha cumplido en desarrollo.
- Baja: Esta actividad da solo un poco de aseguramiento de que el objetivo se ha cumplido en desarrollo.
- Ninguna: Este objetivo no resuelve el objetivo.
Valores aseguramiento general:¶
- Fuerte: El grupo de las actividades asegura que el objetivo se ha cumplido en desarrollo..
- Débil: TEl grupo de las actividades asegura de forma limitada que el objetivo se ha cumplido en desarrollo..
- Arriesgada: Existe poco o ningún aseguramiento de que este opbjetivo se ha cumplido.
Nota: Como regla general, se requieren al menos dos actividades "Altas" y una "Media" para dar una calificación general de "Fuerte". Del mismo modo, se requieren al menos dos actividades "Medias" y una "Baja" para poder dar una calificación general de "Débil".
Plan de acción¶
- Precondiciones y Aserciones
- Refine los documentos de requerimientos donde las preconditiones aún no están determinadas
- Cree funciones de validación para ser utilizadas por las preconditions y las aserciones según sea necesario
- Escriba preconditiones y asertiones en código
- Revisar reuniones
- Asigne reviones por compañeeros cada vez que se considere un cambio a una rama de la entrega
- Seleccione un documento riesgoso o una sección de código para las juntas semanales de revisión
- Cada semana identifique a los evaluadores y programe juntas de revisión
- Los evaluadores deberán estudiar el material de forma indivual por 2 horas
- Los evaluadores deberán reunirse para revisar el material por 2 horas
- Incluya notas de las juntas de revisión en el repositorio y dé seguimiento a a cualquier problemas identificado en las juntas de revisión
- Pruebas unitarias
- Diseñe una infraestructura para la fácil ejecución de pruebas de JUnit (este es solo un objetivo para Ant)
- Cree unidades de prueba para cada clase cuando la clase sea creada
- Ejecute pruebas para las unidades antes de incoroporarlas al repositorio. Todas las pruebas deben ser pasadas antes de que el desarrollador pueda incorporar algo al repositorio, o abra nuevos reportes para las pruebas falladas. Estas "pruebas de humo" serñan ejecutadas en el ambiente de desarrollo normal de cada desarrollador.
- Ejecute pruebas por unidades competas para cada candidato a entrega para detectar regresiones. Estas pruebas de regresiones serán ejecutadas en un equipo dedicado de QA.
- Actualice las pruebas para unidades cada vez que los requerimientos cambien
- Pruebas del sistema
- Diseñe y especifique un manual detallado del conjunto de pruebas.
- Revise el conjunto de pruebas al sisyema para asegurarse de que cada pantalla de la interfaz del usuario o elemento es cubierto
- Ejecute pruebas completas al sistema en cada cadidato a entrega. Estas pruebas al sistema serán ejecutadas en un equipo dedicado de QA.
- Actualice las pruebas al sistema cada vez que los requerimientos cambien
- Administración del aseguramiento de la calidad
- Actualice este plan de pruebas cada vez que los requerimientos cambien
- Docuemnte los resultados de las pruebas y comuníquelos a equipo de de desarrollo completo
- Estime los defectos remanentes (aún no detectados) bañandose en los datos actuales de control de cambios, tasas de error, y métricas en el tamaño del código y el impacto de los cambios.
- Mantenga todos los reportes de errores actu alizados en una base de datos de control de cambios. El sistema de control de cambios está disponible para todos los miembros del proyecto aquí. El significado de estados de un problema, prioridades y otros atributos están definidos en el SDM.
Lista de verificación del plan de aseguramiento de la calidad¶
¿Las actividades seleccionadas en la estrategia de aseguramiento de la calidad brindan suficiente seguridad de que el proyecto cumplirá con sus objetivos de calidad?
Sí, si todas las actividades se llevan a cabo según lo planeado, estamos seguros de que se cumplirán los objetivos de calidad. Por supuesto, ajustaremos este plan según sea necesario.
No, este plan deja abiertos varios riesgos de calidad que han sido indicados en la gestión de riesgos del plan de proyecto.
¿Se han asignado recursos humanos para llevar a cabo las actividades de aseguramiento de la calidad?
Sí, se han asignado recursos humanos. Se encuentran en el documento de recursos necesarios.
No, no se han asignado recursos humanos. Se enumeran como "Pendientes" en el documento de recursos necesarios.
¿Se han asignado recursos de equipamiento y software según sea necesario para las actividades de aseguramiento de la calidad?
Sí, el equipo de aseguramiento de la calidad usará puestos de escritorio y servidores que ya se encuentran asignados a ellos.
Sí, se ha montado un laboratorio para aseguramiento de la calidad. Los recursos necesarios de equipamiento y software se enumeran en el documento de recursos necesarios.
No, las necesidades de equipamiento y software se enumeran como "Pendientes" en el docuemento de recursos necesarios.
¿Se ha comunicado este plan de aseguramiento de la calidad al equipo de desarrollo y a otras partes interesadas?
Sí, todo el equpo conoce la prioridad de nuestros objetivos de calidad para esta entrega y entienden cómo su trabajo ayudará a alcanzar estos objetivos. Todas las sugerencias son bienvenidas.
Sí, este documento está publicado en la página del proyecto. Todas las sugerencias son bienvenidas.
No, algunos desarrolladores aún no conocen los objetivos de calidad y las actividades de aseguramiento de la calidad planificadas para esta entrega. Este es un riesgo que se señala en la gestión de riesgos del plan de proyecto.