Está en la página 1de 1

Metodos y Herramientas del SQA 6) Revisiones por Pares (Peer Reviews).

Son actividades efectivas para el


control de la calidad. Pueden aplicarse al análisis, diseño y codificación.
son metodos y herramientas q se utilizan para asegurar la buena
calidad del software ya que sin ellos no podria ser de buena calidad y 7) Revisión Técnica formal (RTF): Es una actividad de garantía de calidad de
son: auditoria, pruebas de validacion, comparacion de daros, pruebas SW. Es una revisión que incluye recorridos, inspecciones y revisiones
de esfuerzo, pruebas de uso, revisiones por pares, revision tecnica cíclicas. REVISIONES POR PARES (PEER REVIEWS) Consiste en la
formal. revisión del código de un programador por otros programadores (sus pares).
Se puede poner en práctica creando un panel que encarga de revisar
METODOLOGÍA SQA Las pruebas de SW son tanto un arte como una periódicamente muestras de código. En la revisión por pares se analizan o
ciencia en general, en aplicaciones complejas, como los sistemas operativos, revisan factores técnicos, de procedimiento y humanos. Las revisiones por
es prácticamente imposible eliminar todos los errores antes de liberar la pares son las siguientes: Walkthroughs (recorridos) Revisiones Inspecciones
versión, esto se debe a los diferentes puntos de vista y a las limitaciones de de código
tiempo.
Diferentes aplicaciones de SW requieren distintos enfoques en lo que Walkthroughs Objetivos: Detectar posibles defectos. Identificar
respecta a las pruebas. oportunidades de mejora. Examinar alternativas.

Los métodos más comunes para el aseguramiento de la calidad son los El walkthrough es usado para revisar especificaciones de requerimientos o de
siguientes: diseño. Procedimientos: A partir del código regular, el walkthrough es
realizado al menos una vez por cada bucle a través del modelo espiral y se
1) Auditorías PPQA (Process and Product Quality Assurance) Es la actividad realizará en forma circular (programador i-th revisará el código del
de garantizar que el proceso y el producto de trabajo se ajustan al plan programador 1-th+1). Todas las deficiencias serán anotadas y utilizadas para
acordado. el mejoramiento del proceso.

2) Pruebas de Validación: Es el acto de introducir datos, los cuales el tester Durante cada código revisado en el walkthrough se tomarán dos mediciones:
sabe que son erróneos en la aplicación. relativas y objetivas. Las deficiencias relativas son: código eficiente (pocos
recursos son consumidos) y código exacto (que tan cerca está el producto con
3) Comparación de datos: Técnica que se realiza comparando los resultados las especificaciones). Las deficiencias objetivas son: errores de formato,
de una aplicación con parámetros específicos con los resultados de otra nombre de variables no estandarizado, falta de documentación (comentarios
aplicación previamente creada, introduciendo los mismos parámetros de en el código) y falta de normas de codificación.
manera que se obtenga un resultado exacto.
INSPECCIONES DE CÓDIGO No son excluyentes con el testing. Cada
4) Prueba de esfuerzo (Stress Testing) Se realiza cuando el SW es utilizado desarrollador puede encontrar distintos tipos de defectos. No hay tiempo ni
de la manera más “ruda” posible en un período de tiempo para ver si trabaja dinero para inspeccionar todo. Se suele centrar la inspección en los módulos
con altos niveles de carga. más críticos. Es recomendable realizarla después de una prueba básica.

5) Pruebas de Uso: A veces conseguir usuarios que no estén familiarizados Objetivos primarios: Detectar defectos. Elegir el camino de resolución.
con el SW para probarlo por un tiempo determinado, ofrece Verificar la resolución (Los defectos deben ser corregidos).
retroalimentación a los desarrolladores acerca de las dificultades que
encontraron. Esta es la mejor maneta de realizar mejoras a la interfaz. Objetivos secundarios: Asegurar consenso sobre el trabajo y la calidad.
Potenciar el trabajo en equipo. Obtener datos para las métricas.