Universidad Tecnolgica Metropolitana Facultad de Ingeniera Escuela de Informtica

Ingeniera de Software Gestin de Testing

Integrantes : Andrs Figueroa Felipe Grandy Pedro Maldonado Arturo Castillo Profesor Fecha : Oscar Magna V Sergio Muoz R : 03 06 - 2009

La Ingeniera de Software como Disciplina

La ingeniera del software es una disciplina de la ingeniera cuya meta es el desarrollo costeable de sistemas de software. Este ofrece mtodos y tcnicas para desarrollar y mantener software de calidad, comprendiendo todos los aspectos de su produccin. Tiene como objetivos principales la bsqueda de tcnicas que mejorasen l calidad y permitiesen reducir l j la lid d iti d i los costos d l t de las soluciones basadas en computadores. En 1999 con un trabajo en conjunto por la IEEE y la ACM se fijan estndares ticos y de calidad para considerar la ingeniera de software como disciplina formal de la ingeniera.

El Software y su evolucin
Durante los primeros aos de la era del computador, el software se contemplaba como un aadido, la creacin de este era un diseo artesanal artesanal" para el que existan pocos mtodos sistemticos sistemticos. El software se diseaba a medida para cada aplicacin y tenia una distribucin relativamente pequea. La mayora del software se desarrollaba y era utilizado por la misma p persona u organizacin. La misma persona lo escriba, lo ejecutaba y, g p , j si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseo era un proceso implcito, realizado en la mente de alguien y, la documentacin normalmente no exista.

El Software y su evolucin
Los primeros aos 1950 - 1965 La segunda era 1965 - 1975 Sistemas de tiempo Real Software a a medida Diseo implcito Procesos no documentados Software como producto Sistemas de gestin de Base de datos Mantenimiento i i del Software Incorporacin de inteligencia Acceso instantneo a instantneo datos Sistemas expertos Redes neuronales artificiales Inteligencia artificial La tercera era 1975 - 1985 La cuarta era 1985 -

Enfoque de Ingeniera
Usando un enfoque de ingeniera para desarrollo de software implica que: el proceso de desarrollo es bien conocido; los proyectos se planifican; ciclo de vida de los modelos son definidos; existen estndares para los productos y procesos; las mediciones se utilizan para evaluar productos y procesos de calidad calidad.

Enfoque de Ingeniera

La validacin y verificacin de los procesos desempean un papel clave en la determinacin de la calidad; l i los ingenieros ti i tienen una educacin d i adecuada, capacitacin y certificacin.

Enfoque de Ingeniera
Componentes de un proceso de ingeniera de software. El proceso d d de desarrollo d ll de software, como la mayora de los procesos de ingeniera, debe ser gestionado Es decir gestionado. decir, se debe disear, aplicar, evaluar, y mantenerse. Al igual que en otras disciplinas de la ingeniera, el d i i l desarrollo d ll de software es un proceso debe evolucionar de forma coherente y previsible previsible.

Testing
Una de las disciplinas de la ingeniera de software que participa, de madera transversal, durante todo el ciclo del d l software es el T ti ft l Testing que d t determina el nivel d i l i l de calidad que puede llegar a tener este. Aqu se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema sistema.

Testing
La necesidad de productos de software de alta calidad es lo que ha motivado a identificar y cuantificar los factores d calidad t l f t de lid d tales como l f ilid d d uso, la facilidad de comprobabilidad, mantenibilidad y fiabilidad. Las pruebas de software, testing o beta testing es un proceso usado para identificar posibles fallos de implementacin, calidad, implementacin calidad o usabilidad de un software software. Estas pruebas son llevadas a cabo por un Tester quien se encarga de realizar un anlisis crtico del producto en un entorno apartado al de produccin.

Objetivos de la revisin del software Detectar defectos en la lgica, funcin o implementacin. implementacin Verificar satisfaccin de requerimientos. q Asegurar cumplimiento de estndares. Fomentar uniformidad Hacer proyectos ms manejables.

Norma Iso
La ISO 9126 es un estndar internacional para la evaluacin del Software. El estndar est di idid en cuatro partes l t d t dividido t t las cuales di i l dirigen, respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso. Esta se centra en 6 puntos bsicos y fundamentales:
Eficiencia: comportamiento del producto y el comportamiento de

