Capacitación de Estudio ISTQB

7/24/2019 Capacitacin de Estudio ISTQB

1/338

1


2/338

2

Seminarios y Formacin

Tester CertificadoNivel Bsico

Formacin para el Tester Certificado NivelBsico de acuerdo al programa de estudiosdel ISTQB


3/338

3

ontrol Documentos

ontrol Documentos

Ubicacin Documento SQASA\SGC\Procesos de Soporte\Gestionar el TalentoHumano-TH\Documentos \Capactacin ISTQB\ Capacitacin deestudio ISTQBHRIS-01

Fecha Versin Naturaleza del

Cambio

Elabora Valida Aprueba Distribuir a

Creacindocumento

Scorrea TodosEarango

Lzapata

2008/06/14 1.0 Lcerro


4/338

4

0 Introduccin02 Tabla de Contenidos

El presente curso se ha desarrollado de acuerdo con el programa

de estudios del Certificado de Tester Nivel Bsico, que constade siete captulos:

Captulo 0 Introduccin.

Captulo I Fundamentos de Pruebas. Captulo II Pruebas a travs del Ciclo de Vida del Software.

Captulo III Tcnicas Estticas.

Captulo IV Tcnicas de Diseo de Pruebas. Captulo V Gestin de Pruebas.

Captulo VI Herramientas de Pruebas.


5/338

5

0 Introduccin03 Organizaciones Internacionales

Programa de Capacitacin del ISTQB

En 1998, se desarrolla en Gran Bretaa un programa de capacitacin de mltiplesniveles, Los fundamentos del proceso de pruebas de software son formulados en el programa

de estudios para el nivel bsico (Syllabus for Foundation Level), edicin actual: Abrilde 2007.

Desde 2004 tambin se cuenta con certificaciones para el Nivel Avanzado (AdvancedLevel):

Jefe de Pruebas (Test Manager), Tester Tcnico (Technical Tester), TesterFuncional (Functional Tester)

Se encuentra preparacin de Nivel Experto. Los Consejos/Comits de Pruebas (Testing Boards) (locales) de cada pas

conforman la estructura de la organizacin del International Software TestingQualification Board (www.istqb.org)

Por ejemplo en Espaa: Spanish Software Testing Board (SSTQB), en Alemania: TheGerman Testing Board (GTB)

* ISTQB = International Software Testing Qualification Board
http://www.istqb.org/http://www.istqb.org/http://www.istqb.org/


6/338

6

0 Introduccin04 Programa de Estudios y Evaluacin

El conjunto de diapositivas est basado en el Programa deEstudios de Tester Certificado Nivel Bsico del ISTQB

A continuacin del curso de formacin se puede tomar el examen para obtener elcertificado de Tester Certificado, Nivel Bsico (Certified Tester,

Foundation Level) La evaluacin es realizada por un examinador perteneciente a una organizacin

independiente (por ejemplo ISQI* o GASQ**) Los temas de la evaluacin estn extrados de las secciones correspondientes

a las dadas en el curso de formacin. El examen es de tipo seleccin mltiple,con una duracin de 60 minutos.

Cada pregunta tiene una (de cuatro) nica respuesta correcta. Hay una ponderacin de preguntas por crditos (de acuerdo a su clasificacin

de dificultad) y son 40 preguntas en total. El 60% de crditos deben serrespondidos en forma correcta con el objeto de aprobar el examen.

*ISQI = International Software Quality Institute**GASQ = Global Asociation for Software Quality


7/338

7

0 Introduccin05 Objetivos

Objetivos principales para la formacin de TesterCertificado. Aprender las tcnicas bsicas para planificar las pruebas. Aplicar las tcnicas de prueba de software en proyectos. Seleccionar las tcnicas y objetivos de pruebas apropiados.

Aprender una terminologa comn. Audiencia El curso est dirigido a testers de software, desarrolladores y jefes

de proyecto en un entorno de produccin de software, as como enun entorno de produccin industrial que deseen dar a su

conocimiento un fundamento de mayor solidez. Documentos

Conjunto de diapositivas propias de la presentacin Ejercicios y sus soluciones


8/338

8

I Fundamentos de Pruebas de SoftwareAgenda

Captulo I Fundamentos de Pruebas de Software

I/01 Comprendiendo el proceso de pruebas de software.

I/02 Los Siete Principios Generales del Proceso de Pruebas de Software.

I/03 Proceso de Pruebas Bsico.

I/04 Psicologa en el Proceso de Pruebas


9/338

9

I Fundamentos de Pruebas de Software01 Comprendiendo el Proceso de Pruebas del Software

La Importancia Econmica del Software El funcionamiento de maquinaria y equipamiento depende en una gran

medida al software. No es posible imaginar grandes sistemas, en el mbito de las finanzas ni en

el control de trfico, funcionando sin software.

Calidad del Software Cada vez ms, la calidad del software se ha convertido en un factor

determinante del xito tcnico o comercial de sistemas y productos.

Pruebas para la Mejora de la Calidad Las pruebas y revisiones aseguran la mejora de la calidad de productos de

software as como de la calidad del proceso de desarrollo en s.


10/338

10


Ejemplo de fallo 1: Lanzamiento del Ariane 5

El 4 de Junio de 1996, el vuelo inaugural de la lanzadera Ariane-5 result fallido. Tanslo 40 segundos aproximadamente despus de la iniciacin de la secuencia de vuelo,a una altitud de aproximadamente 3700 m, la lanzadera se desvi de su ruta, se partiy explot.

El software del Ariane 5 reutiliz las especificaciones del Ariane 4, pero la trayectoriade vuelo del Ariane 5 era considerablemente distinta y superaba el rango para el cualel cdigo reutilizado haba sido diseado. En particular, la mayor aceleracin del Ariane5 provoc un fallo en los ordenadores de respaldo (back up) y navegacin inercialprimarios, tras lo cual toberas de la lanzadera fueron dirigidas por datos ilegtimos. Laspruebas previas al vuelo nunca fueron ejecutadas sobre el cdigo reajustado bajocondiciones de vuelo simuladas del Ariane 5, por lo tanto el error no fue descubiertoantes del lanzamiento.

Fuente: Wikipedia.com


11/338

11


Ejemplo de fallo 2: Rayos X Letales

Un gran nmero de pacientes recibieron una dosis letal de rayos gamma debido a unfallo de software.

El Therac-285 era una mquina para radiacin teraputica producida por la empresaAtomic Energy of Canada Limited.Estuvo involucrada con, al menos, seis accidentes conocidos entre 1985 y 1987, en loscuales los pacientes fueron objeto de una sobredosis masiva de radiacin, que enalgunos casos fueron del orden de centenas de gray. Al menos cinco pacientesmurieron por la sobredosis. Estos accidentes destacan los riesgos del control desoftware de sistemas crticos en trminos de seguridad (Safety Critical Systems).

Fuente: Wikipedia.com


12/338

12


Error (Error), Defecto (Defect), Fallo (Failure)

Error (Error) (IEEE 610): Accin humana que produce un resultado incorrecto, por ejemplo un error de

programacin.

Defecto (Defect) Desperfecto en un componente o sistema que pueda ser la causa por la cual el

sistema o componente no logre llevar a cabo su funcin especfica, por ejemplo;sentencia o definicin de datos incorrectas.

Fallo (Failure) Manifestacin fsica o funcional de un defecto. Si un defecto es encontrado

durante la ejecucin de una aplicacin puede producir un fallo. Desviacin de un componente o sistema respecto de la prestacin, el servicio o

resultado esperados. (Fenton).

Un error introduce un defecto, un defecto causa un fallo


13/338

13


Causas de los Fallos (Failures) de Software

Error Humano Un defecto es introducido en el cdigo de software, en los datos o en los

parmetros de configuracin. Causas del error humano

Plazos, demandas excesivas debidas a la complejidad, distracciones.

Condiciones Ambientales Cambios en las condiciones ambientales.

Causas de condiciones ambientales negativas/adversas.

Radiacin, magnetismo, campos electromagnticos, polucin, manchassolares, fallo de disco duros, fluctuaciones en el suministro de energa.


14/338

14


Proceso de Pruebas durante el proceso de desarrollo,mantenimiento y Operaciones

Mejora de la Calidad de un Producto de Software: El proceso de pruebas ayuda a proveer al software de los atributos deseados,

i.e. retirar defectos que conducen a fallos.

Reduccin del Riesgo de Detectar Errores: Actividades de Pruebas de Software adecuadas reducirn el riesgo de encontrar

errores durante la fase de operaciones de software.

