Curso ISTQB Español

8/21/2019 Curso ISTQB Espaol

1/417


2/417

2 de 418

Foundation Level Syllabus (2010)Traduccin por Norman Burbano. [email protected]

0Introduccin

01Presentacin

Organizacin del curso

Agenda del curso.

Por favor mantenga su celular apagado.


3/417

3 de 418


0 - Introduccin

02 - Tabla de contenidos

El presente curso se ha desarrollado de acuerdo con el programa de estudios del ao 2010 deProbador, Certificado Nivel Bsico, que consta de siete captulos:

Captulo 0 Introduccin.Captulo I Fundamentos de Pruebas.

Captulo II Pruebas a travs del Ciclo de Vida Software.Captulo III Tcnicas Estticas.Captulo IV Tcnicas de Diseo de Pruebas.Captulo V Gestin de Pruebas.Captulo VI Herramientas de Pruebas.


4/417

4 de 418


0 - Introduccin

03 - 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 software son formulados en el programa de

estudios para el nivel bsico (Syllabus for Foundation Level - edicin actual: marzo de2010).

Desde 2004 tambin se cuenta con certificaciones para el Nivel Avanzado (AdvancedLevel): Jefe de Pruebas (Test Manager). Probador Tcnico (Technical Tester). ProbadorFuncional (Functional Tester)

El Nivel Experto se encuentra listo para descarga.

Los Comits de Pruebas (Testing Boards) locales de cada pas conforman la estructura de

la organizacin del "International Software Testing Qualification Board" (www.istqb.org) Por ejemplo en Hispanoamrica: HISPANIC America Software Testing Qualification Board

(HASTQB)

*ISTQB = International Software Testing Qualification Board (Comit Internacional deClasificacin de pruebas de software)


5/417

5 de 418


0 - Introduccin

04 - Programa de estudios y evaluacin

El conjunto de diapositivas est basado en elPrograma de Estudios de

Probador Certificado - Nivel Bsico del ISTQBVersin 2010 (marzo).

A continuacin del curso de formacin tendr lugar un examen al que se puede asistirpara obtener el certificado de Probador Certificado. Nivel Bsico (Certified TesterFoundation Level).

La evaluacin es realizada por un examinador perteneciente a una organizacinindependiente (por ejemplo ISQI*).

Los temas de la evaluacin estn extrados de las secciones correspondientes a las dadasen el curso de formacin. El examen es del tipo seleccin mltiple, con una duracin de

60 minutos. Cada pregunta tiene una (de cuatro) nica respuesta correcta. Tienen que ser

respondidas un total de 40 preguntas, de las cuales 26 (65%) tienen que ser respondidasde forma correcta con el objeto de aprobar el examen

* ISQI International Software Quality Institute


6/417

6 de 418


0 - Introduccin

05 - Objetivos

Objetivos principales para la formacin de Probador

Certificado

Aprender las tcnicas bsicas para planificar las pruebas.

Aplicar las tcnicas de pruebas software en proyectos.

Seleccionar las tcnicas y objetivos de pruebas apropiados. Aprender una terminologa comn.

Audiencia

El curso est dirigido a probadores de software, desarrolladores y jefes de proyecto en unentorno de produccin software as como en un entorno de produccin industrial quedeseen dar a su conocimiento un fundamento de mayor solidez.

Documentos

Conjunto de diapositivas propios de la presentacin.

Ejercicios y sus soluciones.

Referencias y glosario.


7/417

7 de 418


I - Fundamentos de Pruebas Software

Agenda

Captulo I - Fundamentos de Pruebas Software

I/01 Por qu es necesario Probar?

I/02 Qu son pruebas?

I/03 Los siete Principios generales del proceso de pruebas de software.

I/04 Proceso de pruebas bsico.I/05 Psicologa en el proceso de pruebas.

I/06 Cdigo de tica.


8/417

8 de 418



01 - Por qu es necesario Probar?

La importancia econmica del software

El funcionamiento de maquinaria y equipamiento depende en gran medida del software.

No es posible imaginar grandes sistemas, en el mbito de las finanzas ni el control degrfico, funcionando sin software.

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

tcnico o comercial de sistemas y producidos.

Pruebas para la mejora de la calidad

Las pruebas y revisiones aseguran la mejora de la calidad de productos software as comode la calidad del proceso de desarrollo en s.


9/417

9 de 418




Causas de los fallos (failures) de software

Error humanoUn defecto es introducido en el cdigo software, en los datos o en los parmetros deconfiguracin.

Causas del error humano:Plazos, demandas excesivas debidas a lo complejidad, distracciones.

Condiciones ambientalesCambios en las condiciones ambientales.

Causas de condiciones ambientales negativas/adversas.Radiacin, magnetismo, campos electromagnticos y polucin, manchas solares, fallo dediscos duros, fluctuaciones en el suministro de energa elctrica.


10/417

10 de 418




Error, defecto (defect), fallo (failure)

Error (IEEE 610):Accin humana que produce un resultado incorrecto por ej. Un error de programacin.

Defecto (Defect):Desperfecto en un componente o sistema que puede ser una causa por la cual el sistemao componente no logre llevar o cabo su funcin especfica, por ej. Sentencia o definicinde datos incorrectas.

Fallo (Failure):Manifestacin fsica o funcional de un defecto. Si un defecto es encontrado durante laejecucin de una aplicacin puede producir un fallo.Desviacin de un componente o sistema respecto de la prestacin, el servicio o resultadoesperados.

UN ERROR INTRODUCE UN DEFECTO, UN DEFECTO CAUSA UN FALLO.


11/417

11 de 418




Proceso de pruebas durante el proceso de desarrollo, mantenimiento y operaciones

Mejora de la calidad de un producto software:El proceso de pruebas ayuda a proveer al software de los atributos deseados. Puederetirar defectos que conducen a fallos.

Reduccin del riesgo de detectar errores:Actividades de pruebas software adecuadas reducirn el riesgo de encontrar erroresdurante la fase de operaciones software.

Satisfacer compromisos:La ejecucin de pruebas puede ser un requisito obligatorio por parte del cliente o debidoa normas legales as como el cumplimiento de estndares propios de la Industriaespecfica.


12/417

12 de 418




El costo de los defectos

El costo de eliminardefectos se incrementacon el tiempo durante el

cual el defecto permaneceen el sistema

La seleccin de errores enetapas tempranas permitela correccin de losmismos a costos

reducidos.


13/417

13 de 418




Calidad software

Definicin: Software (segn IEEE 610):Programas de computadora, procedimientos, y posiblemente documentacin asociada ascomo los datos relacionados con la operacin de un sistema Informtico.

Definicin: Calidad software (segn ISO/IEC 9126):La totalidad de la funcionalidad y caractersticas de un producto software quecontribuyen a su habilidad de satisfacer necesidades especificadas o implcitas

Definicin: Calidad (segn IEEE Std 610):Grado en el cual un componente, sistema o proceso satisface los requisitos especificadosy/o necesidades del usuario/cliente y sus expectativas.


14/417

14 de 418




Calidad software

De acuerdo a la norma ISO/IEC 9126 la calidad software est constituida por:o Funcionalidad Atributos funcionales de calidado Fiabilidado Usabilidado Eficiencia Atributos no-funcionales de calidado Mantenibilidado Portabilidad

Tipos de Aseguramiento d la Calidad (QA):o Actividades constructivascon el objeto de prevenir defectos, por ejemplo a travs

de la aplicacin de mtodos apropiados de ingeniera de software.

o Actividades analticascon el objeto de prevenir defectos. por ejemplo a travs depruebas que conducen a la correccin de defectos y prevencin de fallos,incrementando as la calidad del software.


