Project

General

Profile

Plan de aseguramiento de la calidad

Proyecto SuiteSET3
Descripción Plantilla para proyectos basada en ReadySET y Métrica 3.
Desarrollo SuiteSET3 (desarrollo) versión 2.0.x
Plazos vigentes FECHA INICIO - FECHA FINALIZACIÓN
Fecha edición 25/06/2022

Relacionados
Referencias
  • ENLACES A NORMAS RELEVANTES
  • ENLACES A OTROS DOCUMENTOS

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 if para 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

  • Cada método público
  • Cada método público en NOMBRECOMPONENTE
  • Todos los métodos públicos que modifican datos

Usaremos las instrucciones if al comienzo de los métodos públicos para validar el valor de cada argumento. Esto ayuda a documentar suposiciones y capturar valores no válidos antes de que puedan causar errores.

Aserciones

  • Cada metodo privado
  • Cada método privado en NOMBRECOMPONENTE
  • Todos los métodos privados que modifican datos

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

  • Advertencias estrictas del compilador
  • Comprobación de estilo automatizada
  • Validación de XML
  • Detección de errores comunes

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

  • Todos los cambios para liberar ramas.
  • Todos los cambios a NOMBRECOMPONENTE
  • Todos los cambios.

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

  • Semanal
  • Una vez antes del lanzamiento
  • Cada archivo fuente

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

  • 100% de los métodos públicos, y 75% de las declaraciones.
  • 100% de los métodos públicos.
  • 75% de las declaraciones

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

  • 100% de las pantallas y campos de la interfaz de usuario
  • 100% de los requisitos especificados

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

  • 100% de las pantallas y campos de la interfaz de usuario
  • 100% de los requisitos especificados

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
  • Ejecutar todas las pruebas de unidad antes de cada compromiso
  • Ejecutar todas las pruebas de la unidad todas las noches
  • Añadir nueva prueba de unidad al verificar arreglos

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

  • Pruebas de carga simples
  • Análisis detallado de cada parámetro de escalabilidad.

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

  • 4 clientes actuales
  • 40 miembros de nuestra red de desarrolladores
  • 1000 miembros del público

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

  • Monitorear nuestros servidores ASP
  • Monitorear remotamente los servidores de los clientes.

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

  • Preguntar a los usuarios para reportar fallas
  • Reportar fallas automáticamente

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

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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.