Satisfacer Compromisos La ejecucin de pruebas puede ser un requisito obligatorio por parte del cliente o

debido a normas legales as como el cumplimiento de estndares propios de laindustria especfica.


15/338

15


Calidad en el Software

Definicin: Calidad en el Software (segn ISO/IEC9126)

La totalidad de las funcionalidades y caractersticas de un producto desoftware que contribuyen a su habilidad de satisfacer necesidadesespecificadas o implcitas.

Definicin: Calidad en el Software (segn IEEE 610) Grado en el cual un componente, sistema o proceso satisface los requisitos

especificados y/o necesidades del usuario/cliente y sus expectativas.


16/338

16


Calidad en el Software

De acuerdo a la norma ISO/IEC 9126 la calidad de software est constituida por: Funcionalidad Atributos funcionales de calidad

Fiabilidad

Usabilidad

Eficiencia Atributos no funcionales de calidad

Mantenibilidad

Portabilidad

Tipos de Aseguramiento de Calidad (QA): Actividades constructivas con el objeto de prevenir defectos, por ejemplo a travs de la

aplicacin de mtodos apropiados de ingeniera de software.

Actividades analticas con el objeto de detectar defectos, por ejemplo a travs de pruebasconducentes a la correccin de defectos y prevencin de fallos, incrementando as la calidad

del software.


17/338

17


Aseguramiento de la Calidad Constructivo Proceso de Calidad Gestin de la Calidad

Consigna

Los defectos evitados no

requieren ser reparados.

Los errores cometidos en elpasado no deben ser

repetidos.

Prevenir defectos.

QA

Constructivo

Guas

Estndares

Listas de ComprobacinReglas de Proceso y Normas

Requisitos Legales

Mtodos

Herramientas

Lenguajes

Listas / Plantillas

Entorno de Desarrollo, Integrado (IDE)Tcnico

Organiz

acin


18/338

18


Aseguramiento de la Calidad Analtico Calidad del Producto Procedimientos de Verificacin y Pruebas

QAAnaltico

Consigna:

Los defectos deben ser

detectados tan temprano en elproceso como sea posible.

Pruebas Estticas

Examen sin la ejecucin del

programaPruebas Dinmicas

Incluye la ejecucin delprograma.E

sttico

CajaNegra

Dinmic

o

Ca

jaBlanca

Tcnicas Basadas en la Experiencia

Clases de Equivalencia

Anlisis de Valores de lmite

Pruebas de Transicin de estado

Tablas de decisin

Algoritmo Pairwise (En parejas)

Cobertura de sentencia

Cobertura de rama

Cobertura de condicin

Cobertura de camino

Revisiones / ensayos

Anlisis del flujo de control

Anlisis del flujo de datos

Mtricas del compilador / analizador.


19/338

19


El costo de los defectos

El costo de eliminar defectos seincrementa con el tiempo durante elcual el defecto permanece en elsistema.

La deteccin de errores en etapastempranas permite la correccin delos mismos a costos reducidos.


20/338

20


Calidad Software Atributos funcionales de Calidad

Funcionalidad significa:1. Correctitud: La funcionalidad satisface los atributos/capacidades requeridos.

2. Completitud: La funcionalidad satisface todos los requisitos.

Funcionalidad incluye (ISO/IEC 9126):1. Idoneidad

2. Precisin

3. Conformidad

4. Interoperabilidad

5. Seguridad


21/338

21


Calidad Software Atributos no funcionales de Calidad

Fiabilidad: Caractersticas: Bajo ciertas condiciones el software mantiene su capacidad

por un tiempo determinado.

Fiabilidad= Calidad/tiempo

Usabilidad: Caractersticas: intuitivo, fcil de usar y de aprender.


22/338

22


Calidad Software Atributos no funcionales de Calidad

Eficiencia: Caractersticas: el sistema requiere la utilizacin de un mnimo de

recursos para ejecutar una tarea determinada.

Mantenibilidad: Caractersticas: Medida del esfuerzo requerido para realizar cambios

en un sistema.

Portabilidad: Caractersticas: Fcil de instalar y desinstalar. Parametrizable.


23/338

23

I - Fundamentos de Pruebas de Software01 Comprendiendo el Proceso de Pruebas del Software

Atributos de la calidad

Algunos atributos se influyen entre s. Debido a esta interdependencia ydependiendo del objeto de la prueba, los atributos deben ser priorizados.

Para medir cada tipo de atributo se requieren tipos diferentes de pruebas.


24/338

24


Objetivos de las pruebas

Adquirir conocimiento sobre los defectos en un objeto de prueba

Comprobar la funcionalidad

Generar informacin de riesgos

Generar confianza


25/338

25


Cuntas pruebas son suficientes?

Criterio para finalizacin de las pruebas

Pruebas basadas en riesgo: responsabilidad y probabilidad de fallos

Pruebas basadas en plazos y presupuestos: disponibilidad de recursos.


26/338

26


Caso de prueba (test case), base de una prueba (test basis)

Caso de prueba: Precondiciones.

Conjunto de valores de entrada.

Conjunto de resultados esperados.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados. Poscondiciones esperadas.

Base de la prueba: Conjunto de documentos que definen los requisitos de un componente o

sistema. Utilizado como el fundamento para el desarrollo de casos de prueba.


27/338

27


Desarrollo software y revisiones Cdigo (code), cdigo fuente (source code):

programa de computadora escrito en un lenguaje de programacin que puedeser ledo por una persona.

Depuracin (debugging):

localizacin y correccin de defectos en el cdigo fuente.

Desarrollo software (software development):es un proceso cuyo objetivo es desarrollar un sistema basado en uncomputador, normalmente sigue un modelo de desarrollo software.

Requisito (requirement):

un requisito describe un atributo funcional o no funcional deseado oconsiderado obligatorio.

Revisin (review):evaluacin de un proyecto con el fin de detectar discrepancias con respecto alos resultados esperados y para recomendar mejoras.


28/338

28


Pruebas y depuracin (debugging)

Probar y volver a probar (re-test) son actividades propias delproceso de prueba.

La depuracin y la correccin de defectos son actividades propiasdel desarrollo.

Deteccin-identificacinde defectos

Correccinde

defectos

Volver aprobar

(re-test)Prueba

Depuracin


29/338

29


Resumen: Los fallos software pueden causar importantes perjuicios.

La calidad software es la suma de los atributos que se refieren a la capacidaddel software de satisfacer un conjunto de requisitos dados.

El aseguramiento de la calidad constructivo se ocupa de la prevencin dedefectos.

El aseguramiento de la calidad analtico se ocupa de detectar y corregir

defectos. Los atributos de la calidad funcionales y no funcionales definen la calidad

total del sistema.

Cada prueba debe contar con un criterio para la finalizacin de pruebas.Al

alcanzar el criterio de finalizacin de pruebas finalizan las actividades delproceso de pruebas.

Los testers buscan fallos en el sistema e informan sobre los mismos. Losdesarrolladores buscan defectos y los corrigen.


30/338

30

I - Fundamentos de Pruebas de Software02 Principios del proceso de pruebas software

Principio 1: El proceso de pruebas demuestra la presencia dedefectos.

El proceso de pruebas puede probar la presencia de defectos.

El proceso de pruebas no puede demostrar la ausencia de defectos.


31/338

31


Principio 2: No es posible realizar pruebas exhaustivas

Pruebas exhaustivas

Explosin de casos de prueba

Prueba de muestra


32/338

32


Principio 3: pruebas tempranas (early testing)

La correccin de un defecto es menos costosa en la medida en la cual sudeteccin se realiza en fases mas tempranas del proceso de software.

La preparacin de una prueba tambin consume tiempo.


33/338

33


Principio 4: Agrupamiento de defectos (defect clustering)

Encuentre un defecto y encontrara mas defectos cerca!

Los testers deben ser flexibles


34/338

34


Principio 5: Paradoja del pesticida

Repetir pruebas en las mismas condiciones no es efectivo

Las pruebas deben ser revisadas/modificadas regularmente para losdistintos mdulos (cdigo).


35/338

35


Principio 6: Las pruebas dependen del contexto

Las pruebas se desarrollan de forma diferente en diferentes contextos.

Objetos de prueba diferentes son probados de forma diferente.

Entorno de pruebas (test bed) vs. Entorno de produccin.


36/338

36


Principio 7: La falacia de la ausencia de errores

Un proceso de pruebas adecuado detectara los fallos mas importantes.

Esto en si no prueba la calidad del sistema software.


37/338

37