15/417

15 de 418




Aseguramiento de la calidad constructivo Proceso de calidad - Gestin de la calidad.

Consigna

Los defectos evitados no requieren serreparados.

Los errores cometidos en el pasado nodeben ser repetidos.

Prevenir defectos


16/417

16 de 418




Aseguramiento de la calidad analtico Calidad de producto - Procedimientos de Verificacin y Pruebas

ConsignaLos defectos deben ser detectados tan

temprano en el proceso como seaposible.

Pruebas estticas examen sin laejecucin del programa.

Pruebas dinmicas incluye la ejecucin

del programa.


17/417

17 de 418




Calidad software - Atributos funcionales de calidadFuncionalidad significa:

Correcto: La funcionalidad satisface los atributos / capacidades requeridos.

Completitud: La funcionalidad satisface todos los requisitos (funcionales).

Funcionalidad incluye (segn ISO/IEC 9126):

Adecuacin.

Precisin.

Conformidad (Estndares).

Interoperabilidad (Componentes).

Seguridad.


18/417

18 de 418




Calidad software - Atributos no funcionales de calidad / 1

Fiabilidad

Madurez, tolerancia a defectos, recuperacin tras fallos.

Caractersticas: En determinadas condiciones, el software / sistema mantendr sucapacidad / funcionalidad a lo largo de un perodo de tiempo.

Fiabilidad = Calidad / tiempo.

Usabilidad

Facilidad de ser utilizado, facilidad de ser aprendido, facilidad de ser comprendido,atractivo.

Caractersticas: fcil de usar, fcil de aprender, conforme o normas, uso intuitivo.


19/417

19 de 418




Calidad software - Atributos no funcionales de calidad /2

Eficiencia

Comportamiento del sistema: funcionalidad y respuesta temporal.

Caractersticas: El sistema requiere la utilizacin de un mnimo de recursos (por ejemplotiempo de CPU) para ejecutar una tarea determinada.

Mantenibilidad

Verificable, estable, cualidad de ser analizado, modificable.

Caractersticas: Medida del esfuerzo requerido para realizar cambios en un sistema /componentes.

Portabilidad

Capacidad de ser reemplazado, Instalable.

Capacidad del software de ser transferido a un nuevo entorno (software, hardware,organizacin).

Caractersticas: Fcil de instalar y desinstalar, parmetros.


20/417

20 de 418




Atributos de la calidad

Algunos atributos de la calidad de un producto software se influyen mutuamente. Debidoa esta interdependencia y en funcin del objeto de prueba, los atributos debern sercaracterizados por una prioridad a los efectos de ser tenida en cuenta. Por ejemploeficiencia vs. portabilidad.

Se realizarn distintos tipos de pruebas con el objeto de medir cada tipo de atributo.


21/417

21 de 418


I - Fundamentos de Pruebas Software01 - Por qu es necesario Probar?

Objetivos de las pruebas

Adquirir conocimiento sobre los defectos en un objeto de prueba

Los defectos propios de un objeto de prueba deben ser detectados y descritos de talforma que se facilite su correccin.

Comprobar la funcionalidad

La funcionalidad del sistema debe ser implementada tal y como ha sido especificada.

Generar informacin

Se debe proporcionar Informacin relativa a evitar riesgos relativos a un sistema softwareantes de su entrega a los usuarios. La adquisicin de esta Informacin puede ser uno delos objetivos de las pruebas.

Generar confianza

Un sistema software que ha sido probado de forma adecuada se considera que cumplecon la funcionalidad esperada y cuenta con un alto nivel de calidad.


22/417

22 de 418



Cuntas pruebas son suficientes?

Criterio para la finalizacin de pruebas No encontrar (ms) defectos es un criterio apropiado para finalizar las actividades de pruebas.Sin embargo son necesarias otras mtricas para reflejar de forma adecuada el nivel de calidadalcanzado.

Pruebas basadas en el riesgoo El nivel de riesgo determina el grado en el cual se ha probado, es decir:

responsabilidad en caso de fallos, probabilidad de la ocurrencia de fallos, aspectosrelativos o factores econmicos y propios del proyecto.

Pruebas basadas en plazos y presupuestoo La disponibilidad de recursos (personal, tiempo, presupuesto) puede determinar la

medida del esfuerzo a dedicar al proceso de pruebas.


23/417

23 de 418



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

Caso de prueba (test case):La definicin de un caso de prueba incluye la siguiente informacin (segn IEEE Std 610):

o Precondiciones.o Conjunto de valores de entrada.o Conjunto de resultados esperados.o Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados.o Pos condiciones esperadas.

Base de la prueba (test basis o test base):Conjunto de documentos que definen los requisitos de un componente o sistema.Utilizado como fundamento para el desarrollo de casos de prueba.


24/417

24 de 418



Desarrollo de software y revisiones:

Cdigo (code), cdigo fuente (source code):Programa de computadora escrito en un lenguaje de programacin que puede ser ledopor una persona.

Depuracin (debugging):Localizacin y correccin de defectos en el cdigo fuente

Desarrollo software (software development):Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basadoen un computador (ordenador). Normalmente sigue un modelo de desarrollo software.

Requisito (requirement):Un requisito describe un atributo funcional deseado o considerado obligatorio.

Revisin (review):Evaluacin de un producto o estado de un proyecto con el objeto de detectardiscrepancias con respecto o los resultados esperados (planificados) y para recomendarmejoras (segn IEEE Std 1028).


25/417

25 de 418



Resumen:

Los fallos de software pueden causar importantes perjuicios.

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

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

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 elcriterio de finalizacin de pruebas finalizan las actividades del proceso de pruebas.

Los probadores (testers) buscan fallos en el sistema e informan sobre los mismos(proceso de pruebas). Los desarrolladores buscan defectos y los corrigen (depuracin).


26/417

26 de 418


I - Fundamentos de Pruebas SoftwareAgenda





I/04 Proceso de pruebas bsico.I/05 Psicologa en el proceso de pruebas.

I/06 Cdigo de tica


27/417

27 de 418


I - Fundamentos de Pruebas Software02 - Qu son pruebas?

Otros medios de prueba ms de la ejecucin de pruebas

Ejecucin de las pruebas es slo una parte de las pruebas

El proceso de prueba incluye:o Planificacin y controlo Eleccin de las condiciones de pruebao Diseo y ejecucin de casos de pruebao Control de resultadoso Evaluacin de los criterios de salidao Presentacin de informes sobre el proceso de prueba y el sistema bajo pruebao Finalizar o completar las actividades de cierre

Revisin de documentos, cdigos fuente y la realizacin de anlisis esttico tambinayudan a prevenir los defectos que aparecen en el cdigo.


28/417

28 de 418



Objetivos de pruebas

Bsqueda de defectosPuede ser:o En las pruebas de desarrollo: para encontrar el mayor nmero posible de erroreso En las pruebas de aceptacin: para confirmar que el sistema funciona como se

esperaba

Ganar confianza en el nivel de calidad

Proporcionar informacin para la toma de decisionesPara evaluar la calidad del software, para dar informacin a los interesados de los riesgosde liberar el sistema en un momento dado

Prevencin de defectosLas pruebas de mantenimiento permiten determinar si se han introducido nuevosdefectos durante el desarrollo de cambios


29/417

29 de 418



Trmino: Desarrollo de software

DepuracinEl proceso de encontrar, analizar y eliminar las causas de fallas en el software.

Requisito (requerimiento)Una condicin o capacidad que necesita un usuario para resolver un problema, alcanzar unobjetivo que se debe cumplir o que tenga un componente o el sistema, para satisfacer uncontrato, norma, especificacin u otro documento formalmente impuesto [despus de IEEE610].