recursos.
Faciliad de mantencin: facilidad de anlisis, facilidad de cambio,

, p estabilidad, facilidad de prueba.

Norma Iso
Portablidad: facilidad de instalacin, coformidad,

facilidad de reemplazo.
Funcionalidad: adecuacin, precisin,

seguridad.
Confiabilidad: marudrez, tolerancia a fallas,

recuperacin de fallas fallas.

Usabilidad: facilidad de comprensin, facilidad p ,

de aprendizaje, facilidad de

operacin.

Conceptos bsicos de Testing

Una falla (failure) ocurre cuando un programa no se comporta

adecuadamente; representa una propiedad del sistema en j ejecucin.

Un defecto (fault) existe en el cdigo; si se encuentra puede causar

una falla, no hay defecto si el sistema no puede fallar.

Un error (error, mistake) es una accin humana que resulta en

software que contiene un defecto en el sistema, hacindolo fallar.

N Nunca se puede probar que un programa no f ll solo se puede d b fallar, l d

probar que contiene defectos.

Conceptos bsicos de Testing

Un test exitoso es aquel que encuentra muchos

defectos, no lo opuesto, por lo tanto, desarrollo exitoso puede ll d llevar a t ti no exitoso ( encuentra testing it (no t defectos).
El propsito del testing es encontrar defectos, es un

proceso destructivo, se debe mostrar que algo es incorrecto. incorrecto

Cada vez que se corrigen defectos detectados, se

pueden introducir nuevos defectos al sistema sistema.

Proceso de testing
Planificacin: al comienzo del desarrollo, se establecen guas,

mtodos y niveles de ambicin, si ser automtico o manual, estimacin de recursos requeridos, estndares involucrados.
Identificacin: estimacin ms detalla de los recursos requeridos. Especializacin: descripcin de las pruebas a nivel funcional

(propsito), y a nivel detallado (ejecucin paso a paso).

Ejecucin: desarrollo de las pruebas tanto automatizadas como

manuales, registrando l resultados. l i t d los lt d

Proceso de testing

Anlisis de defectos: identificacin del

defecto y sus causas y de las acciones causas, correctivas.

Completacin: preparacin del

equipamiento y l casos d prueba para i i t los de b uso posterior, registro de documentacin.

Garanta de Calidad del Software

Que es la Calidad del Software ? La garanta de la calidad del software SQA es una actividad de proteccin que se aplica a lo largo de todo el proceso del Software.

Engloba:

-Enfoque de gestin de calidad -Tecnologa de ingeniera de software efectiva -Revisiones tcnicas formales que se aplican durante el proceso del software -Estrategia de prueba multiescalada -Control de documentacin de Software -Procedimiento para asegurar ajuste en los estndares -Medicin e informes

Garanta de Calidad del Software

Conceptos de Calidad
-Control de Variacin -Calidad -Calidad de Diseo -Calidad de Concordancia -Control de Calidad -Coste de Calidad -Garanta de Calidad -Coste de Fallos

Garanta de Calidad del Software

Control de Variacin: es el centro del control de calidad. Nos esforzamos en controlar la variacin en el proceso que aplicamos, recursos que consumimos y los atributos de calidad del producto final. final Calidad: Caracterstica o Atributo de algo. Como atributo nos referimos a las caractersticas mensurables. Cuando examinamos un elemento segn caractersticas mensurables tenemos dos tipos de calidad: calidad de diseo y de concordancia concordancia. Calidad de Diseo: se refiere a las caractersticas que especifican los Ingenieros de Software para un elemento. Calidad de Concordancia: es el grado de cumplimiento de las especificaciones de diseo durante su realizacin

Ingeniera de Software Page 19

Garanta de Calidad del Software

Control de Calidad: es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados asignados. Garanta de Calidad: consiste en la auditora y las funciones de informacin de la gestin. Su objetivo es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto. producto Coste de Calidad: incluye todos los costes acarreados en la bsqueda de la calidad o en las actividades relacionadas en la obtencin de la calidad. Costes de Fallos: son los costes que desapareceran si no surgieran defectos antes del envo de un producto a los clientes.

Garanta de Calidad del Software

Garanta de Calidad del Software
-Software de Alta Calidad como meta mas importante -Los requisitos del Software son la base de las medidas de calidad -Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del Software -Existe un conjunto de requisitos implcitos q a menudo no se mencionan j q p que

Software de alta calidad: concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos con los establecidos, estndares de desarrollo explcitamente documentados, y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.

Garanta de Calidad del Software

Problemas de fondo La historia de la garantia de calidad en el desarrollo de software es paralela a la historia de la calidad en la creacin de hardware. En los primeros aos de la informtica, la calidad era responsabilidad nicamente del p , p programador. Pasado el tiempo se incorporaron estndares de garanta de calidad para el software en los contratos militares para desarrollo de software y se extendieron rpidamente a los desarrollos de software en el mundo comercial. Muchos de los que constituyen una organizacin tienen responsabilidad de garanta de calidad de software.

Garanta de Calidad del Software

Grupo de SQA Actua como representacin del cliente en casa p La gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente. El grupo SQA intenta responder a estas y otras p g g p p preguntas p para asegurar q se mantiene la g que calidad del software La SQA comprende una gran variedad de tareas, las cuales estn asociadas a dos constitutivos distintos: los ingenieros de software q realizan trabajo tcnico y un g p de g que j grupo SQA que tiene la responsabilidad de la planificacin de garanta de calidad.

Garanta de Calidad del Software

El instituto de Ingeniera del Software recomienda un conjunto de actividades para un grupo independiente de SQA: p -Establecimiento de un Plan de SQA para un proyecto. Este plan contempla evaluaciones a realizar, auditorias y revisiones, estndares aplicables al proyecto, procedimientos para informacin, documentos generados por el g p SQA y realimentacin. , g p grupo -Participacin en el desarrollo de la descripcin del proceso de software del proyecto. Revisin de las actividades de ingeniera del software para verificar su ajuste al proceso de software definido. -Auditora de los productos de software designados p p g para verificar el ajuste con los definidos j como parte del proceso del software -Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido -Registrar lo q no se ajuste a los requisitos e informar a sus superiores. g que j q p

Garanta de Calidad del Software

Revisiones del Software
Las revisiones del software son un filtro para el proceso de ingeniera del Software. Sirven para purificar las actividades de ingeniera del software que suceden como resultado del anlisis, el diseo y la codificacin. Existen muchos tipos distintos de revisiones que se pueden llevar adelante como parte de la ingeniera del software. Una de las ms importantes RTF. Revisin Tcnica Formal (RTF) es el filtro mas efectivo desde el punto de vista de garanta de calidad. Encontrar errores antes de pasar a otra actividad de ingeniera del software o de entregar al cliente.

Garanta de Calidad del Software

Revisiones Tcnicas Formales
RTF: actividad de garanta de calidad del software llevada a cabo por los ingenieros del software. Objetivos: - Descubrir errores en la funcin, la lgica o implementacin de cualquier representacin del Software. - Verificar que el software bajo revisin alcanza sus requisitos. - Garantizar que el software ha sido representado de acuerdo con ciertos estndares predefinidos. - Conseguir un software desarrollado de forma uniforme. - Hacer que los proyectos sean ms manejables. Realizacin de una reunin bien planificada, controlada y atendida.

Garanta de Calidad del Software

Revisiones Tcnicas Formales
- Reunin de revisin - 3 a 5 personas - Preparar por adelantado requiriendo no mas de 2 horas por persona adelantado, - Duracin de a lo mas 2 horas - Limitar centro de Atencin -Registro de sucesos

Pruebas del Software

Conceptos
Prueba: ti id d P b actividad en l cul un sistema o uno d l componentes d l sistema se ejecuta en la l i t de los t del i t j t circunstancias previamente especificadas, de manera que los resultados sean registrados y evaluados. Caso d P b es un conjunto d entradas, condiciones d ejecucin y resultados C de Prueba: j t de t d di i de j i lt d esperados desarrollados para un objetivo en particular. Defecto: es una definicin de datos o un paso de procedimiento incorrecto en un programa. Fallo: es la incapacidad de un sistema o de alguno de sus componentes para realizar alguna funcin requerida.

Pruebas del Software

Objetivos -D Descubrir errores bi - Tener una alta probabilidad de descubrir un error no encontrado hasta ese momento

Importancia - Fiabilidad del Software - No es una actividad secundaria

Pruebas del Software

Principios de una Prueba - Realizar seguimiento hasta los requisitos de los clientes - Planificacin - Comenzar desde lo ms pequeo hasta lo mas grande - Pruebas conducidas por un equipo - Evitar casos de prueba no documentados - No se debe realizar un plan de prueba suponiendo que no hay defectos y destinando pocos recursos a estas pruebas

Pruebas del Software

Mtodos de diseo de casos de prueba
Principales Enfoques - Enfoque estructural o de caja blanca - Enfoque funcional o de caja negra - Enfoque aleatorio

Pruebas del Software

Enfoque Estructural
Grafo d fl j G f de flujo o d secuencia de i - Sealar sobre el cdigo cada condicin de cada decisin tanto en sentencias If-then y Case-of como en los ciclos While o Until. - Agrupar el resto de las sentencias en secuencias situadas entre cada dos condiciones segn los esquemas de representacin. - Numerar tanto las condiciones como los grupos de sentencias de manera que se les sentencias, asigne un identificador nico.

Pruebas del Software

Enfoque Estructural

Pruebas del Software

Esquemas de representacin

Pruebas del Software

Complejidad ciclomtica de Mc Cabe
- Ej Ejecucin d un conjunto d caminos i d i de j t de i independientes di t - Nmero mximo de caminos independientes ? - Complejidad ciclomtica de Mc Cabe, V(G), se puede calcular de la siguiente manera:

Pruebas del Software

Complejidad ciclomtica de Mc Cabe

Pruebas del Software

Enfoque Funcional
Particiones o Cl P ti i Clases d equivalencia de i l i - Cada caso de prueba debe cubrir el mximo N de entradas. - D b tratarse el dominio d valores d entrada di idid en un N fi it d clases d Debe t t l d i i de l de t d dividido finito de l de equivalencia. - Mtodo de diseo: identificacin de clases de equivalencia, creacin de los casos de prueba correspondientes correspondientes.

Pruebas del Software

Enfoque Funcional
Particiones o Cl P ti i Clases d equivalencia de i l i Paso 1 - Identificar las condiciones de las entradas del programa. - A partir de esto, identificar clases d equivalencias ( d d t vlidos y no vlidos ) ti d t id tifi l de i l i de datos lid lid Paso 2 -Asignacin de un nmero nico a cada clase de equivalencia. - Hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba se prueba, tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible. - Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, prueba escribir un caso para una nica clase no vlida sin cubrir cubrir.

Niveles de Testing
Sistemas de gran tamao necesitan abordarse

en niveles
En la mayor parte de los casos hay 3 o 4 niveles
Unidad: Componentes individuales Integracin: Componentes g p g p grupales Sistema: Sistema como un todo Aceptacin: Requerimientos del sistema

Niveles de Testing

Niveles de Testing
El enfoque usado para el desarrollo del software

impactar en como se realizarn las pruebas

Dos grandes p g paradigmas p g para el desarrollo del

software
Por Procedimientos Orientado a Objetos j

Actividades de Prueba del Software

Doc. Requisitos

Anlisis P. validacin Diseo

Doc. Diseo

P. integracin Codificacin Integracin Mantenimiento P. unidades

Cod. Mdulos

Cd. Completo

Modelo de ciclo de vida en V

Requisitos de Usuario Pruebas de Usuario/Acept

Requisitos de Software

Pruebas de Sistema

Arquitectura

Pruebas de Integracin

Diseo Detallado D t ll d

Pruebas Unitarias U it i

Codificacin

Pruebas de Unidad

Propsito: Encontrar defectos en un mdulo o funcin. Realiza solo una funcin Puede compilarse por si solo Poca cantidad de cdigo, debera verse entero en la pantalla Desarrollar las pruebas de unidad son las ms fcil de desarrollar, ejecutar p , j y guardar y analizar resultados Solucionar los problemas en este nivel es fcil debido al reducido cdigo Se deben incluir pruebas para

Casos habituales y casos extremos de los parmetros. Todas l T d las excepciones. i Todos los tipos de efectos laterales.

Estndar IEEE 1008-1987 para pruebas unitarias del Software

Planificacin

El enfoque general del Plan, los recursos, y el calendario Determinar las caractersticas a probar Redefinir el plan general

Adquirir conjunto de pruebas

Diseo del conjunto de pruebas Implementar plan refinado y diseo

Medicin

Ejecutar los procedimientos de prueba Comprobar la terminacin Evaluacin de unidades y esfuerzo

Pruebas de Integracin

Propsitos P it

Detectar errores en las interfaces de las unidades Ensamblar las unidades en subsistemas y finalmente en un sistema

Las pruebas de unidad puede no recrear la situacin de tener otros mdulos o unidades combinadas Funciona mejor como un proceso iterativo Debemos planificar las pruebas de integracin:

En el Documento de Arquitectura, o bien en el Plan de Pruebas de Sistema. Hay que destinar recursos a esto (gente y tiempo).

Al probar cada mdulo individualmente es necesario crear mdulos auxiliares que simulen las acciones de los mdulos invocados por el mdulo que se est probando. Debido a todo esto, a menudo se combinan ambos tipos de prueba: unitarias y de integracin, por ejemplo a travs de la prueba llamada desarrollo incremental.

Mix: Pruebas Unitarias y de Integracin

Desarrollo Incremental
El tipo de prueba incremental consiste en agregar cada

p j p mdulo o componente individual al conjunto de componentes existentes y el conjunto resultante se prueba.

Esto reduce la necesidad de crear mdulos conductores,

permitiendo adems examinar ms detalladamente las interfaces.

Cuando las pruebas unitarias y de integracin se realizan p g

separadamente es difcil identificar los componentes individuales o mdulos que causan resultados incorrectos.
Lo ms probable es que los problemas que surjan al

incorporar un nuevo componente, surjan de este ltimo o de las interfaces entre l y los otros componentes.

Pruebas de Integracin: Estrategias de integracin g g

Estrategia de arriba a abajo (top-down).

El primer componente o mdulo que se desarrolla y prueba es el que est arriba en la jerarqua.

Los mdulos de nivel ms bajo se sustituyen por mdulos auxiliares que simulan el resto de la funcionalidad. En este caso no son necesarios mdulos conductores

Una ventaja de esta estrategia es que las interfaces entre los mdulos son probadas en una fase temprana y con frecuencia.

Estrategia de abajo a arriba (bottom-up)

En este caso se crean primero los componentes de ms bajo nivel y se crean mdulos conductores para simular las invocaciones.

Los mdulos auxiliares son necesarios en raras ocasiones.

Este tipo de enfoque de las pruebas permite un desarrollo ms paralelizado que el enfoque el Top-Down, pero presenta mayores dificultades a la hora de planificar y de gestionar las pruebas.

Pruebas de Sistema
Propsito: Asegurar que se cumplen los

requisitos de software.
Este es un proceso formal:
Planificado en el Plan de Pruebas de Sistema. L b La base son l casos d prueba d fi id en l los de b definidos la

Especificacin de Pruebas de Sistema.

Resultados se registran en el Acta de Pruebas de

Sistema.

Pruebas de Sistema S alcance es el sistema completo. L pruebas Su l l i t l t Las b tpicas que deben hacerse son:
Pruebas funcionales

Consisten en determinar que se han cumplido los requisitos de software del sistema, y que ste realiza correctamente todas sistema las funciones especificadas en los requisitos de usuario.

Pruebas de comunicaciones

Determinan si las interfaces entre los componentes del sistema funcionan adecuadamente. Esto se refiere tanto a: las comunicaciones entre dispositivos remotos, las interfaces f entre diferentes mdulos, interfaces hombre-mquina, etc.

Pruebas de Sistema

Pruebas de rendimiento

Consisten en determinar que los tiempos de respuesta estn dentro de los intervalos establecidos en las especificaciones del sistema.

Pruebas de volumen

Consisten en examinar el funcionamiento del sistema cuando est trabajando con grandes volmenes de datos, simulando la carga de trabajo esperada. g g j p

Pruebas de sobrecarga (o stress)

Consisten en comprobar el funcionamiento del sistema en el umbral lmite de los recursos, sometindolo a cargas excesivas. recursos excesivas

Pruebas de disponibilidad de datos

Consisten en demostrar que el sistema puede recuperarse ante fallas sin fallas, prdidas indebidas de datos. Esto considera el hardware y el software.

Pruebas de Sistema

Pruebas de facilidad de uso

Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurarse que se acomoda al modo habitual de trabajo de stos, como para determinar si les facilita su trabajo. , p j

Pruebas de operacin

Consisten en comprobar los procedimientos de operacin, incluyendo los procedimientos de inicio y fi d t b j y l f ilid d d operacin. di i t d i i i fin de trabajo la facilidad de i

Pruebas de entorno

Consisten en verificar las interacciones del sistema con otros sistemas dentro sistemas, del mismo entorno.

Pruebas de seguridad

Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.

Pruebas de Aceptacin
Propsito: Certificar que los requisitos del cliente se han

cumplido satisfactoriamente y por lo tanto se puede iniciar la i i i l produccin ( l marcha bl d i (o la h blanca). )

Esta etapa tambin llamada pruebas de aceptacin

debe estar a cargo de un equipo independiente del de desarrollo:

Puede ser otra gente de la empresa. Puede ser el cliente, si hay uno especfico, capaz de hacerlo. Hay empresas que ofrecen este servicio.

Pruebas de Aceptacin
Son aquellas pruebas que realiza el usuario/cliente con el objeto de

comprobar si el sistema es aceptable para l.

E t pruebas son del mismo ti Estas b d l i tipo que l mencionadas las i d

anteriormente, pero son determinadas por el usuario, en lugar de serlo por el equipo de desarrollo.
Un tipo especial de estas pruebas es el de la ejecucin en paralelo

con el viejo sistema (legado), para comparar los resultados producidos por ambas ejecuciones.
Se chequea fundamentalmente: correctitud, robustez, performance

y documentacin.

Pruebas de regresin

Propsito: Asegurar que cambios en el software no introducen nuevos defectos. Se ejecutan luego de modificar el sistema. Consisten en repetir las pruebas que ya se han hecho al sistema en una versin anterior, y comparar el resultado actual con el anterior. i t i l lt d t l l t i Aqu hay un beneficio enorme al tener un ambiente automatizado de pruebas. pruebas Repetir slo pruebas de verificacin

Pruebas de unidades Pruebas de integracin

Plan de Pruebas: IEEE 829

Pasos que incluye: Identificador de plan de pruebas (se muestra el estndar a seguir para

el nombre de las pruebas)

Introduccin (en que consiste las pruebas del sistema) Elementos a probar Caractersticas a ser probadas Caractersticas que no se probarn Enfoque Criterio de fallo o aceptacin de los elementos p
56

Plan de Pruebas: IEEE 829

Criterio de Suspensin y Reanudacin de requerimientos Entregables de las pruebas Tareas de las pruebas Necesidades del entorno Responsabilidades Equipo y necesidades de capacitacin Agenda
57

Plan de Pruebas: IEEE 829

Riesgos y contingencias Acuerdos

A las pruebas se les ha empezado a llamar de manera formal

verificacin y validacin.

Existen metodologas ms robustas como el TMMI (Test Maturity

Model) M d l)
58