I - Fundamentos de Pruebas de Software02 Principios del proceso de pruebas softwareResumen: Las pruebas pueden ayudar a detectar defectos en el software, sin embargo

las mismas no pueden demostrar la ausencia de defectos.

Salvo en casos triviales las pruebas exhaustivas son imposibles, las pruebasde muestra son necesarias.

Las pruebas tempranas ayudan a reducir costos dado que los defectosdescubiertos en fases tempranas del proceso software son corregidas con

menor esfuerzo. Los defectos se presentan agrupados,. El encontrar un defecto en una

ubicacin determinada significa que probablemente se encontrara otro defecto asu alrededor.

Repetir pruebas idnticas no genera nueva informacin.

Cada entorno partculardetermina la forma en la cual seejecutarn/desarrollarn las pruebas.

Un software libre de errores no implica que sea adecuado para el uso.


38/338

38

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico.El proceso de pruebas como proceso dentro del proceso de

desarrollo software

Dependiendo del enfoque seleccionado, el proceso de pruebas tendr lugar endiferentes puntos del proceso de desarrollo.

Las pruebas constituyen un proceso en si mismas.


39/338

39

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico.El proceso de pruebas a lo largo del proceso de desarrollo

software

Incluye superposicin y vuelta atrs

(backtracking).

Cada fase del proceso de pruebastiene lugar de forma concurrente

con las fases del proceso de

desarrollo software.

Plan de pruebas

Anlisis y diseo de

pruebas

Implementacin yejecucin de pruebas

Evaluacin del criterio desalida y generacin deinformes

Actividades de cierrede pruebas


40/338

40

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico.

Control de pruebas tareas principales

El control de pruebas es una actividad continua queinfluye en la planificacin de las pruebas.

El estado del proceso de pruebas se determina

comparando el progreso logrado con respecto al

plan de pruebas.Se miden y analizan resultados.

Elprogreso

de las pruebas, lacobertura

de las pruebas y el cumplimiento delcriterio de finalizacin de pruebas son objeto de seguimiento y sondocumentados.

Se inician medidas correctivas.

Preparary tomardecisiones.


41/338

41


Planificacin de pruebas tareas

Principales Determinar el alcance y los riesgos. Identificar los objetivos de las pruebas y el criterio

de finalizacin de pruebas.

Determinar el enfoque: tcnicas de pruebas,

cobertura de pruebas, equipo de pruebas. Implementar el mtodo/estrategia de pruebas,

planificacin del tiempo disponible para las

actividades a seguir.

Adquirir/obtener y programar recursos requeridos para las pruebas: personal,entorno de pruebas, presupuesto de pruebas.


42/338

42

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico. Estrategia de pruebas:

(1) Descripcin a alto nivel de los niveles de prueba a llevar a cabo y laspruebas asociadas a ellos para una organizacin o programa (uno o mas

proyectos). (2) De acuerdo con el enfoque global, los esfuerzos aplicados a las pruebas

se reparten entre los objetos de prueba y los diferentes objetivos de laspruebas: la eleccin del mtodo de prueba, como y cuando las actividades

asociadas a las pruebas debern ser ejecutadas y cuando se debe detenerel proceso de pruebas (criterio de finalizacin).

Criterio de salida (segn Gilb and Graham):

Conjunto de condiciones genricas y especificas, acordadas con los

implicados, para permitir que un proceso sea considerado formalmentefinalizado. El propsito de los criterios de salida es evitar que una tarea seconsidere finalizada habiendo partes destacadas de la misma sincompletar. Los criterios de salida son utilizados como fuente para elaborarinformes y planificar la suspensin de las pruebas.


43/338

43


Anlisis y diseo de pruebas tareas

principales Revisin de las bases de las pruebas (requisitos,

arquitectura del sistema, diseo, interfaces).

Identificar condiciones de prueba especificas y los

datos de prueba necesarios.

Diseos de pruebas / casos de prueba. Positivos y negativos

Anlisis de la testabilidad.


44/338

44


Anlisis y diseo de pruebas tareas

Principales

Organizacin del entorno de pruebas (test bed).

Infraestructura de pruebas y herramientas de

pruebas (si fuera necesario).

Procesos, procedimientos y responsabilidades.

Eleccin, suministro, instalacin y operacin de herramientas de pruebas.


45/338

45

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico. Plan de pruebas (test plan):

Documento que describe el alcance, enfoque, recursos y planificacin (temporal), delas actividades previstas del proceso de pruebas. Este documento incluye, pero no

esta limitado a, los objetos de prueba, las caractersticas a verificar (a probar), losrecurso y un plan de contingencias.

Datos de prueba (test data): Datos que existen en el sistema antes de que una prueba sea ejecutada, y que afecta

o es afectado por el componente o sistema sujeto a pruebas.

Datos de entrada (input data): Variable que es leda por un componente (tanto almacenada dentro del sistema como

fuera del mismo).

Cobertura de pruebas (test coverage): Grado en el cual un elemento especifico ha sido ejecutado por conjunto de pruebas,

utilizado con mayor frecuencia en pruebas de caja blanca con el objeto de determinarla cobertura del cdigo.

Orculo de pruebas (test oracle): Fuente que permite determinar los resultados esperados de un software sujeto a

pruebas: comparativas (benchmarks)(tambin resultado de pruebas previas),

manuales de usuario o conocimiento especializado. No debe ser el cdigo.


46/338

46


Ejecucin de pruebas tareas principales

Desarrollo y asignacin de un orden de

prioridad a los casos de prueba.

Creacin de guiones de automatizacin de

pruebas, si fuera necesario.

Configuracin del entorno de pruebas (test bed).

Ejecucin de pruebas (de forma manual o

automtica).

Registro y anlisis de los resultados de pruebas.

Reiteracin de pruebas (retest) / pruebas de regresin (regression testing).


47/338

47

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico. Juego de pruebas (test suit) / secuencia de pruebas (test sequence):

Conjunto de casos prueba para un componente o sistema, donde la postcondicion de un caso deprueba es utilizada como precondicin para el caso siguiente.

Especificacin de procedimiento de pruebas (escenario de pruebas): Documento en el cual se especifica una secuencia de acciones para la ejecucin de una prueba.Tambin es conocido como guion de pruebas o guion de pruebas manuales.

Ejecucin de pruebas: Es el proceso de llevar a cabo una prueba aportando/generando los resultados reales.

Registro de pruebas (informe de pruebas): Relacin cronolgica de los detalles relevantes relativa a la ejecucin de pruebas; cuando se

desarrollaron las pruebas, que resultados fueron generados

Pruebas de regresin: Pruebas, tras la modificacin de un programa previamente probado, con el objeto de asegurar que

no se han introducido o descubierto defectos en reas que no hubieran sido objeto de modificacincomo resultado de los cambios realizados. Se realizan cuando el software o su entorno a sidomodificado.

Pruebas de confirmacin, reiteracin de pruebas (retest): Repeticin de una prueba tras la correccin de un defecto con el objeto de confirmar que el defecto

ha sido eliminado con xito.


48/338

48


Evaluacin del criterio de salida tareas

principales

Evaluacin de la ejecucin de pruebas conrespecto a objetivos definidos.

Evaluacin de los registros de pruebas

(resumen de las actividades de pruebas,resultado de prueba, comunicar criterio de salida).

Proporcionar informacin con el objeto de permitir

la decisin con respecto a si tendrn lugar pruebas adicionales.


49/338

49


Actividades de cierre de pruebas

tareas principales

Recopilar datos de las actividades Cierre de informes de incidencias o generacin de

solicitudes de cambio para cualquier punto que

permaneciera abierto.

Comprobar que entregables planificados han sidoentregados.

Documentar la aceptacin del sistema.

Finalizar y archivar los utensilios de pruebas

Analizar las lecciones aprendidas para futuros proyectos.


50/338

50

I - Fundamentos de Pruebas de Software03 Proceso de pruebas bsico.Resumen:El proceso de pruebas se puede dividir en diferentes fases.

Planificacin de pruebas: abarca las actividades como la definicin de laestrategia de pruebas para todas las fases, as como la planificacin de losrecursos (tiempo, personal, maquinas).

Diseo de pruebas ( especificacin): abarca el diseo de casos de prueba ysus resultados esperados.

Ejecucin de pruebas: abarca la definicin de datos de pruebas, la ejecucinde pruebas y la comparacin de resultados.

Informes de pruebas(logging): registro de los resultados de prueba, en formade tabulada, en base de datos o de forma escrita.