RevisinLa evaluacin de un estado del producto o proyecto para determinar las discrepancias de los

resultados previstos y recomendar mejoras. Las revisiones incluyen [segn la IEEE 1028]:revisin de la gestin, revisin informal, revisin tcnica, inspeccin y walkthrough (tutorial).


30/417

30 de 418



Pruebas y depuracin (debugging)

Probar y volver a probar (re-test) son actividades propias del proceso de pruebas.Las pruebas muestran los fallos.

Volver a probar (re-test) verifica que el defecto ha sido corregido.

La depuracin y la correccin de defectos son actividades propias del desarrollo.A travs de la depuracin los desarrolladores pueden reproducir los fallos, analizar elestado del programa y detectar el defecto correspondiente con el objeto de corregirlo.


31/417

31 de 418



Resumen

El proceso de pruebas fundamentales comprende:o Pruebas de planificacin y control.o Pruebas de anlisis y diseo.o Pruebas de implementacin y ejecucin.o Evaluacin de criterios de salida y presentacin de informes.o Actividades de cierre de pruebas.

Los objetivos de pruebas pueden ser: Encontrar defectos, el nivel de calidad, informacinpara la toma de decisiones, la prevencin de defectos.

El diseo de pruebas debe iniciarse en fases tempranas del ciclo de vida del software.

Pruebas dinmicassignifica la ejecucin del software, las pruebas estticasconsiste en larevisin de documentos.

Las pruebas dinmicas muestran fallas que son causadas por defectos, la depuracinencuentra, analiza y elimina la causa de la falla.


32/417

32 de 418






I/03 Los siete principios generales del proceso de pruebas de software.

I/04 Proceso de pruebas bsico.

I/05 Psicologa en el proceso de pruebas.

I/06 Cdigo de tica


33/417

33 de 418


I - Fundamentos de Pruebas Software03 - Los siete principios generales del proceso de pruebas de software.

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

El proceso de pruebas puede probar la presencia de defectos.

Las desviaciones identificadas a lo largo del proceso de pruebas demuestran la presenciade un fallo.

La causa de un fallo puede no ser obvia.

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

Las pruebas reducen la probabilidad de la presencia de defectos que permanecen sin serdetectados. La ausencia de fallos no demuestra la correccin de un producto software.

El mismo proceso de pruebas puede contener errores.

Las condiciones de las pruebas pueden ser inapropiadas para detectar errores.


34/417

34 de 418



Principio 2: No es posible realizar pruebas exhaustivas

Pruebas exhaustivas (exhaustive testing).o Enfoque del proceso de pruebas en el cual el juego de pruebas (suite de pruebas)

abarca todas las combinaciones de valores de entrada y precondiciones.

Explosin de casos de prueba (test case explosion).o Define el incremento exponencial de esfuerzo y costo en el caso de pruebas

exhaustivas.

Prueba de muestra (sample test).o La prueba incluyo solamente a un subconjunto (generado de forma sistemtica o

aleatoria) de todos los posibles valores de entrada.o En condiciones normales, se utilizan generalmente pruebas de muestra. Probar

todas las combinaciones posibles de entradas y precondiciones slo eseconmicamente viable en casos triviales.


35/417

35 de 418



Principio 3: Pruebas tempranas (early testing)

La correccin de un defecto es menos costosa en la medida en la cual su deteccin serealiza en fases ms tempranas del proceso software.

Se obtiene una mxima rentabilidad cuando los errores son corregidos antes de laimplementacin.

Los conceptos y especificaciones pueden ser probados.

Los defectos detectados en la fase de concepcin son corregidos con menor esfuerzo ycostos.

La preparacin de una prueba tambin consume tiempo.

El proceso de pruebas implica ms que slo la ejecucin de pruebas.

Las actividades de pruebas pueden ser preparadas antes de que el desarrollo se hayacompletado.

Las actividades de pruebas (incluidos las revisiones) deben ser ejecutadas en paralelo a laespecificacin y diseo software.


36/417

36 de 418



Principio 4: Agrupamiento de defectos (defect clustering)

Al encontrar un defecto se encontrarn ms defectos "cerca"

Los defectos aparecen agrupados como hongos o cucarachas.

Cuando se detecta un defecto es conveniente investigar el mismo mdulo en el que hasido detectado.

Los probadores (testers) deben ser flexibles

Habiendo sido detectado un defecto es conveniente volver a considerar el rumbo de laspruebas siguientes.

La identificacin de un defecto puede ser investigada con un mayor grado de detalle, porejemplo, realizando pruebas adicionales o modificando pruebas existentes.


37/417

37 de 418


I - Fundamentos de Pruebas Software03 - Los siete Principios generales del proceso de pruebas de software.

Principio 5: Paradoja del pesticida

Repetir pruebas en las mismas condiciones no es efectivo. o Cada caso de prueba debe contar con una combinacin nica de parmetros de

entrada para un objeto de pruebas particular, de lo contrario no se podr obtenerinformacin adicional.

o Si se ejecutan las mismas pruebas de forma reiterada no se podrn encontrar

nuevos defectos. Las pruebas deben ser revisadas/modificadas regularmente para los distintos mdulos

(cdigo).o Es necesario repetir una prueba tras una modificacin del cdigo (correccin de

defectos, nueva funcionalidad)o La automatizacin de pruebas puede resultar conveniente si un conjunto de casos

de prueba se debe ejecutar frecuentemente.


38/417

38 de 418



Principie 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.o El controlador del motor de un coche requiere pruebas diferentes respecto de

aquellas para una aplicacin de "e- Commerce".

Entorno de pruebas (cama de pruebas - test bed) vs. entorno de produccin.o Las pruebas tienen lugar en un entorno distinto del entorno de produccin. El

entorno de pruebas debe ser similar al entorno de produccin.o Siempre habr diferencias entre el entorno de pruebas y el entorno de produccin.

Estas diferencias introducen incertidumbre con respecto a las conclusiones que sepudieran obtener tras las pruebas.


39/417

39 de 418



Principio 7: La falacia de la ausencia de errores

Un proceso de pruebas adecuado detectar los fallos ms importantes.

En la mayora de los casos el proceso de pruebas no encontrar todos los defectos delsistema (ver Principio 2), pero los defectos ms importantes deberan ser detectados.

Esto en s no prueba la calidad del sistema software. La funcionalidad del software puede no satisfacer las necesidades y expectativas de los

usuarios.

No se puede introducir la calidad a travs de las pruebas, ella tiene que construirse desdeel principio.


40/417

40 de 418



Resumen:

Las pruebas pueden ayudar a detectar defectos en el software, sin embargo las mismasno pueden demostrar la ausencia de defectos.

Salvo en casos triviales, las pruebas exhaustivas son imposibles, las pruebas de muestrason necesarias.

Las pruebas tempranas ayudan a reducir costos dado que los defectos descubiertos enfases tempranas del proceso software son corregidos con menor esfuerzo.

Los defectos se presentan agrupados. El encontrar un defecto en una ubicacindeterminada significa que probablemente se encontrar otro defecto a su alrededor.

Repetir pruebas idnticas no genera nueva Informacin.

Cada entorno particular determina la forma en la cual se ejecutarn o desarrollarn laspruebas.

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


41/417

41 de 418








I/05 Psicologa en el proceso de pruebas.

I/06 Cdigo de tica


42/417

42 de 418


I - Fundamentos de Pruebas Software04 - 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 en diferentespuntos del proceso de desarrollo.

Las pruebas constituyen un proceso en s mismas.

