PPT11 Porque es necesario el Testing?

Bsicamente porque las personas no son perfectas, las personas cometen errores porque son falibles, y los sistemas estn hechos por personas. Puntualmente en los sistemas de software la presin de las fechas de entrega, la complejidad de los sistemas y las organizaciones, las cambiantes tecnologas, entre otros factores, aumentan la presin sobre los dise adores incrementando las probabilidades de cometer un error en las especificaciones, en el dise o y en la codificacin. !e ah es donde "ienen la mayora de los errores. #i una especificacin de dise o de un componente contiene alg$n error, ese error se migrara tambi%n al componente construido y probablemente no se comportar seg$n lo esperado. #i este componente se integra a un sistema, este sistema puede fallar. &s "emos como un error en el dise o puede lle"ar a componentes defectuosos y estos componentes defectuosos a sistemas defectuosos. '(isten otras razones por las cual un sistema puede fallar, algo que se presenta muy a menudo son los problemas de ambiente. 's necesario entonces testear un producto para asegurarnos que cumple con lo esperado, si un sistema que ya est en manos del cliente y falla es porque no se testeo lo suficiente o se testeo mal, o ambas razones.

PPT21 Que es el Testing?

)ntuiti"amente las personas que estamos en el tema sabemos que es una acti"idad para reducir el riesgo y mejorar la calidad mediante la b$squeda de defectos. Podemos decir que el *esting es la e(ploracin sistemtica de un componente o sistema con el principal objeti"o de encontrar defectos. 's importante dejar en claro que el testing no incluye la correccin de defectos, los defectos encontrados son asignados a los desarrolladores para su correccin. *esting tambi%n comprueba el correcto funcionamiento de los cambios y correcciones aplicadas y su efecto en otros componentes o sistemas. 'n la prctica testing realiza una rigurosa e(animacin del comportamiento de un componente o sistema y reporta todos los defectos encontrados.

+uego, testing tambi%n repite los testeos necesarios para asegurar que las correcciones fueron efecti"as.

PPT50

#urgimiento de #,&
'n los a os -., el software comenz a encontrar su camino dentro de los sistemas del !o! /del ingl%s !eparment of !efense of 0#&1. 0sualmente estos proyectos estaban muy alejados de la planificacin, se pasaban del presupuesto y tenan muchos problemas t%cnicos. 2recuentemente no funcionaban como se esperaba y muchos proyectos eran cancelados antes de ser entregados. !urante este periodo los contratistas para el desarrollo de software a menudo hacan estimaciones muy optimistas sobre el estado del desarrollo del software. 'l !o! normalmente no era notificado de los problemas en la planificacin, en la gestin del presupuesto y de problemas t%cnicos hasta muy a"anzado el proyecto, cuando ya no eran capaces de entender los problemas ni de e"aluar el impacto de %stos. Para intentar resol"er este problema se estableci la 3erificacin y 3alidacin )ndependientes/)343 del ingl%s )ndependent 3erification and 3alidation1, un proceso de ingeniera que empleaba metodologas rigurosas para e"aluar la correctitud y calidad del software a lo largo de su ciclo de "ida. 'l primer software en usar )343 fue el programa del misil atlas a finales de los a os -.. !esde el proyecto atlas se ha recolectado mucha informacin que indica que los proyectos con )343 se realizan o ejecutan mucho mejor que los proyectos sin )343. 5on el tiempo el rol del )343 se con"irti critico. +a acti"idad que llamamos #,& e"oluciona directamente de la 3erificacin y 3alidacin )ndependientes/)3431, muchas de las tareas que asociamos con #,& son originarias de )343. +uego durante los a os 6. la acti"idad de desarrollo de software comenz a e(pandirse y las compa as de desarrollo de software fueron e(perimentando los mismos pobres resultados que las agencias