Plan de pruebas

59

Pruebas organizacionales
Tareas del equipo de pruebas

Mantener y aplicar las politicas de prueba. Desarrollar y aplicar pruebas para la estandarizacin. Participacion en la revision de codigo, diseo y requerimientos. Planeamiento de pruebas Diseo de pruebas Ejecucin de las pruebas

Pruebas de medicion. Pruebas de control de costos, fechas, y tareas. Adquisicin de herramientas y equipo Ad i i i d h i i para las pruebas. Identificar y aplicar nuevas herramientas y metodos de pruebas. Capacitar nuevo personal.

Entregar informes de las pruebas.

Pruebas organizacionales
Introduciendo especialistas en pruebas Una vez que las politicas y metas que se deben alcansar para cada etapa del proyecto ,tanto globales como particulares, esten establecidas (lo que implica un gran avanse tanto particulares para la organizacion), se debe crear un equipo de especialistas de pruebas, asignar recursos a ellos y crear una carrera para estos profesionales entre otras cosas. Esto implica redisear las funciones y administracion de la jerarquia organizacional

Pruebas organizacionales
Ingeniero en pruebas El ingeniero en pruebas como primer paso debe asegurar que en su area las pruebas que estan siendo relizadas son efectivas y productivas productivas. Estos no son desarrolladores ni analistas pero deben tener conocimiento de estas areas, estos solo agregan valor al producto de software en terminos de alta calidad y satisfaccin al cliente cliente. Su punto de vista debe ser constructivo y no destructivo.