Evaluacin de pruebas: abarca el anlisis de defectos y la evaluacin delcriterio de salida.

Control de pruebas: consiste en las actividades de control que abarcan todaslas fases anteriores.

I F d t d P b d S ft


51/338

51

I - Fundamentos de Pruebas de Software04 Psicologa en el proceso de pruebasRoles y responsabilidadesRol: Desarrollador Rol: Tester

- Implementa requisitos - Planifica actividades de pruebas

- Desarrolla estructuras - Disea casos de prueba

- Desarrolla el software - Su nica preocupacin es encontrar

- Crea un producto defectos

- encontrar errores producidos por undesarrollador es su xito

Percepcin

la actividad del desarrollador es la actividad del tester es destructiva!

Constructiva!

Error!

Las pruebas tambin constituyen una actividad constructiva,

su propsito es la eliminacin de defectos en un producto!



52/338

52

I - Fundamentos de Pruebas de Software04 Psicologa en el proceso de pruebasCaractersticas personales de un buen tester /1

Curioso, perceptivo, atento a los detalles.

Con el objeto de comprender los escenarios prcticos del cliente. Con el objeto de poder analizar la estructura de una prueba.

Con el objeto de descubrir donde se pueden manifestar fallos.

Escptico y con actitud critica. Los objetos de prueba contienen defectos. Usted solo debe

encontrarlos.

No se debe tener temor al hecho de que pueden ser descubiertosdefectos serios que tengan un impacto sobre la evolucin delproyecto.



53/338

53

I - Fundamentos de Pruebas de Software04 Psicologa en el proceso de pruebasCaractersticas personales de un buen tester /2

Aptitudes para la comunicacin.

Necesarias para llevar malas noticias a los desarrolladores. Necesarias para vencer estados de frustracin.

Tanto cuestiones tcnicas como prcticas. Relativas al uso delsistema. Deben ser entendidas y comunicadas.

Una comunicacin positiva puede ayudar a evitar situacionesdifciles.

Facilitan establecer una relacin de trabajo con los desarrolladoresa corto plazo.

Experiencia. Factores personales influyen en la ocurrencia de errores.

La experiencia ayuda a identificar donde se pueden acumularerrores.



54/338

54

I - Fundamentos de Pruebas de Software04 Psicologa en el proceso de pruebas

Diferencias: disear desarrollar probar

Las pruebas requieren una perspectiva distinta a la del diseo y desarrollo desistemas de software.

En principio, una persona puede asumir los tres roles en su trabajo.

I Fundamentos de Pruebas de Software


55/338

55

I - Fundamentos de Pruebas de Software04 Psicologa en el proceso de pruebas

Pruebas independientes

La separacin de las responsabilidades en el proceso depruebas apoya/promueve la evaluacin independiente de losresultados de las pruebas.



56/338

56

I - Fundamentos de Pruebas de Software

04 Psicologa en el proceso de pruebasOrganizacin de pruebas tipos /1

Pruebas del desarrollador

El desarrollador nunca analizara su creacin de forma

imparcial (apego afectivo).

Las personas tienden a pasar por alto sus propios defectos.

Errores cometidos como consecuencia de una mala interpretacin de losrequisitos se mantendrn sin ser detectados.



57/338

57



Equipos de desarrollo

Los desarrolladores hablan el mismo lenguaje.

Los costos de formacin/informacin en lo relativo a

objetos de prueba se mantienen a un nivel moderado.

Peligro de generacin de conflictos entre equipos de desarrollo.

Mezcla de actividades de desarrollo y pruebas.



58/338

58



Equipos de pruebas

La creacin de equipos de pruebas que den

servicio a diferentes reas del proyecto mejora la calidad de las pruebas.

Es importante que los equipos de pruebas de diferentes reas del proyectotrabajen de forma independiente



59/338

59



Subcontratacin (externalizacin) de pruebas

La separacin de las actividades de pruebas y desarrollo

aportan la mxima independencia entre los objetos de

prueba y el tester.

Las actividades de pruebas subcontratadas son ejecutadas por personalcon conocimiento relativamente pequeo de los objetos de prueba y de losantecedentes del proyecto.

Los expertos externos cuentan con un alto nivel de conocimiento (knowhow), del proceso de pruebas.



60/338

60


04 Psicologa en el proceso de pruebasPruebas dirigidas por objetivos

Los testers fijan sus actividades a los efectos de alcanzar losobjetivos establecidos para ellos.

Los objetivos de pruebas deberan ser establecidos de forma

clara, de lo contrario podran influir negativamente en el cursodel proyecto.



61/338

61


04 Psicologa en el proceso de pruebasDificultades /1

Incapacidad de comprensin mutua.

Especialmente en situaciones de tensin, la deteccin deerrores cometidos por alguien frecuentemente conduce a

conflictos.



62/338

62


04 Psicologa en el proceso de pruebasDificultades /2

La comunicacin entre testers y desarrolladores esinsuficiente o inexistente. Este hecho puede hacer imposible eltrabajo conjunto.

Un proceso de pruebas slido requiere la distancia apropiadacon respecto al objeto de prueba.



63/338

63


04 Psicologa en el proceso de pruebasResumen Las personas cometen errores, toda implementacin tiene defectos.

La naturaleza humana dificulta la posibilidad de hacer frente a losdefectos propios (ceguera a los errores).

Desarrollador y tester implican el encuentro de dos mundos distintos. El desarrollador constructivo algo que no estaba ah previamente es

creado.

El proceso de pruebas resulta destructivo a primera vista - se detectarandefectos!

Juntos, el desarrollo y las pruebas son constructivas en su objetivo deobtener un producto software con la menor cantidad de defectos posible.

Las pruebas independientes aumenta la calidad del proceso depruebas. En lugar de equipos de desarrolladores utilice equipos de prueba (testers),

o equipos de prueba con testers externos.

II Pruebas a lo largo del ciclo de vida software


64/338

64

g

AgendaCapitulo II Pruebas a lo largo del ciclo de vida software

II/01 Modelos de desarrollo software. II/02 Niveles de prueba del modelo V.

II/03 Tipos de prueba objetivos de las pruebas.



65/338

65


01 Modelos de desarrollo softwarePruebas a lo largo del modelo-V general El modelo-V general es el modelo de desarrollo software mas utilizado.

Desarrollo y pruebas son dos ramas iguales

Las pruebas (rama derecha), se disean en paralelo al desarrollo software (ramaizquierda).

Definicin de

requisitos

Diseo funcionaldel sistema

Diseo tcnico

del sistema

Especificacinde componentes

Programacin

Prueba decomponente

Prueba de

Integracin

Pruebas desistema

Pruebas de

aceptacin



66/338

66

g

01 Modelos de desarrollo softwarePruebas a lo largo del modelo-V general

Rama: desarrollo software.

Definicin de requisitos. Documentos de especificacin.

Diseo funcional del sistema. Diseo del flujo funcional del programa.

Diseo tcnico del sistema. Definicin de arquitectura / interfaces.

Especificacin de los componentes. Estructura de los componentes.

Programacin. Creacin de cdigo ejecutable

Definicin derequisitos

Diseo funcionaldel sistema

Diseo tcnicodel sistema

Especificacinde componentes

Programacin



67/338

67

g

01 Modelos de desarrollo softwarePruebas a lo largo del modelo-V general

Rama: pruebas de software.

Pruebas de aceptacin. Pruebas formales de los requisitos del cliente.

Pruebas de sistema. Sistema integrado, especificaciones.

Pruebas de integracin. Interfaces de componentes.

Pruebas de componente. Funcionalidad del componente.

Programacin

Prueba decomponente

Prueba deIntegracin

Pruebas desistema

Pruebas deaceptacin



68/338

68

g

01 Modelos de desarrollo software

Verificacin vs. Validacin

Verificacin Comprobacin de la conformidad con los requisitos establecidos (definicin

segn ISO 9000).

Cuestin clave: se ha procedido correctamente en la construccin delsistema?

Validacin Comprobacin de la idoneidad para el uso esperado (definicin segn ISO

9000).

Cuestin clave: Hemos construido el sistema software correcto?



69/338

69

g

01 Modelos de desarrollo softwareVerificacin dentro del modelo-V general Cada nivel de desarrollo se verifica respecto de los contenidos del nivel que le

precede.

Verificar significa comprobar si los requisitos y definiciones de niveles previos hansido implementados correctamente.


Diseo funcional delsistema

Diseo tcnico delsistema

Especificacin decomponentes

Programacin

Prueba decomponente

Prueba de Integracin

Pruebas de sistema