gubernamentales/!o!, 7&#& etc.1 en las d%cadas tempranas. +as compa as tenan dificultad para entregar el software dentro de los plazos, presupuesto y calidad planificados. 3arios proyectos desarrollados entre 89:. y 899. fueron desastrosos, muchos e(cedan ampliamente el presupuesto y la planificacin o entregaban software de baja calidad que no se poda usar. !urante los :. esta e(periencia se con"irti en lo que conocemos como crisis del software, el tiempo consumido en el mantenimiento e(ceda el tiempo insumido en la construccin de nue"os productos de software. +uego de la crisis del #oftware en los a os :., #,& e"oluciono hacia una herramienta que las compa as de desarrollo de software utilizaban para identificar de forma temprana los problemas de calidad en el proceso de desarrollo. ;ientras #,& era "isto como un peque o paso dentro del proceso del desarrollo del software, muchos jefes de proyectos "ieron beneficios cuantificables a partir de integrar #,& dentro del proceso de desarrollo de software. 'n los 9. "arias compa as de software ya tenan funciones de #,& dentro de sus organizaciones.

PPT51
Definicin de SQA (Software Quality Assurance) &l igual que ocurri con la definicin de calidad hay "arios puntos de "ista desde donde se puede definir el aseguramiento de la calidad del software. !esde el punto de "ista de la e"idencia, la )''' define el aseguramiento de la calidad como <0na gua planificada y sistemtica de todas las acciones necesarias para pro"eer la e"idencia adecuada de que un producto cumple los requerimientos t%cnicos establecidos. 0n conjunto de acti"idades dise adas para e"aluar el proceso por el cual un producto es desarrollado o construido.= >?@

!aniel Aalin define #,& como <0n conjunto, sistemtico y planificado, de acciones necesarias para pro"eer la e"idencia adecuada de que el proceso de desarrollo o mantenimiento de un sistema de software cumple los requerimientos t%cnicos funcionales tan bien como los requerimientos gerenciales para cumplir la planificacin y operar dentro del presupuesto confinado= >6@.

!esde el punto de "ista de la "isibilidad, el #') define #,& como <'l aseguramiento de la calidad del software pro"ee claro control del proceso que est siendo usado por el proyecto y del producto que se est construyendo.=>:@

!esde el punto de "ista del aseguramiento, !on Beifer define #,& como <'l aseguramiento de la calidad del software es el sistema de m%todos y procedimientos usados para asegurar que el producto de software alcanza sus requerimientos. 'l sistema in"olucra la planificacin, estimacin y monitoreo de las acti"idades de desarrollo realizadas por otros.=>9@

!esde el punto de "ista de la capacidad de uso #chulmeyer y ;c;anus definen #,& como <+as acti"idades sistemticas que pro"een e"idencia de la capacidad o disponibilidad de uso del producto de software total.=>8.@

Para certificar madurez de procesos, hay que e"idenciar que uno aplica un cierto proceso y para esto se deben registrar las distintas acti"idades de tal proceso de desarrollo, como %ste es el objeti"o que persigue el software a desarrollar como parte de esta tesis, elegiremos la definicin que da la )''' desde el punto de "ista de la generacin de e"idencia adecuada que muestre que se cumple con el proceso que se dice seguir y con los requerimientos establecidos.

PPT56 #,& no es lo mismo que #,5 /#oftware ,uality 5ontrol1

Aeneralmente cuando le preguntamos a un profesional de sistemas que es lo que entiende por aseguramiento de la calidad del software, inmediatamente comienza a hablar de testing, algunos de ellos incluyen a la "alidacin y "erificacin y luego empiezan a hablar de re"isiones, las cuales son slo e(tensiones del testing. 's decir, a menudo hay una confusin entre #,& y el testing /el cual actualmente forma parte del rea de control de calidad del software #,51. Caciendo slo testing y re"isiones no aseguramos la calidad de los productos, sino aseguramos el cumplimiento de especificaciones tanto funcionales como t%cnicas. 'n el desarrollo de software la diferencia entre #,5 y #,& no esta clara y estos t%rminos a menudo se confunden, #,& se encarga de controlar el cumplimiento del proceso, mientras que #,5 son aquellas acciones del aseguramiento de la calidad que proporcionan un medio para controlar y medir las caractersticas de un elemento, proceso o facilidad respecto a los requisitos establecidos. D +a siguiente tabla e(pone sint%ticamente las diferencias entre control de calidad y aseguramiento de la calidad. 5ontrol de calidad !etecta problemas en los productos de trabajo. &seguramiento de la calidad &segura la adherencia a los procesos, estndares y planes. '"al$a que los procesos, planes y estndares utilizados en el proyecto cumplan con los estndares organizacionales. Be"isa procesos

