El proceso de aseguramiento de calidad está concebido como el conjunto de actividades y esfuerzos asociados para planear, organizar, dirigir y controlar la calidad del producto de software a lo largo de todo el ciclo de vida con el objetivo de satisfacer las necesidades y requerimientos del Usuario (cliente).

1. ASEGURAMIENTO
DE CALIDAD
Aseguramiento de Calidad de sitios Web
Metodologías de Prueba
Santiago - 2009

2. ASEGURAMIENTO DE CALIDAD
• El proceso de aseguramiento de calidad está
concebido como el conjunto de actividades y
esfuerzos asociados para planear, organizar,
dirigir y controlar la calidad del producto de
software a lo largo de todo el ciclo de vida con
el objetivo de satisfacer las necesidades y
requerimientos del Usuario (cliente).

3. Pruebas de Software
• Las pruebas del software corresponden a una de las disciplinas más
relevantes dentro de ciclo de vida del software dado que permitirá
establecer de forma objetiva si el producto de software construido cumple
con los atributos que el cliente requiere para satisfacer sus necesidades y
requerimientos. Inicialmente las pruebas son planificadas y organizadas
con el equipo de QA, Desarrolladores y el Cliente según el tipo de prueba
(se incluyen en plan de pruebas).
• El objetivo de las pruebas se cumple cuando éstas se realizan con función
de los casos de uso que darán origen a los respectivos casos de pruebas
que son debidamente revisados y acordados con el Cliente.

4. Modelos de Aseguramiento de Calidad
• El Modelo CMM, Madurez de la Capacidad El Capability Maturity Model, CMM2, o
Modelo de Madurez de la Capacidad del Software, definido en 1986 por el
Software Engineering Institute, SEI de la Carnegie Mellon University, despertó alto
interés en la industria de software debido a que las primeras instituciones que lo
adoptaron, como el Departamento de la Defensa de los Estados Unidos,
reportaron acerca de los múltiples beneficios proporcionados, tanto cualitativos
como cuantitativos.
• El Modelo TickIT: En 1991, el Consejo Nacional de Acreditación de los Organismos
de Certificación (National Accreditation Council of Certification Bodies, NACCB),
introdujo en el Reino Unido el programa TickIT como respuesta a las quejas
emitidas por las empresas dedicadas a la elaboración de software con respecto a
la calidad y consistencia de las evaluaciones para la certificación ante la norma ISO
9001; el objetivo del programa TickIT era ayudar a las organizaciones de software a
crear sistemas de calidad que agregaran valor a sus empresas y que cumplieran
con la norma ISO 9001.
• El modelo TPI: TPI (Test Process Improvement) está basado en las mejores
prácticas de la industria relativas a la mejora del proceso de pruebas. El modelo
incluye guías prácticas para evaluar el nivel de madurez de pruebas de una
organización así como los pasos para mejorar el proceso.

5. Metodologías de Prueba

6. Enfoque para el diseño de las Pruebas
• Recordando el objetivo de la pruebas, se diseñan pruebas que
tengan la mayor probabilidad de encontrar el mayor número
de no conformidades con la mínima cantidad de esfuerzo y
tiempo, para lo cual existen fundamentalmente dos enfoques,
que al combinarlos permite lograr mayor efectividad:
– - Pruebas de Caja Negra o Enfoque Funcional, hace referencia a
pruebas que se llevan a cabo a través de la interfaz gráfica del
software (GUI). O sea, pretenden demostrar que las funciones del
software son operativas, que la entrada se acepta de forma adecuada
y que se produce una salida correcta, así como que la integridad de la
información externa se mantiene.
– - Pruebas de Caja Blanca, son aquellas pruebas que se basan en los
caminos lógicos del software, la estructura interna y la
implementación del software en pruebas, proponiendo casos que
ejerciten conjuntos específicos de condiciones y/o ciclos.

7. En el proceso de desarrollo
• Definir la Plataforma de Pruebas
• Pruebas Unitarias
• Pruebas de Integración
• Pruebas de Aceptación de Usuario
• Pruebas de Seguridad (Solo perfiles de
usuario)
• Pruebas de Sistema
• Pruebas de Stress
• Pruebas de Instalación