Pruebas deaceptacin

Verificacin

Desarrollo eintegracin



70/338

70

01 Modelos de desarrollo softwareValidacin dentro del modelo-V general La validacin se refiere a la correctitud de cada nivel de desarrollo.

Validar significa comprobar lo adecuado de los resultados de un nivel dedesarrollo.


Diseo funcional delsistema

Diseo tcnico delsistema

Especificacin decomponentes

Programacin

Prueba decomponente

Prueba de Integracin

Pruebas de sistema

Pruebas deaceptacin

Verificacin

Desarrollo e

integracinValidacin



71/338

71

01 Modelos de desarrollo softwareTesting within the W-model The W-model can be see as an extension to the general V-model.

The W-model makes it clear, that certain quality assurance activities shall be

performed in parallel with the development process.

Programming

Planningcomponent

test

Execution ofcomponent

test

Debugging anderror correction

Componentspecification

Func.technicaldesign

Planningintegration test

Planningsystems test

Func. systemdesign

Functional

requirements

Planning test

activities

Execution ofintegration test



Execution ofsystems test

Execution ofacceptance

test




72/338

72

01 Modelos de desarrollo softwareOtros modelos de prueba: modelos iterativos /1 Desarrollo software iterativo.

Las actividades: definicin de requisitos, diseo, desarrollo y pruebas se segmentan en

pasos reducidos y se ejecutan de forma continua. Se debe alcanzar el consentimiento con el cliente tras cada iteracin con el objeto de

modificar el rumbo del proyecto si fuera necesario.

Ejemplos de modelos iterativos: Modelo prototipado: desarrollo rpido de una representacin del sistema que pudiera

ser objeto de uso, seguida de modificaciones sucesivas hasta que el sistema seafinalizado.

Desarrollo rpido de aplicaciones (rapid aplication developmen - RAD): la interfaz deusuario se implementa utilizando una funcionalidad hecha (out of the box), simulando lafuncionalidad que posteriormente ser desarrollada.

Proceso unificado (rational unified process RUP): modelo orientado a objeto yproducto de la compaa rational / IBM. Principalmente aporta el lenguaje de modelo UMLy soporte al proceso unificado.

Programacin extrema (extreme programming XP): el desarrollo y las pruebastienen lugar sin una especificacin de requisitos formalizada.



73/338

73

01 Modelos de desarrollo softwareOtros modelos de prueba: modelos iterativos /2 Caractersticas de los modelos iterativos:

Cada iteracin contribuye con una caracterstica adicional del sistema bajodesarrollo.

Cada iteracin puede ser probada por separado.

Las pruebas de regresin son de gran relevancia.

En cada iteracin, la verificacin (relacin con el nivel precedente), y lavalidacin (grado de correccin del producto dentro del nivel actual), se

pueden efectuar por separado.

II Pruebas a lo largo del ciclo de vida Software


74/338

74

01 Modelos de Desarrollo de Software

Principios de todos los modelos

Cada actividad de desarrollo debe ser probada.

Cada nivel de pruebas debera ser probado de formaespecfica.

El proceso de pruebas comienza con mucha antelacin a la

ejecucin de pruebas.



75/338

75

01 Modelos de Desarrollo de SoftwareResumen

El desarrollo de software utiliza modelos tanto para el propiodesarrollo de software como para las actividades del proceso depruebas.

El modelo ms conocido es el modelo-V, el cual describe los nivelesde desarrollo y niveles de prueba como dos ramas relacionadas.

Los modelos iterativos ms relevantes son RUP y XP.

Las actividades de pruebas estn recomendadas en todos losniveles de desarrollo.



76/338

76

02 Niveles en el Proceso de Pruebas

Definicin Pruebas de componente

Pruebas de cada componente tras su realizacin

Dadas las convenciones de cada lenguaje deprogramacin para la asignacin de nombres asus respectivas componentes, se podr hacerreferencia a un componente como: Pruebas de mdulo (module test) (por ejemplo en

C)

Prueba de clase (por ejemplo en Java o C++) Prueba de unidad (por ejemplo en Pascal)

Programacin

Pruebas deComponentes

Pruebas deIntegracin

Pruebas deSistema

Pruebas deAceptacin



77/338

77


Pruebas de Componente: Alcance Slo se prueban componentes individuales.

Un componente puede estar constituido por un conjunto de unidades mspequeas

Los objetos de prueba no siempre pueden ser probados en solitario (deforma autnoma).

Cada componente es probado de forma independiente Describiendo defectos internos.

Los efectos cruzados entre componentes quedan fuera del alcance deestas pruebas



78/338

78


Pruebas de Componente: Motivacin

Probar la funcionalidad. Toda funcionalidad debe ser probada, por lo menos., con un caso deprueba.

Defectos descubiertos habitualmente:

Probar la robustez (testing robustness)(resistencia a datos de entrada invlidos) Los casos de prueba que comprueban datos de entrada invlidos se

denominan pruebas negativas.

Un sistema robusto aporta un tratamiento apropiado para datos deentrada errneos.



79/338

79


Pruebas de Componente: Arns de Pruebas La ejecucin de pruebas de componente requiere,

frecuentemente, de drivers y stubs. Un driver procesa la interfaz de un componente.

Un stub reemplaza o simula un componente que an no

se encuentra disponible.

Driver Componente Datosde

Prueba

Stub



80/338

80


Pruebas de Componente: Mtodos

El cdigo fuente se encuentra disponible para eltester

Tester = desarrollador

Se podr aplicar al diseo de casos de prueba el conocimiento de lafuncionalidad, estructura de componentes y variables.

Las pruebas funcionales sern pertinentes (con frecuencia).

Adicionalmente, el uso de depuradores (debuggers) y otras herramientas

de desarrollo permitirn acceso directo a las variables del programa.



81/338

81


Resumen: Pruebas de Componente

Un componente es la unidad ms pequea especificada de un sistema.

Prueba de mdulo, de clase, de unidad y de desarrolladorson los utilizadoscomo sinnimos.

Los drivers ejecutarn las funciones de un componente y las funcionesadyacentes que son reemplazadas por stubs.

Las pruebas de componente podrn comprobar caractersticas funcionales yno funcionales de un sistema.



82/338

82


Definicin Pruebas de Integracin (tambin: Pruebas

de Interfaz) Comprueba la interaccin entre elementos

de software (componentes) tras laintegracin del sistema.

La integracin es la actividad en la cual secombinan componentes de softwareindividuales en subsistemas ms amplios.

La integracin adicional de subsistemastambin es parte del proceso de integracindel sistema

Programacin



Pruebas deSistema

Pruebas deAceptacin



83/338

83

02 Niveles en el Proceso de Pruebas Pruebas de Integracin: Alcance /1

Las pruebas de integracin asumen que los componentes ya hansido probados.

Las pruebas de integracin comprueban la interaccin mutuaentre componentes (subsistemas) software:

Las pruebas de integracin comprueban las interfaces con elentorno del sistema.



84/338

84


Ser probado un (subsistema) sistema compuesto de componentesindividuales.

Son necesario drivers de prueba (los cuales aportan el entorno alproceso del sistema o subsistema)

Los drivers de prueba propios de las pruebas de componente pueden serreutilizadas aqu.



85/338

85


Herramientas de control (monitoring tools) pueden apoyar lasactividades de pruebas registrando datos y controlando las mismaspruebas.

Un stub reemplaza un componente faltante. Un stub programado reemplazar datos o funcionalidad de un

componente que an no ha sido integrado

Un stub asumir las tareas elementales de un componente faltante.



86/338

86


Pruebas de Integracin: Enfoque

El propsito de las pruebas de integracin es detectar defectos enlas interfaces. Las pruebas de integracin comprueban la correctainteraccin entre componentes.

Al reemplazar drivers y stubs de prueba por componentesreales se pueden generar nuevos defectos tales como:

Prdida de datos, manipulacin errnea de datos o entradaserrneas.

El componente involucrado interpreta los datos de entrada deuna manera distinta. Los datos son transferidos en un momento incorrecto: antes

de tiempo, despus de tiempo, a una frecuencia distinta de larequerida.



87/338

87

02 Niveles en el Proceso de Pruebas Pruebas de Integracin: Estrategias /1

Hay diferentes estrategias para las pruebas de integracin Enfoque incremental es un elemento comn a la mayora de las

estrategias (excepcin: estrategia Big Bang). Las estrategias ascendente (bottom - up) y descendente (top-

down) son las utilizadas con mayor frecuencia.

La eleccin de la estrategia debe considerar tambin aquellos