El proceso de pruebas est determinado por las siguientes fases:o Planificacin de pruebas.o Anlisis de pruebas y diseo de pruebas.o Implementacin de pruebas y ejecucin de pruebas.o Evaluacin del criterio de finalizacin de pruebas y generacin de informes de

pruebas.o Actividades de cierre de pruebas.

As tambin: Control de las pruebas (todas las fases).

LAS FASES DEL PROCESO DE PRUEBAS SE PODRN SUPERPONER.


43/417

43 de 418



El proceso de pruebas a lo largo del proceso de desarrollo software

Incluye superposicin y vueltaatras (backtracking).

El proceso de pruebas es msque la ejecucin de pruebas!

Cada fase del proceso depruebas tiene lugar de formaconcurrente con las fases delproceso de desarrollo software.


44/417

44 de 418



Control de pruebas - tareas principales

El control de pruebas es una actividadcontinua que influye en la planificacinde las pruebas. El plan de pruebas puedeser modificado en funcin de la

informacin adquirida a partir delcontrol de pruebas.

El estado del proceso de pruebas sedetermina comparando el progresologrado con respecto al plan de pruebas.Se iniciarn aquellas actividades que seconsideraran consecuentemente necesarias.

Se miden y analizan resultados. El progreso de las pruebas, la cobertura de las pruebas y el cumplimiento del criterio de

finalizacin de pruebas son objeto de seguimiento y son documentados.

Se inician medidas correctivas.

Preparar y tomar decisiones.


45/417

45 de 418



Planificacin de pruebas - tareas principales

Determinar el alcance y los riesgos.

Identificar los objetivos de las pruebas y elcriterio de finalizacin de pruebas.

Determinar el enfoque: tcnicas de

pruebas, cobertura de pruebas, equipo depruebas.

Implementar el mtodo de pruebas /estrategia de pruebas, planificacin deltiempo disponible para las actividades aseguir.

Adquirir/obtener y programar recursos

requeridos por las pruebas: personal,entorno de pruebas, presupuesto de pruebas.


46/417

46 de 418



Trminos: Planificacin de pruebas

Plan Maestro de prueba (en alemn: Testkonzept):Un documento que describe el alcance, el enfoque, los recursos y el calendario de actividadesde la prueba prevista. Esto incluye, pero no se limita a los recursos, los elementos de prueba,las caractersticas de la prueba y planes de contingencia.

Estrategia de pruebas:Una descripcin de alto nivel de los niveles de prueba a realizar y las pruebas dentro de losniveles de una organizacin o programa (uno o ms proyectos).

Enfoque de pruebas:La aplicacin de la estrategia de prueba para un proyecto especfico Por lo general incluye las

decisiones que siguen a los objetivos (de prueba) del proyecto y el anlisis de riesgos, puntosde partida sobre el proceso de prueba, las tcnicas de diseo de la prueba que deben aplicarse,los criterios de salida y tipos de prueba para llevar a cabo.


47/417

47 de 418



Trminos: Planificacin de pruebas

Criterios de salida (despus de Gilb y Graham]:

El conjunto de las condiciones genricas y especficas, acordadas con las partes interesadas,para permitir que un proceso sea completado oficialmente. El propsito de los criterios de

salida es evitar que una tarea sea considerada completa cuando todava hay partes de la tareapendiente que no se han terminado. Criterios de salida se utilizan para informar y paraplanificar cundo dejar de probar. Esto debe hacerse para cada nivel de prueba.


48/417

48 de 418



Anlisis y diseo de pruebas - tareas principales

Revisin de las bases de las pruebas (requisitos,arquitectura del sistema, diseo, interfaces).

Anlisis de lo arquitectura del sistema, diseodel sistema incluyendo las interfaces entre los

objetos de prueba. Identificar condiciones de prueba especficas y

los datos de prueba necesarios.

Evaluar la disponibilidad de datos de prueba y/ola viabilidad de generar dalos de prueba

Diseo de pruebas / casos de prueba.

Crear casos de prueba lgicos (casos de prueba con datos de prueba sin valores

especficos) y establecer un orden de prioridad para los mismos. Los casos de prueba positivos comprueban la funcionalidad, los casos de prueba

negativos comprueban situaciones en las cuales se debe realizar un tratamiento deerrores

Anlisis de la posibilidad de realizar pruebas sobre el sistema.


49/417

49 de 418



Anlisis y diseo de pruebas - tareas principales

Organizacin del entorno de pruebas (cama de pruebas - test bed).o Disponibilidad (exclusiva) del entorno de pruebas, ventanas de tiempo. etc.o Definir el modo de operacin del entorno de pruebas, incluida la administracin de

usuarios.o Carga de datos de prueba y parmetros del sistema.o Conexin del entorno de pruebas con los sistemas adyacentes.

Infraestructura de pruebas y herramientas de pruebas (si fuera necesario).o Procesos, procedimientos y responsabilidades.o Eleccin, suministro. Instalacin y operacin de herramientas de pruebas.


50/417

50 de 418



Trminos: Anlisis y diseo de pruebas

Datos de prueba (test data):Datos que existen en el sistema antes de que una prueba sea ejecutada y que afecta o esafectado 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 delmismo).

Cobertura de pruebas (test coverage):Grado en el cual un elemento especifico ha sido ejecutado por un conjunto de pruebas.Utilizado con mayor frecuencia en pruebas de caja blanca con el objeto de determinar la

cobertura del cdigo.


51/417

51 de 418



Trminos: Anlisis y diseo de pruebas

Orculo de pruebas (test oracle):Fuente que permite determinar los resultados esperados de un software sujeto o pruebas:comparativas (benchmarks) (tambin resultado de pruebas previas), manuales de usuario oconocimiento especializado. No debe ser el cdigo.


52/417

52 de 418



Ejecucin de pruebas - tareas principales

Desarrollo y asignacin de un orden deprioridad a los casos de prueba.o Creacin de datos de prueba, desarrollo

de procedimientos de prueba.o Creacin de secuencias de pruebas

(juegos de pruebas - test suites)

Creacin de scripts de automatizacin depruebas, si fuera necesario.

Configuracin del entorno de pruebas (cama

de pruebas - test bed).

Ejecucin de pruebas (de forma manual o automtica)o Seguimiento de secuencias de pruebas establecidas en el plan de pruebas (juegos de

pruebas orden de los casos de prueba).

3 d 418


53/417

53 de 418



Ejecucin de pruebas - tareas principales

Registro y anlisis de los resultados de pruebas.

Reiteracin de pruebas (retest)o Despus de correccin de defecto

Pruebas de regresin (regression testing).o Tras una correccin o instalar una nueva funcionalidad (cambio): Repeticin de

pruebas con el objeto de asegurar que los defectos han sido corregidos y que lascorrecciones o modificaciones no han Introducido nuevos defectos.

54 d 418


54/417

54 de 418



Trminos: Ejecucin de pruebas

Juego de pruebas (test suite) / secuencia de pruebas (test sequence):Conjunto de casos de prueba para un componente o sistema, donde Ia poscondicin de un casode prueba es utilizada como precondicin para el caso de prueba siguiente.

Especificacin de procedimiento de pruebas (test procedure specification, escenario depruebas - test scenario):Documento en el cual se especifica una secuencia de acciones para la ejecucin de uno pruebaTambin conocido como guin de pruebas o guin de pruebas manuales (Segn IEEE Std 829)

Ejecucin de pruebas (test execution):Es el proceso de llevar a cabo una prueba, aportando / generando los resultados reales.

Registro de pruebas (test log) (informe de pruebas - test report):Relacin cronolgica de los detalles relevantes relativa a la ejecucin de pruebas cuando sedesarrollaron las pruebas, qu resultados fueron generados.

55 d 418