3erifica que los productos de trabajo cumplan con los estndares de calidad especificados en el plan de proyecto.

Be"isa el contenido del producto *abla 6E5ontrol de calidad "s. &seguramiento de la calidad

'n conclusin, el rol del #,& es auditar que los distintos equipos de la organizacin, inclusi"e el de #,5 siguen los procedimientos, estndares y procesos establecidos. 'l equipo de #,& debera establecer m%tricas para medir la efecti"idad del proceso. 5omo complemento el rol de #,5 es tomar una actitud acti"a de "erificacin y "alidacin del resultado o salida del proceso implementado.

PPT58
Funciones generales del SQA
!escribir los diferentes roles que puede jugar el equipo de #,& en una organizacin nos dar una "isin clara de las funciones que puede lle"ar a cabo. <5omo polica del proceso=E el trabajo del equipo de #,& es asegurar que el desarrollo sigue el proceso establecido. 'ntre sus funciones en este rol se encuentranE o &uditar los productos del trabajo para identificar deficiencias.o !eterminar el cumplimiento del plan de desarrollo del proyecto y del proceso de desarrollo de software. o Fuzgar el proceso y no el producto. <5omo abogado del cliente=E el trabajo del equipo de #,& es representar al cliente. 'ntre sus funciones en este rol se encuentranE o )dentificar la funcionalidad que al cliente le gustara encontrar.o &yudar a la organizacin a sensibilizarse con las necesidades del cliente. o &ctuar como un cliente de prueba para obtener una alta satisfaccin del cliente.

<5omo analista= el trabajo del equipo de #,& es recabar informacin. 'ntre sus funciones en este rol se encuentranE o Funtar muchos datos sobre todos los aspectos del producto y del proceso. o 5on esta informacin ayudar a mejorar los procesos y los productos. <5omo pro"eedor de informacin= el trabajo del equipo de #,& es re"isar qu% es lo que est% hecho y decir cules objeti"os t%cnicos realmente estn cumplidos para que la gerencia pueda tomar mejores decisiones de negocios. 'ntre sus funciones en este rol se encuentranE o Pro"eer informacin t%cnica objeti"a para que la gerencia pueda usarla para tomar mejores decisiones. o Pro"eer informacin apropiada de las clases de productos y de los riesgos asociados con estos. o 5oncentrarse ms en la reduccin de los riesgos que en el cumplimiento del proceso. <5omo responsable de la elaboracin del proceso= el trabajo del equipo de #,& es participar en la definicin de los planes, procesos, estndares y procedimientos para asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para realizar las e"aluaciones de ,& y cumplir los requerimientos del proyecto y las polticas de la organizacin. Para cumplir este rol el aseguramiento de la calidad debera comenzar en las fases tempranas del proyecto. &qu con"iene aclarar que no necesariamente las personas que definen la metodologa a seguir pertenecen al equipo de ,&. !efinir la metodologa puede llegar a ser o no una acti"idad del equipo de ,&. 0na estructura posible en el proceso de mejora del software puede ser contar con un #'PA /#oftware 'ngineering Process Aroup1 totalmente independiente del equipo de ,&, encargado de definir la metodologa mientras que el equipo de ,& se limita a "erificar que se cumpla dicha metodologa.

PPT62