aspectos relativos a la eficiencia de las pruebas.

En cada proyecto especfico se debe considerar el compromisoentre la reduccin de tiempo y la reduccin esfuerzo en pruebas



88/338

88

02 Niveles en el Proceso de Pruebas Pruebas de Integracin: Estrategias /2

Pruebas

Integracin

Ascendente (bottom-up)

Pruebas

Integracin

Descendente (top-down)

Pruebas

Integracin

Big Bang

II Pruebas a lo largo del ciclo de vida Software02 Niveles en el Proceso de Pruebas


89/338

89

Resumen: Pruebas de Integracin

Integracin significa construir grupos de componentes.

Las pruebas de integracin comprueban la interaccin entre componentesrespecto de la especificacin de interfaces.

La integracin ocurre de forma ascendente (bottom-up), descendente(top-down) o en forma de Big Bang.

Integracin de subsistemas (estn constituidos por componentes integrados)

tambin es una forma de integracin.

Cualquier estrategia de integracin distinta a las anteriores es integracin adhoc.



90/338

90

Definicin Pruebas de Sistema

Pruebas del sistema de software integrado.

Las pruebas de sistema se refieren a (segn ISO 9126): Requisitos Funcionales.

Funcionalidad. Requisitos no funcionales.

Fiabilidad.

Usabilidad.

Eficiencia. Modificabilidad.

Portabilidad.

Programacin



Pruebas deSistema

Pruebas deAceptacin



91/338

91

Pruebas de Sistema: Alcance

Prueba de un sistema integrado desde el punto de vista del usuario. Implementacin completa y correcta de los requisitos.

Despliegue en el entorno real del sistema con datos recientes.

El entorno de pruebas debera coincidir con el entorno real. No son necesarios stubs o drivers.

Todas las interfaces externas son probadas en condiciones reales.

Emulacin prxima al futuro entorno real del sistema.



92/338

92

Pruebas de Sistema: Requisitos Funcionales/1

Objetivo: comprobar que la funcionalidad implementada expone las

caractersticas requeridas. Las caractersticas a ser probadas incluyen (segn ISO 9126):

Adecuacin/idoneidad (suitability) Las funciones implementadas son adecuadas para su uso esperado?

Exactitud (accuracy) Las funciones presentan los resultados correctos (acordados)?

Interoperatibilidad (interoperability) Las interacciones con el entorno del sistema presentan algn problema?

Conformidad (compliance) El sistema cumple con normas y reglamentos aplicables?

Seguridad (security) Estn protegidos los datos/programas contra acceso no deseado o prdida?



93/338

93

Pruebas de Sistema: Requisitos Funcionales/2 Tres enfoques para probar requisitos funcionales:

Pruebas basadas en requisitos. Los casos de prueba se derivan de la especificacin de requisitos.

El nmero de casos de prueba variar en funcin del tipo/profundidad de laspruebas basadas en la especificacin de requisitos.

Pruebas basadas en procesos de negocio Cada proceso de negocio sirve como fuente para derivar/generar pruebas.

El orden de relevancia de los procesos de negocio pueden ser aplicados paraasignar prioridades a los casos de prueba.

Pruebas basadas en casos de uso: Los casos de prueba se derivan/generan a partir de las secuencias de usos

esperados o razonables.

Las secuencias utilizadas con mayor frecuencia reciben una prioridad ms alta.



94/338

94

Pruebas de Sistema: Requisitos NoFuncionales

La conformidad con requisitos no funcionales es difcil delograr:

Ejemplo: Prueba de mantenibilidad Los programadores han cumplido con los estndares de

codificacin respectivos?

El sistema ha sido diseado de una forma estructurada ymodular?



95/338

95

Resumen: Pruebas de Sistema

Las pruebas de sistema se desarrollan utilizando casos de prueba funcionalesy no funcionales.

Las pruebas de sistema funcionales confirman que los requisitos para un usoespecfico previsto han sido satisfechos (validacin).

Las pruebas de sistema no funcionales verifican los atributos de calidad nofuncionales, por ejemplo usabilidad, eficiencia, portabilidad, etc.

Con frecuencia, los atributos de calidad no funcionales son una parte implcitade los requisitos, esto hace difcil validarlos.



96/338

96

DefinicinPruebas de Aceptacin. Las pruebas de aceptacin son pruebas formales

llevadas a cabo con el objeto de verificar laconformidad del sistema con los requisitos. Elobjetivo es aportar justificacin a la confianza en

el sistema para que pueda ser aceptado por elcliente (ver IEEE610).

Es habitual que sean las primeras pruebas en lascuales se vea involucrado el cliente (es

recomendable involucrar al cliente durante elmismo proceso de desarrollo, por ejemplo darsoporte al desarrollo de prototipos). Programacin



Pruebas deSistema

Pruebas de

Aceptacin



97/338

97

Pruebas de Aceptacin: Aceptacin Contractual

El software satisface todos los requisitos contractuales? Con la aceptacin formal se cumplen hitos legales: comienzo de fase

de garanta, hitos de abono (pago), acuerdos de mantenimiento, etc.

Criterios de aceptacin verificables definidos en el momento delacuerdo contractual constituyen una garanta para ambas partes

Normalmente el cliente selecciona casos de prueba para las pruebasde aceptacin. Es posible que surjan malas interpretaciones con respecto a los

requisitos y pueden ser discutidos, El cliente conoce su negocio.

Las pruebas se realizan utilizado el entorno del cliente.



98/338

98

Pruebas de Aceptacin: Pruebas de aceptacinoperativas

Requiere que el software sea adecuado para su uso en un entornooperativo. Integracin del software en la infraestructura TI del cliente (copias de

seguridad/restauracin de sistemas, reinicio, instalacin, capacidad de serdesinstalado, recuperacin en caso de desastres, etc.).

Gestin de usuarios, interaccin con ficheros y estructuras de directorios enuso.

Compatibilidad con otros sistemas (otros ordenadores, servidores de basesde datos, etc.).

Con frecuencia, las pruebas de aceptacin operativas son realizadaspor el administrador de sistemas del cliente.



99/338

99

Pruebas de Aceptacin: Pruebas Alpha y PruebasBeta

Una versin preliminar y estable del software (versin beta) seentrega a un conjunto especfico (seleccionado) de clientes. El cliente ejecuta las pruebas en dependencias propias (pruebas beta,

tambin denominadas pruebas de campo), los problemas son registrados einformados a los desarrolladores para su correccin.

Previo a las pruebas beta el cliente pueden probar el nuevosoftware en las dependencias del desarrollo. Las pruebas alpha se desarrollan en las dependencias de la organizacin

que desarrolla.



100/338

100

Resumen: Pruebas de Aceptacin

Las pruebas de aceptacin son las pruebas de sistema por parte del cliente.

La prueba de aceptacin es una actividad de carcter contractual, se verificarentonces que el software satisface los requisitos del cliente.

Las pruebas alpha y beta son pruebas ejecutadas por clientes reales opotenciales, en las dependencias del desarrollador (alpha) o en lasdependencias del cliente (beta).

II Pruebas a lo largo del ciclo de vida Software03 Tipos de Pruebas: Objetivos del Proceso de Pruebas


101/338

101

Tipos de pruebas y niveles de pruebas Niveles en el proceso de pruebas.

En la seccin previa se han explicado los distintos niveles de pruebas,

es decir, pruebas de componente, pruebas de integracin, etc. En cada nivel de prueba los objetivos de las pruebas tienen un foco

diferente! Por lo tanto, se aplican distintos tipos de pruebas durante los distintos

niveles de pruebas.

Tipos de pruebas Pruebas funcionales (Objetivo: probar la funcin). Pruebas no funcionales (Objetivo: probar las caractersticas del

producto).

Pruebas estructurales (Objetivo: probar la estructura/arquitecturasoftware). Pruebas de confirmacin/regresin (Objetivo: probar despus de

cambios.)



102/338

102

Pruebas Funcionales

Objetivo: la funcin del objeto de prueba. La funcionalidad puede ser vinculada a los datos de entrada y salida de un

objeto de prueba. Los mtodos de caja negra (black box) se utilizan en el diseo de caso de

prueba relevantes.

Las pruebas se desarrollan teniendo en cuenta los requisitos funcionales (establecidos en las especificaciones, conceptos, casos de estudio, reglas de

negocio o documentos relacionados). mbito de Aplicacin

Las pruebas funcionales se pueden llevar a cabo en todos los niveles de prueba.

Ejecucin. El objeto de prueba es ejecutado utilizando combinaciones de datos de prueba