55/417

55 de 418



Trminos: Ejecucin de pruebas

Pruebas de regresin (regression tests):Pruebas tras la modificacin de un programa previamente probado, con el objeto de asegurarque no se han introducido o descubierto defectos en reas que no hubieran sido objeto demodificacin como resultado de los cambios realizados. Se realizan cuando el software o su

entorno han sido modificados.

Pruebas de confirmacin (confirmation testing), reiteracin de pruebas (retest):Repeticin de una prueba despus de la correccin de un defecto, con el objeto de confirmarque el defecto ha sido eliminado con xito.

56 de 418


56/417

56 de 418



Evaluacin del criterio de salida - tareasprincipales

Evaluacin de la ejecucin de pruebas conrespecto a objetivos definidos.

Evaluacin de los registros de pruebas(resumen de las actividades de pruebas,resultados de prueba, comunicar criterio desalida).

Proporcionar informacin con el objeto depermitir la decisin con respecto a si tendrn

lugar pruebas adicionales.

57 de 418


57/417

57 de 418



Actividades de cierre de pruebas - tareasprincipales

Recopilar datos de las actividades delproceso de pruebas finalizadas con el objetode consolidar la experiencia, utensilios de

pruebas (testware), hechos y resultados(valores).

Cierre de informes de incidencias ogeneracin de solicitudes de cambio paracualquier punto que permaneciera abierto.

Comprobar qu entregables planificados han sido entregados y probados.

Documentar la aceptacin del sistema.

Finalizar y archivar los utensilios de pruebas (testware), el entorno de pruebas y lainfraestructura de pruebas para un uso posterior, transferencia al entorno deoperaciones.

Analizar las lecciones aprendidas para futuros proyectos.

58 de 418


58/417

58 de 418



Resumen:

El proceso de pruebas se puede dividir en diferentes fases.

Planificacin de pruebas (test planning) abarca actividades como la definicin de laestrategia de pruebas para todas las fases as como la planificacin de los recursos

(tiempo, personal, mquinas). Diseo de pruebas(especificacin) abarca el diseo de casos de prueba y sus resultados

esperados.

Ejecucin de pruebasabarca la definicin de datos de pruebas, la ejecucin de pruebas yla comparacin de resultados.

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

Evaluacin de pruebasabarca el anlisis de defectos y la evaluacin del criterio de salida. Control de pruebas consiste en las actividades de control que abarcan todas las foses

anteriores.

59 de 418


59/417

59 de 418








I/05 Psicologa en el proceso de pruebas.I/06 Cdigo de tica

60 de 418


60/417

60 de 418


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

Roles y responsabilidades

Rol: Desarrollador

Implementa requisitos.

Desarrolla estructuras.

Desarrolla el software.

Crea un producto.

Rol: Probador (Tester)

Planifica las actividades de pruebas.

Disea casos de prueba.

Su nica preocupacin es encontrar

defectos. Encontrar errores producidos por un

desarrollador es su xito.

Percepcin:La actividad del desarrollador esCONSTRUCTIVA

La actividad del probador (tester) esDESTRUCTIVA

Las pruebas tambin constituyen una actividad constructiva, su propsito es la eliminacinde defectos en un producto!

61 de 418


61/417

61 de 418



Caractersticas personales de un buen tester /1

Curioso, perceptivo, atento a los detalles.o Con el objeto de comprender los escenarios prcticos del cliente.o Con el objeto de poder analizar la estructura de una prueba.o Con el objeto de descubrir dnde se pueden manifestar fallos.

Escptico y con actitud crtica.o Los objetos de prueba contienen defectos. Usted solo debe encontrarlos.o No se debe tener temor al hecho de que pueden ser descubiertos defectos serios

que tengan un impacto sobre la evolucin del proyecto.

62 de 418


62/417

62 de 418



Caractersticas personales de un buen tester /2

Aptitudes para la comunicacin.o Necesarias para llevar malas noticias a los desarrolladores.o Necesarias para vencer estados de frustracin.o Tanto cuestiones tcnicas como prcticas, relativas al uso del sistema, deben ser

entendidas y comunicadas.o Una comunicacin positiva puede ayudar a evitar o facilitar situaciones difciles.o Facilitan establecer una relacin de trabajo con los desarrolladores a corto plazo.

Experiencia.o Factores personales influyen en la ocurrencia de errores.o La experiencia ayuda a identificar dnde se pueden acumular errores.

63 de 418


63/417



Diferencias: disear - desarrollar - probar

Las pruebas requieren una perspectiva distinta a la del diseo y desarrollo de sistemassoftware.o Objetivo comn:proveer un buen producto software.o Cometido del diseo: ayudar al cliente a proveer/suministrar los requisitos

correctos.o Cometido de los desarrolladores:convertirlos requisitos en funciones.o Cometido de los probadores (testers): evaluar la correcta implementacin de los

requisitos del cliente.

En principio, una persona puede asumir los tres roles en su trabajo.o Se deben tener en cuenta las diferencias en objetivos y modelos de conducta.o Es difcil pero posible.

o A veces otras soluciones (pruebas independientes) pueden ser ms sencillas yaportar mejores resultados.

64 de 418


64/417



Pruebas independientes

La separacin de las responsabilidades en el proceso de pruebas apoya/promueve laevaluacin independiente de los resultados de las pruebas.

En el siguiente diagrama se representa el grado de independencia a travs de un grfico de

barras.

65 de 418


65/417



Tipos de organizacin de pruebas /1

Pruebas del desarrolladoro El desarrollador nunca analizar su "creacin" de forma imparcial (apego afectivo).

Sin embargo, l conoce el objeto de pruebas mejor que nadie. Habr costos adicionales debido a la formacin/Informacin de otras personas

respecto del objeto de pruebas.o Las personas tienden a pasar por alto sus propios defectos.

Los desarrolladores corren el riesgo de no reconocer defectos evidentes.o Errores cometidos como consecuencia de una mala interpretacin de los requisitos

se mantendrn sin ser detectados. Establecer grupos de prueba donde los desarrolladores prueben los productos

de otros, ayuda a evitar, o al menos, reducir la posibilidad de ocurrencia de

esto tipo de anomala (producida por negligencia).

66 de 418


66/417




Equipos de desarrolloo Los desarrolladores hablan el mismo lenguaje.o Los costos de formacin/informacin en lo relativo a objetos de prueba se

mantienen a un nivel moderado, especialmente cuando los equipos intercambian

objetos de prueba.o Peligro de generacin de conflictos entre equipos de desarrollo.

Un desarrollador que busca y encuentra un defecto no ser el mejor amigo delautor del objeto de prueba analizado.

o Mezcla de actividades de desarrollo y pruebas. Cambios frecuentes en la forma de pensar.

Dificultad en el control del presupuest del proyecto.

67 de 418


67/417




Equipos de pruebaso La creacin de equipos de pruebas que den servicio o diferentes reas de proyecto

mejora la calidad de las pruebas.o Es importante que los equipos de pruebas de diferentes reas en el proyecto

trabajen de forma independiente.

68 de 418


68/417




Outsourcing de pruebas (subcontratacin)o La separacin de las actividades de pruebas y desarrollo aportan la mxima

independencia entre los objetos de prueba y el probador (tester).o Las actividades de pruebas subcontratadas (externalizadas) son ejecutadas por

personal con un conocimiento relativamente pequeo de los objetos de prueba y delos antecedentes del proyecto.

Lo curva de aprendizaje Implica altos costos, por lo tanto deberan serIncorporados expertos Independientes en etapas tempranas del proyecto.

o Los expertos externos cuentan con un alto nivel de conocimiento (know how) delproceso de pruebas.

