Aseguramiento De Calidad Mp

1,296 views

Published on

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 Comment
0 Likes
Statistics
Notes
  • Breve resumen ... Preparado para explicar metodología a Usuarios no Espescialistas
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
1,296
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
17
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Aseguramiento De Calidad Mp

  1. 1. ASEGURAMIENTO DE CALIDAD Aseguramiento de Calidad de sitios Web Metodologías de Prueba Santiago - 2009
  2. 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. 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. 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. 5. Metodologías de Prueba
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Pruebas de StressEl 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. 16. “Stressando” la Aplicación Stressador Servidores Aduana Simuladores de Usuarios QA Métricas  Memoria RAM  IO  Conexiones  CPU Nro. de Usuarios
  17. 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. 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. 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. 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. 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. 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. 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

×