8. Aseguramiento de Calidad
Desarrollo de Software Producción
Pruebas Funcionales
 Pruebas Unitarias
 Pruebas de Integración
 Pruebas de Seguridad
 Pruebas de Sistema
 Pruebas de Stress
 Pruebas de Instalación
QA
 Inspección de Código  Pruebas de aceptación de
Usuario

9. • Las pruebas de unidad están orientadas principalmente a
validar el cumplimiento de los estándares de presentación y
demás características visuales de la aplicación como la salida
de los reportes y el “look and feel”.
– Las pruebas de Integración se usan cuando el sistema ha sido
desarrollado por módulos o componentes y es necesario determinar
que éstos funcionan conjuntamente o “integrados”
• La pruebas del sistema incluye típicamente muchos subtipos
de prueba como: funcionalidad, usabilidad, seguridad,
internacionalización y localización, confiabilidad y
disponibilidad, capacidad, funcionamiento, recuperación y
portabilidad.
• Las pruebas de aceptación, son las que se hacen con los
clientes y define su aceptación del sistema.

10. Pruebas Unitarias
• Corresponden a las pruebas funcionales (caja negra)
realizadas en cada módulo por separado, las que
permiten medir resultados en función de datos de
entrada. Los criterios para confeccionar las pruebas
de unidad pueden ser:
• Valores de entradas normales
• Valores que provoque errores en el método
• Valores que son imposibles pero no provocan errores
• Valores que se encuentran en el límite entre los valores que
provocan error y los valores normales
• Valores que se encuentran en el límite entre los valores que
provocan error y los valores imposibles

11. Pruebas de Integración
• Finalizadas las pruebas unitarias se realizan las pruebas de
integración. Estas pruebas consisten en probar la interacción
entre distintos módulos que componen el sistema y cuyo
objetivo principal es detectar las fallas de interacción entre
los distintos módulos. Se utilizan dos técnicas para realizar
estas pruebas:
 Pruebas de integración ascendente: Estas pruebas validan que los
módulos inferiores se comuniquen con los módulos superiores.
 Pruebas de integración descendente: Estas pruebas validan que los
módulos superiores se comuniquen con los módulos inferiores.
Además se valida la funcionalidad que se ve influenciada por la
integración de los módulos.

12. Pruebas de Seguridad
• Estas pruebas permiten evaluar el nivel de seguridad
de acceso al sistema, por tratarse de sistemas
privados de Aduana se debe verificar el
cumplimiento de los requisitos de seguridad de
acceso especificados.
Las pruebas de seguridad se basan en casos de
pruebas que revisan lo siguiente:
– Autenticación al sistema
– Cambio de contraseña
– Accesos por perfil
– Visibilidad del menú por perfil
– Funcionalidad por perfil
– Perfil de Administración

13. Inspección de Código
• Para el control de código se realizarán una revisión
de pares con el objetivo de depurar el código. Estas
revisiones se basan en la generación de un checklist
para los siguientes casos:
– Revisión de sintaxis
– Código sucio (comentarios)
– Parámetros y enlaces en duro
– Errores en la referencia de datos
– Errores en la declaración de datos
– Revisión de Procedimientos almacenados

14. Pruebas de Sistema
• Permiten verificar que se han integrado
adecuadamente todos los elementos del sistema y
que realizan las funciones en forma apropiada. Las
pruebas de sistema incluyen las Pruebas de Stress.
Las pruebas de stress tienden a medir la
performance del sistema al momento de ser cargado,
mide tanto los requerimientos de software como los
de hardware. Finalizada las pruebas de stress se
confecciona un reporte que contiene los resultados
de las pruebas.

15. Pruebas de Stress
El objetivo principal de las pruebas de stress es medir el nivel máximo y
recomendado de concurrencia, junto con detectar los posibles errores que no
son posibles de detectar bajo una prueba monousuario.
Las pruebas de stress efectuadas por lo general obtienen lo siguiente:
 Establecer en forma adecuada el N° de usuarios y conexiones,