Est asegurando un diseo de pruebas apropiado.

Se alcanza la optimizacin en el uso de mtodos y herramientas. Diseo de casos de prueba de forma automtica

o Generacin de casos de prueba asistida por ordenador, por ejemplo casos deprueba basados en documentos de especificaciones formales.

69 de 418


69/417



Dificultades /1

Incapacidad de comprensin mutua.o Los desarrolladores deberan contar con un conocimiento bsico de pruebas.o Los probadores (testers) deberan contar con un conocimiento bsico de desarrollo

software.

Especialmente en situaciones de tensin, la deteccin de errores cometidos por alguienfrecuentemente conduce a conflictos.o La forma de documentar los defectos y la forma en la cual el defecto es descrito

determinar cmo se desarrollarn los hechos.o Las personas no deberan ser criticadas, los defectos deben ser descritos en

trminos objetivos.o La descripcin de los defectos debera ayudar al desarrollador a encontrar el error.

o Los objetivos comunes siempre deben ser la cuestin principal.

70 de 418


70/417



Dificultades /2

Lo comunicacin entre probadores (testers) y desarrolladores es insuficiente oinexistente. Este hecho puede hacer imposible el trabajo conjunto.o Los probadores (testers) son vistos nicamente como "portadores de malas

noticias".o Mejora: intente ponerse en el lugar (rol) de la otra persona. Ha llegado mi

mensaje? La respuesta es suficiente?

Un proceso de pruebas slido requiere la distancia apropiada con respecto al objeto deprueba.o Se adquiere un punto de vista independiente e imparcial a travs de la distancia con

respecto al desarrollo.o Sin embargo, una distancia muy grande con respecto al objeto de prueba y el equipo

de desarrollo conducir a mayores esfuerzos y tiempo para las pruebas.

71 de 418


71/417



Resumen

Las personas cometen errores, toda implementacin tiene defectos.

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

Desarrollador y probador (tester) implican el encuentro de dos mundos distintos.o El desarrollo es constructivo - algo que no estaba ah previamente es creado.o El proceso de pruebas resulta destructivo a primera vista - Se delectarn defectos!o Juntos, el desarrollo y las pruebas son constructivos en su objetivo de obtener un

producto de software con la menor cantidad de defectos posible.

Las pruebas Independientes aumentan la calidad del proceso de pruebas.o En lugar de equipos de desarrolladores utilice equipos de prueba o equipos de

prueba con personal externo.

72 de 418


72/417








I/05 Psicologa en el proceso de pruebas.I/06 Cdigo de tica

73 de 418


73/417


I - Fundamentos de Pruebas Software06Cdigo de tica

Cdigo de tica / 1

Las personas que participan en pruebas de software, tienen acceso a informacin muyprivilegiada y crtica. Para garantizar que la informacin no es objeto de un uso inadecuado, elcdigo de tica es necesario.

Pblico:Los probadores certificados de software actuarn segn los intereses de su cliente y suempleador, de conformidad con el inters pblico, especialmente al trabajar en un sistema deseguridad crtico

Cliente y Empleador: El probador certificado deber actuar segn los intereses de sus clientes yempleadores, de acuerdo con el inters pblico. Por ejemplo, que no se filtre informacininterna o privada, sobre el cliente o el empleador en Internet.


74/417

75 de 418


75/417


I - Fundamentos de Pruebas Software06Cdigo de tica

Cdigo de tica / 3

Profesin: Los probadores certificados de software debern promover la integridad yreputacin de la profesin de acuerdo con el inters pblico.

Colegas: Los probadores certificados de software sern justos y apoyarn a sus colegas y

promovern la cooperacin con los desarrolladores de software.

Personal: Los probadores de software certificado se capacitarn permanentemente sobre laprctica de su profesin y promovern un enfoque tico de la prctica de la profesin. Asistir acursos y leer libros puede ser una manera de mantener el conocimiento en un alto nivel.

76 de 418


76/417


II - Pruebas a lo largo del ciclo de vida softwareAgenda

Captulo II - Pruebas a lo largo del ciclo de vida software

II/01 Modelos de desarrollo software.

II/02 Niveles de prueba.

II/03 Tipos de prueba - objetivos de las pruebas.

II/04 Pruebas de Mantenimiento

77 de 418


77/417


II - Pruebas a lo largo del ciclo de vida software01Modelos de desarrollo software.

Pruebas a lo largo del modelo-V general(Modelo secuencial de desarrollo)

El modelo-V general es el modelo de desarrollo software ms utilizado.

Desarrollo y pruebas tienen dos ramas iguales.o Cada nivel de desarrollo tiene su correspondiente nivel de pruebas.

Las pruebas (rama derecha)se disean en paralelo aldesarrollo software (ramaizquierda).

Las actividades del proceso

de pruebas tienen lugar a lolargo de todo el ciclo de vidasoftware.

78 de 418


78/417



Pruebas a lo largo del modelo-V general

Rama: desarrollo software.

Definicin de requisitos.o Documentos de especificacin.

Diseo funcional del sistema.

o Diseo del flujo funcional delprograma.

Diseo tcnico del sistema.o Definicin de arquitectura/

interfaces.

Especificacin de los componentes.o Estructura de los componentes.

Programacin.o Creacin de cdigo ejecutable.

79 de 418


79/417



Pruebas a lo largo del modelo-V general

Rama: pruebas software.

Pruebas de aceptacin.o Pruebas formales de los requisitos

del cliente.

Pruebas de sistema.o Sistema Integrado,

especificaciones.

Pruebas de integracin.o Interfaces de componentes.

Pruebas de componente.o Funcionalidad del componente.

80 de 418


80/417



Verificacin vs. Validacin

Verificacino Comprobacin de la conformidad con los requisitos establecidos (definicin segn

ISO 9000).o Cuestin clave: Se ha procedido correctamente en la construccin del sistema?

o Hemos sumado 1 ms 1 correctamente?

Validacino Comprobacin de la idoneidad para el uso esperado (definicin segn ISO 9000).o Cuestin clave: Hemos construido el sistema de software correcto?o El objetivo era sumar 1 ms 1 o deberamos haber restado?

81 de 418


81/417



Verificacin dentro del modelo-V general

Cada nivel de desarrollo se verifica respecto de los contenidos del nivel que le precede.o Verificar: comprobar la evidencia.

Verificar significa comprobar si los requisitos y definiciones de niveles previos han sidoImplementados correctamente.

82 de 418


82/417



Validacin dentro del modelo-V general

Lo validacin se refiere a la correccin de cada nivel de desarrollo.o Validar: Dar prueba de la aportacin de valor.

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

83 de 418


83/417



Modelo-W

El modelo W puede ser visto como una extensin del modelo-V general

En los estados W-modelo, ciertas actividades de control de calidad se realizar enparalelo con el proceso de desarrollo

84 de 418


84/417



Otros modelos de prueba: modelos iterativos /1

Desarrollo software iterativo.o Las actividades: Definicin de requisitos, diseo, desarrollo y pruebas se segmentan

en pasos reducidos y se ejecutan de formo continua.o Se debe lograr el consentimiento con el cliente tras cada iteracin con el objeto de

modificar el rumbo del proyecto si fuera necesario.

Ejemplos de modelos iterativos:o Modelo Prototipado: Desarrollo rpido de una representacin del sistema que

pudiera ser objeto de uso. Seguido de modificaciones sucesivas hasta que el sistemasea finalizado.

o Desarrollo Rpido de Aplicaciones (Rapid Application Development - RAD): LaInterfaz de usuario se Implementa utilizando una funcionalidad hecha (out of thebox) simulando lo funcionalidad que posteriormente ser desarrollada.