derivados/generados a partir de los casos de prueba.

Los resultados de la ejecucin de la prueba son comparados con los resultadosesperados.


P b N F i l


103/338

103

Pruebas No Funcionales

Objetivo: la funcin del objeto de prueba. De qu forma el software lleva a cabo la funcin? Las caractersticas de calidad no funcionales (ISO 9126: fiabilidad, usabilidad, eficiencia,

mantenibilidad, portabilidad) a menudo son vagas, incompletas o inexistentes, dificultandolas pruebas asociadas a las mismas.

mbito de Aplicacin Las pruebas no funcionales se pueden llevar a cabo en todos los niveles Pruebas no funcionales tpicas:

Pruebas de carga (load testing) / Pruebas de rendimiento (Performance Testing) / Pruebasde volumen (Volumen Testing) / Pruebas de Estrs (Stress Testing).

Pruebas de las caractersticas de seguridad para el software (Testing of Security Features) /Pruebas de las caractersticas de seguridad de software (Testing of Safety Features)

Pruebas de estabilidad y robustez (Stability and Robustness Testing) / Pruebas deCompatibilidad (Compatibility Testing).

Pruebas de usabilidad (Usability Testing) / Pruebas de Configuracin (ConfigurationTesting).

Ejecucin La conformidad con los requisitos no funcionales se miden utilizando requisitos

funcionales (seleccionados).


P b N F i l (P b d Si t )


104/338

104

Pruebas No Funcionales (Pruebas de Sistema)

Prueba de Carga (Load Test) Sistema bajo carga (carga mnima, ms usuarios/transacciones).

Prueba de Rendimiento (Performance Test) Rapidez con la cual un sistema ejecuta una determinada funcin.

Prueba de Volumen (Volume Test) Procesamiento de grandes cantidades de datos / ficheros.

Prueba de estrs (stress test) Reaccin a la sobrecarga / recuperacin tras el retorno a una carga normal.

Prueba de estabilidad (stability test) Rendimiento en modo de operacin continua

Prueba de Robustez (test for robustness) Reaccin a entradas errneas o datos no especificados.

Reaccin a fallos hardware / recuperacin ante situaciones de desastre.


Pruebas No Funcionales


105/338

105

Pruebas No Funcionales Pruebas de Seguridad para el Software (de datos) (test for (data)

security) Proteccin contra accesos no autorizados. Proteccin contra el robo y dao de datos.

Pruebas de compatibilidad (conversin de datos) (compatibility test (dataconversion)). Cumplimiento de normas y reglamentos (internos / externos). Reaccin a distintos entornos (H/W, O/S, etc.)

Pruebas de usabilidad (test for usability) Estructurado, comprensible, fcil de aprender para el usuario. Otros aspectos no funcionales de la calidad:

Portabilidad (portability): capacidad de reemplazar (replaceability), capacidadde ser instalado (installability), conformidad/cumplimiento(conformance/compliance), adaptabilidad (adaptability).

Mantenibilidad (maintainability): verificabilidad (verifiability), estabilidad(stability), analizabilidad (analyzability); capacidad de ser modificado(changeability).

Fiabilidad (Reliability): madurez (matury), robustez (robustness), capacidadde ser recuperado (recoverability).


P b E t t l


106/338

106

Pruebas Estructurales

Objetivo: cobertura Anlisis de la estructura de un objeto de prueba (enfoque: caja blanca).

La finalidad de las pruebas es medir el grado en el cual la estructura del objetode prueba ha sido cubierto por los casos de prueba.

mbito de aplicacin. Las pruebas estructurales son posibles en todos los niveles de pruebas, se

realizan de forma conjunta a las pruebas de componente y de integracin

mediante el uso de herramientas. El diseo de pruebas estructurales se finaliza tras haber sido diseados las

pruebas funcionales, con el propsito de obtener un alto grado de cobertura.

Ejecucin.

Se probar la estructura interna de un objeto de prueba (por ejemplo el controlde flujo en el interior de un componente, el flujo a travs de la estructura de unmen).

Objetivo: todos los elementos estructurales identificados debern estar cubiertospor casos de prueba.


Pruebas de confirmacin/regresin/1


107/338

107

Pruebas de confirmacin/regresin/1 Objetivo: objeto de pruebas despus de cambios.

Despus de que un objeto de pruebas o el entorno de sus sistema ha sidoobjeto de modificacin todos los resultados de pruebas resultan invlidos, por loque las pruebas deben ser repetidas. Repetir una prueba de funcionalidad queha sido verificada previamente se denomina prueba de regresin.

Es necesario volver a probar (retest) zonas adyacentes debido a efectoscolaterales no deseados de una funcionalidad extendida o nueva.

El alcance de las pruebas de regresin depende del riesgo que la nueva

funcionalidad implementada (extensin o correccin de errores) impone alsistema.

mbito de aplicacin. Las pruebas de confirmacin/regresin pueden ser realizadas en todos los

niveles.

Las pruebas tpicas tras una modificacin son las siguientes: Pruebas de confirmacin (retest) (= pruebas despus de la correccin de

errores). Pruebas de regresin (= pruebas para descubrir nuevos defectos

introducidos en funcionalidad previamente sin fallos).


Pruebas de confirmacin/regresin/2


108/338

108

Pruebas de confirmacin/regresin/2 Ejecucin

Bsicamente la ejecucin tiene lugar de la misma forma en la cual se hanejecutado las pruebas en iteraciones previas.

En la mayora de los casos, una prueba de regresin completa no es viabledado sus altos costos y duracin.

Un alto grado de modularidad en el software permite reducirlas pruebas deregresin.

Criterios para la seleccin de casos de prueba de regresin: Casos de prueba de prioridad alta. Probar solamente la funcionalidad estndar, saltarse casos y variaciones

especiales Probar solamente la configuracin utilizada con mayor frecuencia. Probar solamente subsistemas / zonas seleccionadas del objeto de

pruebas. Si durante fases tempranas del proyecto resulta evidente que ciertas pruebas

son adecuadas para las pruebas de regresin, se deber considerar laautomatizacin de estas pruebas.


Resumen


109/338

109

Resumen En niveles de pruebas distintos se utilizan tipos de pruebas distintos. Los tipos de pruebas son: funcionales, no funcionales,

estructurales y pruebas relacionadas a cambios. Las pruebas funcionales comprueban el comportamiento entrada /

salida de un objeto de pruebas. Las pruebas no funcionales comprueban las caractersticas de un

producto. Las pruebas no funcionales incluyen, pero no estn limitadas a,pruebas de carga, pruebas de estrs, pruebas de rendimiento,pruebas de robustez.

Las pruebas estructurales habituales son pruebas que comprueban

el flujo de control y datos midiendo la cobertura en el objeto de prueba. Pruebas importantes despus de un cambio: pruebas de

confirmacin (confirmation tests or retests) y pruebas deregresin (regression tests).

II Pruebas a lo largo del ciclo de vida Software04 Pruebas de Mantenimiento

Pruebas tras aceptacin del producto/1


110/338

110

Pruebas tras aceptacin del producto/1 El cliente ha aprobado el producto y es puesto en produccin.

El ciclo de desarrollo inicial, incluidas las pruebas asociadas, ha sido

completado. El mismo software se encuentra al comienzo del ciclo de vida:

Ser utilizado por muchos aos, ser ampliado.

Es muy probable que an contenga defectos, por lo tanto ser

modificado y corregido. Necesitar adaptarse a nuevas condiciones y deber integrarse a

nuevos entornos.

Cualquier nueva versin del producto, cada nueva actualizacin ycada nueva actualizacin y cada cambio del software requiere pruebasadicionales!




111/338

111

Pruebas tras aceptacin del producto/2 Pruebas de software modificado.

Pruebas de regresin (regression testing) Las pruebas de regresin consisten en la repeticin de pruebas

despus de una modificacin (por ejemplo la correccin de un defecto)con el objeto de comprobar que no se han introducido o descubierto

defectos enmascarados como resultado de la modificacin.

Nota: Las pruebas de regresin son necesarias y realizadas tambin antes

de que tenga lugar la aceptacin del producto. Las pruebas de regresin se realizan siempre que el software o su

entorno haya sido modificados.




112/338

112

Pruebas tras aceptacin del producto/3 El alcance de las pruebas de regresin puede variar en funcin de las

circunstancias (condiciones de entorno):

Prueba de confirmacin (retest): Repeticin de los casos de prueba que han detectado un defecto con

el objeto de comprobar que ha sido corregido.