Consideraciones
Para ser efecti"o, el equipo que realiza #,& debe ser independiente de la organizacin de desarrollo. &unque tener un grupo de auditora independiente es difcil de aplicar en organizaciones chicas donde hay peque os ambientes de desarrollos. Pero si la organizacin es madura y tiene una cultura orientada a la calidad, la funcin de #,& puede estar embebida en el proceso. 5uando el equipo de #,& esta embebido en el proceso, se deben resol"er "arios incon"enientes para garantizar la objeti"idadE o *odo aquel que realice acti"idades de aseguramiento de la calidad debera estar entrenado en el aseguramiento de la calidad.o +as acti"idades de aseguramiento de la calidad realizadas para un producto deberan ser separadas de aquellas in"olucradas en el desarrollo y mantenimiento del mismo. o !ebe estar disponible un canal de comunicacin independiente en el ni"el apropiado de la gerencia para poder escalar las no conformidades cuando sea necesario.

*odo aquel que realice acti"idades de aseguramiento de la calidad debera estar entrenado en el aseguramiento de la calidad.+as acti"idades de aseguramiento de la calidad realizadas para un producto deberan ser separadas de aquellas in"olucradas en el desarrollo y mantenimiento del mismo. !ebe estar disponible un canal de comunicacin independiente en el ni"el apropiado de la gerencia para poder escalar las no conformidades cuando sea necesario. 'l equipo de #,& pro"ee a la gerencia de informacin fehaciente, objeti"a en el momento adecuado. +a cla"e aqu esta en que el grupo de #,& pro"ee a la gerencia de informacin t%cnica objeti"a. +a gerencia necesita "er a la gente de #,& como una fuente de informacin significati"a que puede ayudarla a tomar decisiones difciles. +a Aerencia usa esta informacin para tomar decisiones de negocio apropiadas. +a objeti"idad en la e"aluacin de calidad de los procesos y productos es

crtica para el %(ito del proyecto. +a objeti"idad se logra con independencia del equipo de #,& y sentido com$n o criterio. Cay diferentes maneras de realizar e"aluaciones objeti"as, entre las que se incluyenE

o &uditoras formales realizadas por un rea de #,& independiente de la organizacin. o Be"isiones de a pares que pueden se realizadas con distintos ni"eles de formalidad. o Be"isiones rigurosas en el lugar de desarrollo.o Be"isiones distribuidas y comentarios del producto. *eniendo en cuenta estas consideraciones podemos decir que la tarea del equipo de #,& es un conjunto planificado de tareas, acti"idades y acciones ejecutadas independientemente de la organizacin que desarrolla software, que pro"ee a la gerencia del proyecto informacin fehaciente en un momento preciso que puede ser usada para tomar decisiones de negocio apropiadas.

PPT65
Las pruebas del software (software testing) son parte del proceso de control de calidad del software (SQA), donde especialistas en procesos de software y auditores estn preocupados por el proceso de desarrollo de software en lugar de los artefactos, tales como documentacin, cdigo y sistemas. Ellos examinan y cambian el proceso de ingeniera del software en s para reducir la cantidad de errores en el software entregado: denominada tasa de defectos. Lo que constituye una Aceptable tasa de defectos depende de la naturaleza del software; un simulador de vuelo de un juego de video podra tener una tolerancia mucho ms alta que un software para un avi&oacuten real.Aunque existe una estrecha relacin con SQA, los departamentos de pruebas a menudo existen de forma independiente, y podra no haber funciones SQA en algunas compaas.

Las pruebas de software son una tarea destinada a detectar los defectos en el software contrastando los resultados esperados de un programa informtico con los resultados reales de un conjunto dado de entradas. Por el contrario, QA (control de calidad) es la implementacin de las polticas y procedimientos destinados a prevenir los defectos que se produzcan en primer lugar. Por lo que el control de la calidad es una serie de re"isiones, y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. +a garanta de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de informacin de la gestin. 'l objeti"o de la garanta de la calidad es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto, por lo que se "a adquiriendo una "isin ms profunda y segura de que la calidad del producto est cumpliendo sus objeti"os. 's de esperar, que si los datos proporcionados mediante la garanta de la calidad identifican problemas, la gestin afronte los problemas y aplique los recursos necesarios para resol"erlos. +a garanta de calidad del software comprende una gran "ariedad de tareas, asociadas con dos constituti"os diferentesE los ingenieros de software, que realizan trabajo t%cnico, y un grupo #,&, que tiene la responsabilidad de la planificacin de garanta de calidad. 'l trabajo t%cnico necesita ser re"isado por la misma razn que los lpices necesitan gomasE errar es humano. +a segunda razn por la que necesitamos re"isiones t%cnicas es que, aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan mas fcilmente al que los origina que a otras personas. 'l proceso de re"isin es, por lo tanto la respuesta a la plegaria de Bobert BurnsEG,ue gran regalo sera poder "ernos como nos "en los demsH 0na re"isin es una forma de apro"echar la di"ersidad de un grupo de personas paraE
1. 8. 2. I. 3. J.

#e alar la necesidad de mejoras en el producto de una sola persona o de un equipo 5onfirmar las partes del producto en las que no es necesaria o no es deseable una mejora. 5onseguir un trabajo de mayor calidad ma(imizando los criterios de 5orrectitud y 5ompletitud principalmente .

'(isten muchos tipos diferentes de re"isiones que se pueden lle"ar adelante como parte de la ingeniera del software. 5ada una tiene su lugar. 0na reunin informal durante el almuerzo o en un caf% es una forma de re"isin, si se discuten problemas t%cnicos. 0na presentacin formal de un dise o de software a una audiencia de clientes, ejecuti"os y personal t%cnico es una forma de re"isin. #in embargo en %ste trabajo nos concentraremos en una re"isin t%cnica formal, que llamaremos )nspeccin de #oftware

PPT72
La garanta de calidad en el software no es una certificacin impuesta luego de haber desarrollado un programa. Es un proceso que involucra las siguientes actividades: 1) Aplicacin de metodologas de inge- niera de software para conseguir una