Pruebas organizacionales
Habilidades del ingeniero de pruebas (organizacionales).

Habilidades organizacionales y de planeacin. Habilidad para encontrar y poner atencion a los detalles. Determinacin para descubrir y solucionar problemas. Habilidad para trabajar en grupo y resolver conflictos. Habilidad ensear a otros otros.

Habilidad para trabajar con los usuarios y clientes. Gran habilidad oratoria y de redaccin. Habilidad H bilid d para trabajar en multiples b j li l ambientes . Creatividad.

Pruebas organizacionales
Habilidades del ingeniero de pruebas (tecnicas).

Estudios en ingenieria de software con sus principales metodologias. Gran conocimiento de codificacion en diferentes lenguajes. Estudios de los principales metodos y pruebas de testeo.

Conocimiento de como funcionan las redes, bases de datos y S O S.O. Conocimiento de los distintos documentos de pruebas y uso de p estos.

Experiencia en planificacin de pruebas y ejecucion de estas.

Saber utilizar distintas herramientas y software de pruebas.

Pruebas organizacionales
Secuencia para construir un equipo de trabajo

Pruebas organizacionales
Estructura del equipo de pruebas

Test manager: creacion de politicas, interaccin con el cliente, plan d i t i l li t l de pruebas, supervision del personal y reportes de avance y estado. Test leader: apoya al director de pruebas ademas de involucrarse en las pruebas de ejecucion y reportes. Test engineer: disea, crea y ejecuta las pruebas. Junior test engineer: generalmente son empleados nuevos que estan ganando experiencia ayudando al ingeniero de pruebas.