Prueba de una funcionalidad modificada: Prueba de todas la partes del software que han sido objeto del cambio.

Prueba de nueva funcionalidad: Se prueba solamente el nuevo componente del sistema. El nuevo

componente ha sido probado durante las pruebas de componente. Prueba completa de regresin:

Se ejecuta/repite una prueba completa del sistema.

III Tcnicas estticas00 Agenda

Captulo III Tcnicas estticas de pruebas


113/338

113

Captulo III Tcnicas estticas de pruebas

III/01 Revisiones y el proceso de pruebas.

III/02 Anlisis esttico basado en herramientas.

III Tcnicas estticas01 Revisiones y el proceso de pruebas

Enfoque bsico


114/338

114

Enfoque bsico Las tcnicas estticas de pruebas comprenden varios mtodos que no ejecutan

el componente o sistema objeto de la prueba.

Las pruebas estticas incluyen:

Revisiones (reviews) (actividad manual)

Anlisis Esttico (static analysis) (actividad basada en herramientas).

Las tcnicas estticas complementan las mtodos dinmicos.

Documentos de alta calidad no conducen necesariamente a productos de alta

calidad.


Objetivos de las revisiones


115/338

115

Objetivos de las revisiones

Las revisiones se realizan con el objeto de mejorar la calidad del producto.

La deteccin temprana de errores ahorra costos.

En el transcurso de las revisiones se podran detectar los siguientes defectos:

Defectos en las especificaciones.

Defectos en el diseo y arquitectura del software.

Desviaciones con respecto a estndares acordados (por ejemplo guas deprogramacin).

Defectos en las especificaciones de interfaces.

Mantenibilidad insuficiente.


Ventajas y desventajas de las revisiones /1


116/338

116

Ventajas y desventajas de las revisiones /1 Ventajas:

Costos bajos y un potencial de ahorro relativamente alto.

Defectos en la documentacin son detectados y corregidos temprano Los documentos de alta calidad mejoran el proceso de desarrollo.

Mejora el ndice de comunicacin / intercambio de conocimiento (know - how)

Desventajas:

Se podran presentar situaciones de tensin en el caso de enfrentamientosdirectos con el autor.

Los expertos involucrados en las revisiones deben adquirir conocimientosespecficos del producto, es necesario una buena preparacin.

Inversin considerable de tiempo (del 10% - 15% del presupuesto total). Moderador y participantes influyen directamente en la calidad de la revisin


Fases de una revisin


117/338

117

ases de u a e s

Fase de planificacin.

Preparacin de la organizacin e inicio (kick off).

Preparacin individual.

Reunin de revisin.

Reprocesos

Seguimiento (follow up)


Roles y responsabilidades


118/338

118

y p

Director Responsable Jefe de Proyectos

Inicia la revisin, decide respecto de los participantes y asigna recursos.

Moderador

Dirige la reunin / discucin, hace de mediador, concluye resultados.

Autor.

Expone su trabajo a la crtica, lleva a cabo los cambios recomendados. Evaluador (Tambin: Inspector o revisor).

Detecta defectos, desviaciones, reas problemticas, etc.

Secretario (Tambin: Escriba-Escribano)

Documenta todos los asuntos, problemas y puntos que hubieran sidoidentificados.


Tipos de revisiones (IEEE 1028) /1


119/338

119

p ( )

El proceso bsico de una revisin como se esquematiza aqu se aplica a las

siguientes variaciones de las revisiones Inspeccin, Walkthrough, revisin tcnica, revisin informal

Una diferencia adicional de las revisiones se presenta dependiendo de la

naturaleza del objeto de la revisin.1. Proceso de desarrollo de sw o proceso del proyecto

2. Documentos / productos del proceso de desarrollo.




120/338

120

Inspeccin: caracteristicas relevantes

Proceso formal basado en reglas, uso de roles definidos Los evaluadores inspeccionan el objeto de revisin utilizando listas decomprobacin y mtricas.

Un moderador capacitado (formacin especfica) e independiente dirige la

revisin. La viabilidad de la revisin del objeto es valorada de forma previa a la revisin.

Proceso formal para las actividades de preparacin, ejecucin, documentaciny seguimiento.




121/338

121

Inspeccin: ventajas y desventajas

Sesiones formales y organizadas con roles claramente definidos.

Requiere actividades instensivas de preparacin y seguimiento.

Son necesarios el moderador y el secretario (alguien que toma nota).

Propsito principal: deteccin de defectos utilizando un mtodo estructurado.




122/338

122

( )

Walkthrough: caractersticas relevantes.

Opcionalmente puede haber una preparacin de los evaluadores previa a lareunin.

La reunin es dirigida por el autor, que explica el objeto en revisin.

No es necesario un moderador distinto (el autor modera). A lo largo de la presentacin por parte del autor, los evaluadores tratan delocalizar desviaciones y/o reas que representen un problema.




123/338

123

Walkthrough: ventajas y desventajas.

Esfuerzo reducido en la preparacin de la sesin de revisin, pero es unasesin cuyo resultado queda abierto.

Una sesin puede ser iniciada a travs de notificaciones relizadas con poca

antelacin. El autor tiene una gran influencia sobre el resultado: dado que l mismomodera la revisin, hay un riesgo de dominacin por su parte (puntos crticos noabordados en profundidad).

Posibilidad limitada de control, dado que el autor tambin se encuentra a cargode calquier actividad de seguimiento.




124/338

124

Revisin tcnica: caractersticas relevantes.

La meta del exmen es un aspecto tcnico del objeto de revisin: es apto parael uso?.

Son necesarios expertos, preferiblemente externos.

La reunin puede tener lugar sin la presencia del autor. La revisin se realiza utilizando especifiaciones tcnicas y otros documentos.

El panel de expertos presenta sus recomendaciones con carcter unnime.

Son necesarios preparativos intensivos.




125/338

125

Revisiones informales: caracatersticas relevantes

Es la forma de revisin ms simple.

Frecuentemente iniciada por el autor.

Solamente estarn involucrados evaluadores (uno o ms).

No es necesaria ninguna reunin.

Los resultados pueden o no ser registrados.

Frecuentemente desarrolladas a travs de la solicitud de revisin de undocumento a un compaero de trabajo.




126/338

126

Revisiones informales: ventajas y desventajas

Fcil de ejectuar, incluso en los casos de notificaciones relizadas con pocaantelacin.

Barata

No requiere protocolo.


Factores de xito de una revisin


127/338

127

Las revisiones se deben desarrollarorientadas al logro de los objetivos, es

decir, las desviaciones en el objeto revisado deben ser establecidas de formaimparcial.

El autor del objeto revisado deber ser motivado de una forma positiva por larevisin (Su documento ser an mejor en lugar de su documento es de bajacalidad).

Uso sistemtico (entre otras) de las tcnicas y plantillas implantadas.

Para la ejecucin apropiada de las revisiones ser necesario un presupuestosuficiente (10% al 15% del costo total del desarrollo).

Hacer uso del efecto de las lecciones aprendidas, utilizar la retroalimentacin para

implementar un proceso de mejora continua. Duracin de una reunin de revisin: 2 horas mximo.


Resumen


128/338

128

En el transcurso de las pruebas estticas no se ejecuta el objeto de prueba.

Las revsiones pueden tener lugar en fases tempranas del proceso de desarrollo,ellas complementan / extienden los mtodos de pruebas dinmicas.

Fases de una Revisin:

Planificacin Preparacin (Preparacin Individual) Reunin de revisin

Reprocesos - Seguimiento. Roles y Tareas para una Revisin:

Director Moderador Autor Evaluador Secretario (Toma Nota)

Tipos de Revisiones:

Inspeccin - Walkthrough - Revisin Tcnica Revisin Informal.

III Tcnicas estticas02 Anlisis esttico mediante herramientas.

Terminologa y definiciones


129/338

129

Anlisis esttico (definicin):

Es aquella actividad que consiste en el anlisis de un objeto de prueba (porejemplo cdigo fuente o script), llevado a cabo sin ejecutar el producto software.

Posibles aspectos a ser comprobados con anlisis esttico:

Reglas y estndares de programacin. Diseo de un programa (analisis del flujo de control).

Uso de datos (anlisis del flujo de datos)

Complejidad de la estructura de un programa.

Mtricas, (por ejemplo nmero ciclomtico).

III Tcnicas estticas02 Anlisis esttico mediante herramientas.

Aspectos generales /1


130/338

130

Todos

Capacitación de Estudio ISTQB

Documents

Transcript of Capacitación de Estudio ISTQB