especificacin y un diseo de alta calidad.

2) Realizacin de revisones tcnicas formales. 3) Prueba del software. 4) Ajustealosestndaresdelaorgani- zacin.
5) Control

de cambios y modificaciones (mantenimiento).

6) Mediciones. 7) Registro

e ,informes.

La garanta de calidad en el software comienza realmente con la aplicacin de una

metodologia formal para enfrentar las etapas de anlisis y diseo del . sistema a construir; luego de creada la especificacin del sistema (o prototipo), se debe garantizar su calidad. La actividad que nos permite garantizar la calidad es la revisin tcnica formal realizada por el grupo de control de ca- lidad. . Los objetivos de la revisin tcnica for- mal son: 1) Descubrir errores en la funcin, la lgica o la implementacin de cual- quier representacin del software. 2) Verificar que el software bajo revi- sin alcanza los requerimientos.

3) Garantizarqueelsoftwarehasegui- do los estndares predefinidos. 4) Conseguir un software que sea de- sarrollado en forma uniforme.
S) Propender por que los proyectos sean manejables.

La revisin tcnica formal es un proceso que se aplica a cada una de las fases del desarrollo del sistema en el momen- to en que el grupo de trabajo considera terminada su labor en esa fase. Como resultado de la revisin tcnica formal se obtiene una autorizacin para que el grupo pueda continuar con la fase siguiente, o una recomendacin de no continuar hasta realizar las modificacio- nes y ajustes al proceso en'la fase bajo revisin (Grfico
S).

Una vez que se ha terminado la imple- mentacin, se inicia la fase de pruebas del software. Durante esta fase se dise- an casos de prueba que ayudan a la deteccin de errores producidos en las fases anteriores y no detectados duran- te la revisin tcnica formal. Para muchos grupos de desarrollo las pruebas del software son consideradas. una "red de seguridad" para la garanta de la calidad. Una de las principales amenazas para mantener la calidad de un software, es el proceso de mantenimiento a travs