Pruebas organizacionales
Crear carrera profesional dentro de la empresa (ejemplo AT&T)

Apprenticeship: nuevo personal que ingresa el cual asiste a seminarios, i l l i t i i cursos para obtener los mejores habilidades y metodos. Mastery:asume mas responsabilidades y se involucra en el proceso de planeacion, ejecucin y diseo de pruebas pruebas. Specialization:cuendo de alcanza un nivel de conocimiento mayor en alguna alg na area como standares de seguridad entre otros.

Pruebas organizacionales
Crear carrera profesional dentro de la empresa (ejemplo AT&T)

Leadership: en este nivel el ingeniero necesita ademas d l i i it d de la especializacion en alguna area habilidades tecnicas y comunicacionales. Top-level tester:necesita gran conocimiento en el area de pruebas, ademas debe trabajar con los mas altos directivos en la direccion de estrategias para el testeo.

Pruebas organizacionales
Certificacin de ingenieros en prueba Algunas empresas piden como requisitos a sus ingenieros estar certificados para asegurar sus habilidades como testeadores testeadores. En Estados Unidos existen dos organizaciones para la certificacin la primera es The American Society for Quality (ASQ) y The Quality Assurance Institute (QAI).

Pruebas organizacionales
Introducir las actividades de pruebas al ciclo de vida de un software Para asegurar la calidad del software se deben introducir las pruebas los mas tempranamente posible dentro del ciclo de vida, ya que, si se realizan pruebas solo en vida que el termino del projecto no se toman en cuenta ni el tiempo ni el presupuesto. Existen variados metodos para incorporar la calidad de software en el ciclo de vida estandar como: CMM CMMI TMM TMMI V model entre otros. CMM, CMMI, TMM, TMMI, V-model otros A continuacin explicaremos como usar el V-model:

Pruebas organizacionales
Introducir las actividades de pruebas al ciclo de vida de un software

Pruebas organizacionales
Introducir las actividades de pruebas al ciclo de vida de un software V-model Fase de requerimientos: en esta etapa se deben tomar y verificar que los requerimientos esten bien definidos y sean testeables, esto implica reunirse con el testeables cliente para que este acepte los mismos, claro, previamente provados con algun metodo como caja blanca o negra. Ademas en esta etapa se deben calcular los costos y hitos importantes del proyecto. Fase de Diseo:en esta etapa se deben revisar si el diseo cumple con las politicas antes establecidas, si estas se cumplen se puede pasar a la etapa de integracion donde el ingeniero de p g pruebas debe interactuar directamente con el diseador p para luego crear el documento que sera usado para reparar el codigo o desarrollar nuevas salidas.

Pruebas organizacionales
Introducir las actividades de pruebas al ciclo de vida de un software V-model Fase de Codificacion: en esta etapa se pueden completar las tareas que no se han terminado en la fase de diseo ademas de comenzar la etapa de codificacion por los diseo, desarrolladores ,los ingenieros de pruebas pueden ir haciendo los testeos a los modulos ya terminados de forma paralela. Fase de ejecucion:una vez finalizado la etapa de codificacion se puede comenzar a ejecutar a cabalidad las pruebas, que se estimaron previamente,sobre el softwarae con todos sus modulos completos permitiendo estimar el desempeo de este y generar el reporte de los incidentes. p