o

Proceso Unificado (Rational Unified Process - RUP):Modelo orientado a objetos yproducto de la compaa Rational/lBM. Principalmente aporta el lenguaje demodelado UML y soporte al Proceso Unificado.

o Programacin Extrema (Extreme Programming - XP): El desarrollo y las pruebastienen lugar sin una especificacin de requisitos formalizada.

85 de 418


85/417




Caractersticas de los modelos iterativos:o Cada iteracin contribuye con una caracterstica adicional del sistema bajo

desarrollo.o Cada iteracin puede ser probada por separado.

o Las pruebas de regresin son de gran relevancia.o En cada iteracin, la verificacin (relacin con el nivel precedente) y la validacin

(grado de correccin del producto dentro del nivel actual) se pueden efectuar porseparado.

86 de 418


86/417




Desarrollo guiado por pruebas (Test Driven Development - TDD)o Desarrollo basado en conjunto de pruebas (Suite cases)

Preparar los ciclos de pruebas Prueba automatizada utilizando herramientas de prueba

o Desarrollo, segn los casos de prueba Preparar versiones tempranas del componente para probarlo

Ejecucin automtica de pruebas Corregir los defectos en las versiones Repetir el conjunto de pruebas hasta que no se encuentran errores

Primero se disean las pruebas, luego el software es desarrollado

87 de 418


87/417



Principios de todos los modelos

Cada actividad de desarrollo debe ser probada.o Ninguna porcin del software puede quedar sin ser probada, tanto si ha sido

desarrollada "en una nica fase" o de forma Iterativa.

Cada nivel de pruebas debera ser probado de forma especfica.

o Cada nivel de pruebas cuenta con sus propios objetivos de prueba.o Las pruebas llevadas a cabo en cada nivel deben reflejar estos objetivos.

El proceso de pruebas comienza con mucha antelacin a la ejecucin de pruebas.o Tan pronto como el desarrollo comienza puede comenzar la preparacin de las

pruebas correspondientes.o Tambin es el caso de las revisiones de documentos comenzando por los conceptos,

especificacin y el diseo en conjunto.

88 de 418


88/417



Resumen

El desarrollo de software utiliza modelos tanto para el propio desarrollo de softwarecomo para las actividades del proceso de pruebas.

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

Los modelos iterativos ms relevantes son RUP y XP.

Las actividades de pruebas estn recomendadas en todos los niveles de desarrollo.

89 de 418


89/417


II - Pruebas a lo largo del ciclo de vida softwareAgenda

Captulo II - Pruebas a lo largo del ciclo de vida software

II/01 Modelos de desarrollo software.

II/02 Niveles de prueba.

II/03 Tipos de prueba - objetivos de las pruebas.

II/04 Pruebas de Mantenimiento

90 de 418


90/417


II - Pruebas a lo largo del ciclo de vida software02Niveles de prueba.

Pruebas de Componente

91 de 418


91/417



Pruebas de componente

Bases de prueba (Test basis):o Requisitos (requerimientos )de los componenteso Diseo detalladoo Cdigo

Objetos de prueba tpicos:o Componentes / clases / unidades / mduloso Programaso Conversin de datos / programas de migracino Base de datos de los mdulos

92 de 418


92/417



Pruebas de ComponenteDefinicin

Pruebas de componente (pruebas unitarias, pruebas de mdulo, pruebasde clase, pruebas de desarrollador).o Pruebas de cada componente tras su realizacin.

Dadas las convenciones de cada lenguaje de programacin para la asignacin de nombres

a sus respectivos componentes, se podr hacer referencia a un componente como:o Prueba de mdulo (module test) (por ejemplo en C).o Prueba de clase (por ejemplo en Java o C++).o Prueba de unidad (por ejemplo en Pascal).

Los componentes son referidos como mdulos, clases o unidades. Dado que losdesarrolladores posiblemente pueden estar Involucrados en la ejecucin de pruebas,stas tambin son denominadas pruebas de desarrollador (developer test).

93 de 418


93/417


II - Pruebas a lo largo del ciclo de vida software

02Niveles de prueba.

Pruebas de componenteAlcance

Slo se prueban componentes individuales.o Un componente puede estar constituido por un conjunto de unidades ms

pequeas.

o

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

Cada componente es probado de forma independiente.o Descubriendo defectos internos.o Los efectos cruzados entre componentes quedan fuera del alcance de estas

pruebas.

Los casos de pruebas pueden ser derivados de:

o

Especificacin de componenteso Diseo de Softwareo Modelos de datos

94 de 418


94/417



Pruebas de componente - Pruebas Funcionales y No Funcionales /1.

Pruebas de funcionalidado Toda funcionalidad debe ser probada, por lo menos, con un caso de prueba.

Las funciones: Se realizan correctamente? La funcionalidad: Cumple todaslas especificaciones?

o

Defectos descubiertos habitualmente: Defectos en el tratamiento de datos, normalmente en los valores fronteras

(boundary values). Funciones ausentes (missing functions).

95 de 418


95/417



Pruebas de componente - Pruebas Funcionales y No Funcionales /2.

Probar la robustez (testing robustness) (resistencia a datos de entrada invlidos).o Los casos de prueba que comprueban datos de entrado Invlidos se denominan

pruebas negativaso Un sistema robusto aporta un tratamiento apropiado para datos de entrada

errneos. La aceptacin por parte del sistema de datos de entrada errneos puede

producir fallos en un futuro procesamiento de los mismos (datos de salidaerrneos, fallo del sistema - system crash).

Otros atributos No Funcionales pueden ser probadoso Por ejemplo pruebas de estrs y rendimiento

96 de 418


96/417



Pruebas de componente - Arns de pruebas

La ejecucin de pruebas de componente requiere, frecuentemente, de DRIVERSy STUBS.o Un DRIVERprocesa la interfaz de un componente.

Los DRIVERSsimulan datos de entrada, registran datos de salida y aportan unarns de pruebas (test harness).

Los DRIVERSutilizan herramientas de programacin.

Un STUB reemplaza o simula un componente que an no seencuentro disponible.

Para programar un DRIVERo un STUB, el probador debe>o Tener conocimientos de programacin

o

Tener el cdigo fuente disponibleo Puede necesitar herramientas especiales

97 de 418


97/417



Pruebas de componente - mtodos

El cdigo fuente se encuentra disponible para el probador (tester).o Caso probador (tester) = desarrollador: Las pruebas se desarrollan con una fuerte

orientacin hacia el desarrollo.o El conocimiento de la funcionalidad, estructura de componentes y variables puede

ser aplicado para el diseo de casos de prueba.o Las pruebas funcionales pueden ser aplicadas (con frecuencia).o Adicionalmente, el uso de depuradores (debuggers) y otras herramientas de

desarrollo permitirn acceso directo a las variables del programa.

El conocimiento del cdigo fuente permitir la aplicacin de mtodos de caja blanca(white box) para pruebas de componente.

98 de 418


98/417



Pruebas de componente - Resumen

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

Prueba de mdulo, de clase, de unidad y de desarrollador son utilizados como sinnimos.

Los DRIVERS ejecutarn las funciones de un componente y las funciones adyacentes queson reemplazadas por STUBS.

Las pruebas de componente podrn comprobar caractersticas funcionales y nofuncionales de un sistema.

99 de 418


99/417



Pruebas de Integracin

100 de 418


100/417



Pruebas de integracin

Base de la prueba:o Software y diseo de sistemaso Arquitecturao Diagramas de Flujo

o

Casos de Uso Objetos de prueba tpicos:

o Sub-sistemas de implementacin de bases de datoso Infraestructurao Interfaces