distribución de tráfico y malas prácticas que pudieran impactar la puesta
en producción de los nuevos servicios aplicativos.
 Determinar los niveles de servicio factibles de alcanzar y la escalabilidad
de la solución.
 Detección de posibles cuellos de botella en la infraestructura tecnológica
que soporta a las nuevas aplicaciones, y dejarlos en constancia como
riesgo de escalabilidad.
La prueba de stress finaliza con un informe de pruebas que indica los casos
probados, resultados y parámetros de pruebas. Por cada caso que lo amerite,
se asocia un conjunto con las medidas recomendadas a llevar a cabo para su
resolución. Las acciones correctivas de cada caso están sujetas a la
aprobación de cada una de las partes, por lo cual, la ejecución de las pruebas
de stress no garantiza que se resuelvan todos los problemas encontrados,
dados que pudiesen haber casos que escapan de la responsabilidad y alcance
del proyecto.

16. “Stressando” la Aplicación
QA
Métricas
 Memoria RAM
 IO
 Conexiones
 CPU
Nro. de Usuarios

17. Pruebas de Instalación
• Instaladores
• Creación de la base de datos
• Scripts (procedimientos almacenados, triggers, dts, etc)
• Configuración de sitios web
El objetivo de una prueba de instalación es revisar paso a
paso la instalación de la aplicación desde cero, verificando
que en el manual de instalación se encuentren explicados
todos los pasos necesarios para una instalación exitosa de
la aplicación, en estas pruebas se revisan:

18. Retroalimentación
• Después de ejecutar las iteraciones propuestas de
pruebas en el plan de pruebas y/o haber logrado el
criterio de cierre pactado, se llega a obtener la
calidad deseada en el producto de software.
 Idealmente, durante el proceso de pruebas se espera
poder exponer el sistema a todas las situaciones
posibles, así se encontraría hasta la última no
conformidad y con base en esto se podría cerrar el
proceso, sin embargo eso es imposible desde todos los
puntos de vista: humano, económico e incluso
matemático.
Criterio para determinar la liberación de producto

19. Conclusiones
• Emplear de forma sistemática y disciplinada
modelos, métodos y herramientas de
Ingeniería de software para el aseguramiento
de la calidad favorece no solo la comprensión,
análisis, sino que potencializa la mejora de la
calidad producida.

20. • Para considerar un software como un producto de alta calidad
se deben establecer normas mínimas a cumplir:
– Procedimientos en el desarrollo y en el control en cada fase del ciclo
de vida del producto.
– Estructura organizacional del proyecto.
– Tareas y responsabilidades especificas del personal encargado de
llevar a cabo las pruebas.
– Documentación a preparar para revisar la constancia del producto.
– Técnicas para llevar acabo auditoría y pruebas requeridas.
– Estándares, normas y especificaciones a usuario.
– Criterios de aceptación del producto.

21. Nomenclatura
• Casos de Uso: Es una secuencia de interacciones que se desarrollarán
entre un sistema y sus actores en respuesta a un evento que inicia un
actor principal sobre el propio sistema.
• Test Case: Este artefacto es la especificación de un conjunto de entradas
de prueba, condiciones de ejecución y resultados esperados, identificados
con el propósito de hacer una evaluación de algún aspecto particular de
un escenario.
• Producción: Poner a disposición y Utilización de la Aplicación a los
usuarios Finales, en el ambiente definitivo donde operará el Sistema.

22. 1. Estrategia de pruebas
2. Modelo del Ciclo de Vida
3. Estimación y Planeamiento
4. Técnicas de Diseño de Pruebas
5. Técnicas de Pruebas Estáticas
6. Métricas
7. Herramientas de Prueba
8. Entorno de Pruebas
9. Compromiso y Motivación
10. Funciones de Pruebas y capacitación
11. Comunicación
12. Informes
13. Manejo de Errores
14. Administración del Test Case (elementos de prueba)
15. Administración del Proceso de pruebas
16. Pruebas de Caja Blanca

23. María Paola Dávila
• @expolilla (Redes Sociales: Twitter, FB,,,
LastFm, Youtube, blip.fm, netvibes, jaiku… )
• expolilla@gmail.com
• http://cl.linkedin.com/in/expolilla