Controlando y monitoriando el proceso de pruebas

Terminos introductorios Monitorear un projecto: se refiere a las actividades y tareas que se deben realisar periodicamente para comparar metas y estado de cada uno de los proyectos obteniendos estos datos se pude generar un reporte para comparar el avance real con las tareas planeadas. Controlar un proyecto: consiste en desarrollar y aplicar un conjunto de acciones correctivas que permitan mostrar alguna desviacin de lo planeado para corregirla.

Controlando y monitoriando el proceso de pruebas

Medicin e Hitos para controlar y monitorear Todo proceso debe tener metricas asociadas a este.Las metricas ayudan a determinar el estado y calidad de los procesos, evaluar riesgos prevenir defectos y determinar procesos riesgos, cuando las pruebas deben terminar. Los hitos son una herramienta importante para monitorear el progreso del proyecto, un hito es un evento tangible que se espera que ocurra en una determinada fecha o tiempo del ciclo de vida del software.

Controlando y monitoriando el proceso de pruebas

Medicin e Hitos para controlar y monitorear (grafico de hitos)

En el eje y se encuentran las tareas y en el eje estan l t l j x t los graficos de barra donde muestran el estado de cada uno de acuerdo a las semanas para evaluar el p progreso de una forma mas clara.

Controlando y monitoriando el proceso de pruebas