Configuracin del sistema:o Configuracin de datos

101 de 418


101/417



Pruebas de IntegracinDefinicin

Tambin llamadas pruebas de interfaz

Comprueba la interaccin entre elementos software (componentes) tras la integracindel sistema.

La integracin es la actividad en la cual se combinan los componentes de software

individuales en subsistemas ms amplios. La integracin adicional de subsistemas tambin es parte del proceso de integracin del

sistema.

Cada componente ya ha sido probado en lo referente a su funcionalidad interna (pruebade componente). Las pruebas de integracin comprueban las funciones externas.

Puede ser ejecutada por los desarrolladores y/o los testers

102 de 418


102/417



Pruebas de integracin - Alcance /1

Las pruebas de integracin asumen que los componentes ya han sido probados.

Las pruebas de integracin comprueban la interaccin mutua entre componentes(subsistemas) de software:o Interfaces con otros componentes.

o

Interfaces GUIs / MMIs. Las pruebas de integracin comprueban las interfaces con el entorno del sistema.

o En la mayora de los casos la Interaccin probada es el comportamiento delcomponente y el entorno simulado.

o En condiciones reales factores adicionales del entorno pueden influir en elcomportamiento del componente. Por lo tanto las pruebas de integracin nopueden garantizar un comportamiento correcto en el entorno real del sistema.

Los casos de prueba pueden ser derivados de la especificacin de interfaz, diseoestructural o modelos de datos

103 de 418


103/417




Ser probado un (subsistema) sistema compuesto de componentes Individuales.o Cada componente tiene una Interfaz externa y/o una interfaz que interacta con

otro componente dentro del mismo (subsistema) sistema.

Son necesarios DRIVERSde prueba (los cuales aportan el entorno al proceso del sistema o

subsistema)o Con el objeto de tener en cuenta o producir entradas y salidas del (subsistema)

sistema.o Con el objeto de registrar datos.

Los DRIVERS de prueba propios de las pruebas de componente pueden ser reutilizadas enestas pruebas.

104 de 418


104/417




Herramientas de control (monitoring tools): pueden apoyar las actividades de pruebasregistrando datos y controlando las mismas pruebas.

Un STUBreemplaza un componente faltante.

o

Un STUB programado reemplazar datos o funcionalidad de un componente quean no ha sido integrado.o Un STUBasumir las tareas elementales de un componente faltante.

105 de 418


105/417



Pruebas de integracin - Enfoque

El propsito de las pruebas de Integracin es detectar defectos en las interfaces. Laspruebas de integracin comprueban la correcta interaccin entre componentes.o Con el objeto de comprobar, entre otros, aspectos relativos al rendimiento y la

seguridad, requiriendo pruebas adicionales (no funcionales).

Al reemplazar DRIVERS y STUBS de prueba por componentes reales se pueden generarnuevos defectos tales como:o Prdida de datos, manipulacin errnea de dalos o entradas errneas.o El componente involucrado Interpreta los datos de entrada de una manera distinta.o Los dalos son transferidos en un momento incorrecto: antes de tiempo, despus de

tiempo, a una frecuencia distinta de la requerida.

106 de 418


106/417



Pruebas de integracin - Estrategias /1

Hay diferentes estrategias para las pruebas de Integracin.o El enfoque Incremental es un elemento comn a la mayora de las estrategias (excepcin:

estrategia BIG BANG).o Las estrategias ascendentes (BOTTOM-UP) y descendente (TOP-DOWN) son los utilizados

con mayor frecuencia.

La eleccin de la estrategia debe considerar tambin aquellos aspectos relativos a la eficienciade las pruebas.o La estrategia de integracin determina la magnitud del esfuerzo requerido para las

pruebas (por ejemplo el uso de herramientas, programacin de DRIVERSy STUBS, etc.).o La finalizacin de lo construccin de componentes determina, para todos los tipos de

estrategias, el intervalo temporal en el cual el componente estar disponible. Por lo tanto,la estrategia de desarrollo Influye en lo estrategia de integracin.

En cada proyecto especfico se debe considerar el compromiso entre la reduccin de tiempo yla reduccin de esfuerzo en pruebas:o Probar aquello que se encuentra finalizado: mayores costos en pruebas y menor tiempo

ocioso.o Seguir un plan de pruebas de integracin estricto: menores costos y mayor tiempo ocioso.

107 de 418


107/417



Pruebas de integracin - Estrategias /2

Integracin AD HOC.o Los componentes sern probados, si es posible, inmediatamente despus de haber

sido finalizada su construccin y se hayan finalizado las pruebas de componente.

Caractersticas de la integracin AD HOC.

o

Inicio temprano de las actividades de prueba, dando lugar a un proceso dedesarrollo de software ms corto en trminos globales.o DRIVERS y STUBS sern necesarios dependiendo del tipo de componentes

finalizados.

Uso de la Integracin AD HOC.o Es una estrategia que puede ser aplicada en cualquier etapa del proyecto.o Es una estrategia que normalmente se aplica combinada con otras.

108 de 418


108/417



Pruebas de integracin - Resumen

Integracin significa construir grupos de componentes.

Las pruebas de integracin comprueban la interaccin entre componentes respecto de laespecificacin 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

un forma de integracin.

Cualquier estrategia de integracin distinta a las anteriores es integracin AD HOC.

109 de 418


109/417



Pruebas de Sistema

110 de 418


110/417



Pruebas de Sistema

Base de pruebas:o Especificacin de requerimientos del sistema y del softwareo Casos de usoo Especificacin funcionalo

Informes de anlisis de riesgoo Manuales de operacin del sistema y de usuarioo Configuracin del sistema

Parametrizacin (Datos de configuracin)

111 de 418


111/417



Pruebas de Sistema - Definicin

El proceso de pruebas de un sistema integrado comprueba si cumple con los requisitosespecificados.

Las pruebas del sistema verifica el comportamiento de todo el sistema

El alcance de las pruebas se define en el Plan Maestro de pruebas o en el Plan de niveles

de pruebas Se busca que la calidad del software este determinado por el punto de vista del usuario

Pruebas del sistema se refieren (segn ISO 9126)o Requisitos funcionales (funcionalidad y no funcionales (fiabilidad, usabilidad,

eficiencia, mantenibilidad, portabilidad)

Las caractersticas de la calidad de los datos son las bases para las pruebas

Los casos de prueba se pueden derivar de:

Especificaciones funcionales Casos de uso

Procesos de negocio

Informes de anlisis de riesgo

112 de 418


112/417



Pruebas de SistemaAlcance

Pruebas de un sistema integrado desde el punto de vista del usuario.o Implementacin completa y correcta de los requerimientos.o Despliegue en el entorno real del sistema con datos reales.

El entorno de pruebas debera coincidir con el entorno real.

o

No son necesarios STUBS o DRIVERS.o Todas las interfaces externas son probadas en condiciones reales.o Emulacin prxima al futuro entorno real del sistema

No se realizan pruebas en el entorno realo Los defectos inducidos podran daar el entorno real.o Un software objeto de despliegue se encuentra en un estado de cambio constante.

Muchas pruebas no sern reproducibles.

113 de 418


113/417



Pruebas de SistemaRequerimientos funcionales /1

Objetivo: comprobar que la funcionalidad implementada expone las caractersticasrequeridas.

Las caractersticas a ser probadas incluyen (segn ISO 9126):o Adecuacin/idoneidad (Suitability).

Las funciones Implementadas son adecuadas paro su uso esperado?o Exactitud (Accuracy).

Las funciones presentan los resultados correctos (acordados)?o Interoperabilidad (Interoperabilit

Curso ISTQB Español

Documents

Transcript of Curso ISTQB Español