Medicines para monitorear los procesos de prueba Existen cuatro mediciones fundamentales: Mediciones para monitorear el estado de avance: se debe establecer el avance que se lleva actualmente y comparar con el estipulado en cuanto a tiempo y presupuesto. Mediciones para monitorear la productividad: antiguamente se usaban los Kloc/hora para medir la productividad de cada ingeniero de pruebas pero no es lo mas recomendable, por lo que se recomienda medir el tiempo gastado por cada ingeniero en cada una de las etapas, como diseo de pruebas, planeacion de pruebas, reportes entre otros. Mediciones para monitorear los costos: uno de los metodos ms usados es calcular p que presupuesto total, p ejemplo se si p por j p el total de pruebas q se van a realizar o el p estiman 200 horas totales de pruebas y una de ellas demora 20 horas se puede obtener su porcentaje aportado de la siguiente forma: 20/200*100= 10% .

Controlando y monitoriando el proceso de pruebas

Medicines para monitorear los procesos de prueba Mediciones para monitorear los errores: se deben hacer pruebas de codigo de diseo y planeacion con la ayuda de los desarrolladores para generar reportes para luego reparar estos. Adems existe el test de efectividad el cual permite estimar si las pruebas y controles aplicados tienen un buen impacto en la calidad esto se puede hacer contando los calidad, defectos encontrados y compararlos con los defectos que se tienen historicamente.

Controlando y monitoriando el proceso de pruebas

Reuniones sobre avance y reportes Las reuniones sirven para reportar los avances de cada tarea, si estas estan terminadas o estan pacialmente logradas y los posibles problemas relacionados con las pruebas que realisan los ingenieros en pruebas, ademas de discutir como estos problemas afectaran al proyecto y que plan de contingencia sera usado.

Controlando y monitoriando el proceso de pruebas

Reuniones sobre avance y reportes (entradas y salidas de la reunin)

Entradas:La reunin la componen el equipo d d prueba, l j f d i de de b los jefes de pruebas, el jefe de proyectos, el grupo de softwrae quality assurance, los reportes e , p informacion referente a cada tarea. Salidas:actividades para resolver los distintos problemas gastos v/s problemas, presupuesto, proximas actividades para la siguiente reunin, etc.

Controlando y monitoriando el proceso de pruebas

Criterios para finalizacion de pruebas Todos las pruebas planeadas deben estar ejecutadas y aprobadas por el software. Todas las metas especificas han sido cumplidas (se puede verificar con caja blanca) blanca).

D t t un numero especifico de d f t (esto Detectar ifi d defectos ( t requiere una tabla de datos historicos). El promedio de defectos para un cierto periodo esta por debajo de lo especificado para ese nivel.