0 - I - Istqb CTFL

Luis Mercadal & Asociados
Curso Oficial de ISTQB Certified Tester Foundation Level

- Probador de Software Certificado de Nivel Fundamentos -
Introduccin + Fundamentos de Pruebas

0 - Introduccin
El presente curso se ha desarrollado de acuerdo con el ltimo Programa de Estudio (2010) de ISTQB
Certified Tester Foundation Level (CTFL)
Consta de siete captulos:
- Captulo 0
- Captulo I
- Captulo II
- Captulo III
- Captulo IV
- Captulo V
- Captulo VI
Introduccin
Fundamentos de Pruebas
Pruebas a travs del Ciclo de Vida del Software
Tcnicas Estticas
Tcnicas de Diseo de Pruebas
Gestin de Pruebas
Herramientas de Pruebas
Captulo I - Fundamentos de pruebas
I/ 01 Porqu son necesarias las pruebas?

I/02 Qu son las pruebas?
I/03 Siete principios del proceso de pruebas
I/04 Proceso de pruebas bsico
I/05 Psicologa en el proceso de pruebas
I/06 Cdigo tico
Captulo II - Pruebas a travs del ciclo de vida del software
II/01 Modelos de desarrollo de software

II/02 Niveles de prueba
II/03 Tipos de prueba
II/04 Pruebas de mantenimiento
Captulo III - Tcnicas estticas
III/01 Tcnicas estticas y el proceso de pruebas

III/02 Proceso de revisiones
III/03 Anlisis esttico con herramientas
www.luismercadal.com.ar | info@luismercadal.com.ar

Captulo IV - Tcnicas de diseo de pruebas
IV/01 Proceso de desarrollo de prueba

IV/02 Categoras de las tcnicas de diseo de prueba
IV/03 Tcnicas basadas en la especificacin o de caja negra
IV/04 Tcnicas basadas en la estructura o de caja blanca
IV/05 Tcnicas basadas en la experiencia
IV/06 Seleccin de las tcnicas de prueba
Captulo V - Gestin de pruebas
V/01 Organizacin de prueba

V/02 Planificacin y estimacin del proceso de prueba
V/03 Seguimiento y control del estado de las pruebas
V/04 Gestin de la configuracin
V/05 Riesgo y proceso de prueba
V/06 Gestin de incidencias
Captulo VI - Herramientas de pruebas
VI/01 Tipos de herramientas de prueba

VI/02 Uso efectivo de herramientas de prueba
VI/03 Introduccin de herramientas de prueba en una organizacin
ISTQB - International Software Testing Qualifications Board - www.istqb.org

El Comit Internacional de Certificaciones de Pruebas de Software es una organizacin
internacional sin fines de lucro, creada en Noviembre de 2002, en Edimburgo (Escocia), y registrada
legalmente en Blgica, basada en el trabajo voluntario de cientos de expertos en pruebas de software a
nivel mundial.
Es responsable del esquema internacional de certificacin profesional denominado "ISTQB Certified
Tester" (Probador de Software Certificado del ISTQB)
Suministra el Programa de Estudio y el Glosario en los cuales se definen los estndares
internacionales por nivel y se establecen las guas para la acreditacin y evaluacin de los profesionales
de las pruebas de software a cargo de los comits de cada pas.
Ms de 295.000 profesionales certificados en todo el mundo.
Niveles de Certificacin del ISTQB
Foundation Level
Advanced Level
Expert Level
www.lmercadal.blogspot.com.ar/2012/12/niveles-de-certificacion-del-istqb.html
www.lmercadal.blogspot.com.ar/2013/07/estructura-de-los-examenes-del-istqb.html

HASTQB - Hispanic America Software Testing Qualifications Board - www.hastqb.org

En Hispanoamrica, el Comit Hispanoamericano de Certificaciones de Pruebas de Software es el
representante oficial del ISTQB.
El HASTQB es una asociacin jurdica trans-sectorial y trans-nacional sin fines de lucro fundada por
empresas, instituciones, organizaciones y personas especializadas en el campo de las pruebas de
software y la industria del software.
iSQI - International Software Quality Institute - www.isqi.org
El Instituto Internacional de Calidad de Software es una empresa alemana, proveedor de exmenes
de certificacin, lder en el mundo.
El iSQI es responsable de supervisar los exmenes del ISTQB tanto por computadora como
presenciales, en papel.
ISTQB Certified Tester Foundation Level + ISTQB-BCS Certified Tester Foundation Level
ISTQB - International Software Testing Qualifications Board
BCS - The Chartered Institute for IT
La BCS (British Computer Society) es una organizacin profesional y una sociedad cientfica que
representa a quienes trabajan en las Tecnologas de la Informacin y las Comunicaciones en el Reino
Unido e internacionalmente. Fue establecida en 1957, y en 2009 se renombr como BCS - The
Chartered Institute for IT.
En octubre de 2011, el ISEB (Information Systems Examination Board) se renombr como BCS
Professional Certification, y entonces el logo de BCS Professional Certification substituy al logo de
ISEB en toda la correspondencia y los certificados de la BCS.
www.lmercadal.blogspot.com.ar/2012/11/istqb-y-bcs-una-doble-certificacion.html
Objetivos de Aprendizaje / Niveles de Conocimiento

Nivel 1 (K1) - Recordar, reconocer, retener
Nivel 2 (K2) - Entender, explicar, razonar, comparar. clasificar, categorizar, dar ejemplos, resumir
Nivel 3 (K3) - Aplicar, utilizar
Nivel 4 (K4) - Analizar
Objetivos de Aprendizaje / Niveles de Conocimiento por captulo

I - Fundamentos de Pruebas (K1 y K2)
II - Pruebas a travs del Ciclo de Vida del Software (K2)
III - Tcnicas Estticas (K1 y K2)
IV - Tcnicas de Diseo de Pruebas (K1, K2, K3 y K4)
V - Gestin de Pruebas (K1, K2 y K3)
VI - Herramientas de Pruebas (K1 y K2)

Captulo I - Fundamentos de Pruebas
Contenido
Captulo I - Fundamentos de pruebas

I/06 Cdigo tico
Software
Programas, procedimientos y documentacin y datos asociados, relacionados con la operacin de

un sistema informtico
Conjunto de tres componentes:

Programas (instrucciones)
Estn escritos usando lenguajes especficos que las computadoras pueden leer y
ejecutar
Los programas proporcionan la funcionalidad requerida manipulando datos
Datos
Datos necesarios para manejar y probar los programas y las estructuras requeridas
para mantener y manipular estos datos
Documentos
Documentos como manuales de usuario y de operacin son necesarios para permitir

a los usuarios operar con el sistema
Los documentos tambin son requeridos por las personas encargadas de mantener el
software

La importancia econmica del software
El funcionamiento de maquinaria y equipamiento depende en gran medida de software
No es posible imaginar grandes sistemas, en el mbito de las finanzas ni el control de trfico

automotor, entre otros, funcionando sin software
Calidad del software
Cada vez ms, la calidad del software se ha convertido en un factor determinante del xito de
sistemas tcnicos o comerciales
Pruebas para la mejora de la calidad
Las pruebas y revisiones aseguran la mejora de la calidad del software as como de la calidad del
proceso de desarrollo en s
Ejemplo de falla 1: Lanzamiento del Ariane 5

El Vuelo 501, tuvo lugar el 4 de junio de 1996, fue la primera prueba de vuelo del sistema desechable
de lanzamiento del Ariane 5 (cohete que contena 4 satlites)
NO fue un xito, la lanzadera se destruy 37 segundos despus del lanzamiento debido a un mal
funcionamiento en el software de control, haciendo del mismo uno de los defectos de software ms
caros de la historia.
Ejemplo de falla 2: Rayos X letales
La Therac-25 era una mquina de radioterapia producida por la Atomic Energy of Canada Limited
(AECL)
Estuvo implicada en al menos seis accidentes entre 1985 y 1987.
Pacientes recibieron dosis extremas de radiacin durante sus tratamientos, resultando en lesiones
graves o la muerte, debido a defectos en el software.
Causas de Fallas en el Software

Error Humano
Un defecto ha sido introducido por una persona en el cdigo, en los datos, en los parmetros de
configuracin, en un documento
Cdigos complejos, plazos de entrega ajustados, distracciones, demandas excesivas, estrs
Condiciones Ambientales
Cambios en las condiciones ambientales pueden producir un mal funcionamiento del hardware
donde se est ejecuta el software
Radiacin, magnetismo, polucin, fluctuaciones en el suministro de energa elctrica

Error, Defecto, y Falla
Error (equivocacin)
Accin humana que produce un resultado incorrecto.
Defecto (bug, falta, problema)

Desperfecto en un componente o sistema que puede causar que el componente o sistema
falle.
Falla (fallo, fallo de prueba)

Desviacin del componente o del sistema respecto de prestacin, servicio o resultado
esperado.
El rol de las pruebas de software en el desarrollo, mantenimiento y operaciones
Contribuir a la calidad del producto software
Reducir el riesgo de complicaciones durante las operaciones
Cumplir con requisitos contractuales o legales, o estndares especficos del sector
El costo de los defectos
El costo de eliminar defectos se incrementa con el tiempo de permanencia del defecto en el sistema
La deteccin de defectos en etapas tempranas permite la correccin de los mismos a costos

reducidos
Ms se demoren en encontrar un defecto, ms costoso ser repararlo

Pruebas y Calidad
Desde el principio de la ingeniera de software, se observ que la calidad est compuesta por una
composicin de muchas caractersticas.
Un modelo de calidad describe entonces estas caractersticas y sus relaciones.
El estndar ISO/IEC 9126-1 propone las siguientes 6 caractersticas de calidad interna y externa:
Funcionalidad
Atributos funcionales de la calidad
Fiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Atributos no-funcionales de la calidad
ISO/IEC 9126-1
ISO (International Organization for Standardization)
IEC (International Electrotechnical Commission)
ISO/IEC 9126-1:2001 - Software Engineering -- Product Quality -- Part 1: Quality Model
ISO/IEC 25010:2011 - Systems and Software Engineering -- Systems and software Quality
Requirements and Evaluation (SQuaRE) -- System and Software Quality Models
El estndar ISO/IEC 25010 reemplaza y actualiza al estndar ISO/IEC 9126-1

Atributos Funcionales de la Calidad

Funcionalidad significa:
Correccin
Completitud
La funcionalidad satisface los atributos / capacidades requeridos

La funcionalidad satisface todos los requisitos (funcionales)
Subcaractersticas de Funcionalidad
Adecuacin - atributos que determinan si el conjunto de funciones son apropiadas para las tareas
especificadas
Exactitud - atributos que determinan que los efectos sean los correctos o los esperados
Interoperabilidad - atributos que miden la habilidad de interactuar con sistemas especificados
Seguridad (seguridad de acceso) - atributos que miden la habilidad para prevenir accesos no
autorizados, ya sea accidentales o deliberados, a programas y/ o a datos
Cumplimiento (conformidad, adherencia a normas) - atributos que hacen que el software adhiera a
estndares relacionados con la aplicacin, y convenciones o regulaciones legales
Atributos No-Funcionales de la Calidad

Fiabilidad (confiabilidad)
Conjunto de atributos que se relacionan con la capacidad del software de mantener su nivel de
rendimiento bajo las condiciones establecidas por un perodo de tiempo.
Subcaractersticas de Fiabilidad
Madurez - atributos que se relacionan con la frecuencia de fallas por defectos en el software
Tolerancia a Fallas (tolerancia a fallos) - atributos que miden la habilidad de mantener el nivel
especificado de rendimiento en caso de fallas del software
Recuperabilidad (recuperacin, capacidad de recuperacin) - atributos que miden la capacidad de
restablecer el nivel de rendimiento y recuperar datos en caso de falla, y el tiempo y esfuerzo necesario
para ello

Usabilidad
Conjunto de atributos que se relacionan con el esfuerzo necesario para usar, y en la evaluacin
individual de tal uso, por parte de un conjunto especificado o implcito de usuarios.
Subcaractersticas de Usabilidad
Comprensin (entendimiento, capacidad de ser entendido, fcil comprensin) - atributos que
miden el esfuerzo del usuario en reconocer el concepto lgico del software y su aplicabilidad
Aprendizaje (capacidad para ser aprendido, fcil aprendizaje) - atributos que miden el esfuerzo del
usuario en aprender la aplicacin (control, operacin, entrada, salida)
Operabilidad (operatividad, capacidad para ser operado) - atributos que miden el esfuerzo del
usuario en operar y controlar el sistema
Atractividad (software atractivo, capacidad de atraccin)
Eficiencia
Conjunto de atributos que se relacionan con el nivel de rendimiento del software y la cantidad de
recursos usados, bajo las condiciones establecidas.
Subcaractersticas de Eficiencia
Comportamiento Temporal (en tiempo, comportamiento frente al tiempo, comportamiento de
tiempos) - atributos que miden la respuesta y tiempos de procesamiento de las funciones
Utilizacin de Recursos (en recursos, uso de recursos) - atributos que miden la cantidad de recursos
usados y la duracin de tal uso en la ejecucin de las funciones
10

Mantenibilidad (facilidad de mantenimiento, capacidad de mantenimiento)

Conjunto de atributos que se relacionan con el esfuerzo en realizar modificaciones.
Subcaractersticas de Mantenibilidad
Analizabilidad (capacidad de/ para ser analizado) - atributos que miden el esfuerzo necesario para el
diagnstico de deficiencias o causas de fallas, o para identificacin de las partes que deben ser
modificadas
Cambiabilidad (facilidad para el cambio, capacidad para ser cambiado) - atributos que miden el
esfuerzo necesario para realizar modificaciones, remocin de fallas o cambios en el contexto
Estabilidad - atributos que se relacionan con el riesgo de efectos no esperados en las modificaciones
Testeabilidad (facilidad de prueba, capacidad para ser probado) - atributos que miden el esfuerzo
necesario para validar el software modificado
Portabilidad
Conjunto de atributos que se relacionan con la habilidad del software para ser transferido de un
ambiente (entorno) a otro.
Subcaractersticas de Portabilidad
Adaptabilidad - atributos que miden la oportunidad de adaptacin a diferentes ambientes sin aplicar
otras acciones que no sean las provistas para el propsito del software
Instalabilidad (facilidad de instalacin) - atributos que miden el esfuerzo necesario para instalar el
software en el ambiente especificado
Conformidad - atributos que miden si el software se adhiere a estndares o convenciones relacionados
con portabilidad
Reemplazabilidad (facilidad de reemplazo, capacidad para ser reemplazado) - atributos que se
relacionan con la oportunidad y esfuerzo de usar el software en lugar de otro software en su ambiente
Atributos de la Calidad
Algunos atributos de la calidad de un producto software se influyen mutuamente.

Debido a esta interdependencia y en funcin del objeto de prueba, los atributos debern ser
caracterizados por una prioridad. Por ejemplo, Eficiencia versus Portabilidad
Se realizarn distintos tipos de prueba con el objeto de medir distintos tipos de atributo.
11

Cuntas pruebas son suficientes? Cundo finalizar las pruebas?

Se deben tener en cuenta:
Niveles de riesgo
Riesgos tcnicos, de seguridad, comerciales
Limitaciones del proyecto
Tiempo, presupuesto
Las pruebas deben brindar la suficiente informacin para que se puedan tomar decisiones sobre
el sistema / software
Pasar a la siguiente fase de prueba
Entregar el producto software al cliente
Probar significa ms que ejecutar pruebas
La ejecucin de la prueba es solo una parte de todas actividades de pruebas
El proceso de prueba incluye:
Planificar y Controlar
Seleccionar las condiciones de las pruebas
Disear y ejecutar casos de prueba
Comprobar los resultados
Evaluar los criterios de salida
Elaborar informes sobre el proceso de pruebas y sobre el sistema probado
Finalizar o completar actividades de cierre
Revisar documentos (incluyendo el cdigo fuente)

Realizar anlisis estticos
12

Objetivos de las Actividades de Pruebas

Detectar defectos
Las pruebas se realizan para detectar defectos.
Detectar defectos permite identificar los riesgos asociados con un software.
Ganar confianza acerca del nivel de calidad y proporcionar informacin
Las pruebas se realizan para confirmar que un software funciona como se esperaba y que cumple
con los requerimientos establecidos.
La informacin generada permite a los interesados tomar decisiones con base en informacin
concreta acerca del software.
Prevenir defectos
Disear pruebas, encontrar defectos temprano en un ciclo de vida del proyecto y realizar
revisiones de documentos previenen que aparezcan defectos en el software.
Pruebas y Depuracin
Probar y repetir la prueba (re-test) son actividades propias del proceso de pruebas
Las pruebas muestran las fallas
La repeticin de pruebas (pruebas de confirmacin) verifica que el defecto ha sido corregido
Depuracin (debugging) es el proceso de encontrar, analizar y eliminar las causas de las fallas en
el software
La depuracin y la correccin de defectos son actividades propias del desarrollador
13

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 presencia de una
falla
La causa de una falla 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 permanezcan sin ser
detectados. La ausencia de fallas no demuestran la correccin del software
El mismo proceso de pruebas puede contener errores
Las condiciones de prueba pueden ser inapropiadas para detectar defectos
Principio 2
No es posible realizar pruebas exhaustivas
Probar todas las combinaciones posibles de valores de entrada y precondiciones slo es

econmicamente viable en casos triviales
En condiciones reales, se utilizan generalmente pruebas de muestra
Pruebas exhaustivas
Enfoque de pruebas donde el conjunto de pruebas abarca todas las combinaciones posibles de
valores de entrada y precondiciones.
Explosin de casos de prueba

Define el incremento exponencial de esfuerzo y coste en el caso de pruebas exhaustivas
Prueba de muestra
La prueba incluye solamente a un subconjunto de todas las combinaciones posibles de
valores de entrada y precondiciones
14

Principio 3
Pruebas tempranas
Cuanto ms temprana es la deteccin de un defecto, menos costosa es su correccin
Se obtiene una mxima rentabilidad cuando los defectos son corregidos antes de la
implementacin
Los conceptos y especificaciones tambin pueden ser probados
Los defectos detectados en la fase de concepcin son corregidos con menor esfuerzo y
costo
Las actividades de pruebas pueden ser preparadas antes de que el desarrollo se haya completado
Las actividades de pruebas (incluidas las revisiones) deben ser ejecutadas en paralelo a la
especificacin y diseo del software
Principio 4
Agrupamiento de defectos
Encuentre un defecto y encontrar ms defectos cerca del mismo
Los defectos aparecen agrupados como hongos o cucarachas
Vale la pena investigar un mismo mdulo donde se ha detectado un defecto
Los probadores (testers) deben ser flexibles
Principio 5
Paradoja del pesticida
Repetir pruebas con las mismas condiciones no es efectivo
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 de cdigo
Es necesario repetir una prueba tras una modificacin del cdigo (correccin de defectos, nueva
funcionalidad)
La automatizacin de pruebas puede resultar conveniente si un conjunto de casos de prueba se

debe ejecutar frecuentemente
15

Principio 6
Las pruebas dependen del contexto
Las pruebas se realizan de forma diferente en diferentes contextos
Objetos de prueba diferentes son probados de forma diferente
El controlador del motor de un camin requiere pruebas diferentes respecto de aquellas para una
aplicacin de comercio electrnico
Ambiente de Prueba vs. Ambiente de Produccin
Las pruebas tienen lugar en un ambiente distinto del ambiente de produccin
Siempre habr desviaciones entre el ambiente de pruebas y el ambiente de produccin.

Estas desviaciones pueden poner en tela de juicio las conclusiones que se obtuvieran tras
las pruebas.
Principio 7
La falacia de la ausencia de errores
Un proceso de pruebas adecuado detectar los defectos ms importantes
En la mayora de los casos, el proceso de pruebas no detectar todos los defectos del sistema
(Principio 2 - No es posible realizar pruebas exhaustivas), pero los defectos ms importantes
deberan ser detectados
El no encontrar defectos no prueba por s solo la calidad del 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 desde el
principio.
16

El proceso de pruebas como proceso dentro del proceso de desarrollo software
Dependiendo del enfoque seleccionado el proceso de pruebas tendr lugar en diferentes puntos del
proceso de desarrollo
Las pruebas constituyen un proceso en s mismas
El proceso de pruebas est determinado por las siguientes fases:
Planificacin y Control de pruebas

Anlisis y Diseo de pruebas
Implementacin y Ejecucin de pruebas
Evaluacin de los criterios de salida e Informes de pruebas
Actividades de cierre de pruebas
Las fases del proceso de pruebas se podrn superponer.
El proceso de pruebas a lo largo del proceso de desarrollo software
El proceso de pruebas es ms que la ejecucin de pruebas!
Incluye superposicin y vuelta atrs
Cada fase del proceso de pruebas tiene lugar de forma concurrente con las fases del proceso de
desarrollo software
17

Control de Pruebas
Compara el progreso actual con lo planificado
Informa estado y desviaciones respecto a lo planificado
Si fuera necesario, inicia acciones necesarias para ajustarse a la misin y objetivos del proyecto
De cara al control de pruebas, estas acciones deben ser monitorizadas a lo largo del proyecto
La planificacin de pruebas tiene en cuenta la realimentacin de las actividades de monitorizacin y
control.
Se basa en las siguientes tareas fundamentales:
Medida y anlisis de resultados
Monitorizacin y documentacin del progreso, cobertura de pruebas y criterios de salida
Iniciacin de acciones correctivas
Toma de decisiones
Planificacin de Pruebas
Identifica la misin de la prueba, definiendo los objetivos de la prueba y la especificacin de las
actividades de cara a cumplir los objetivos y completar la misin.
Tiene en cuenta la realimentacin de las actividades de monitorizacin y control.
Se basa en las siguientes tareas fundamentales:
Determinacin del alcance y riesgos, e identificacin de objetivos de la prueba
Determinacin de tcnicas, tems, cobertura, identificacin y definicin de la interfaz entre los

equipos implicados en la prueba
Determinacin de los recursos requeridos (personal, PCs, etc.)
Implementacin de las polticas y/o de la estrategia de la prueba
Planificacin del anlisis y de las tareas de diseo
Planificacin de la implementacin, ejecucin y evaluacin de la prueba
Determinacin del criterio de salida
18

Anlisis y Diseo de Pruebas

Los objetivos generales de la prueba son transformados en condiciones de pruebas tangibles y diseos
de pruebas.
Contiene las siguientes tareas fundamentales:
Revisar las bases de prueba (requisitos, arquitecturas, diseo, interfaces)
Evaluar la testeabilidad de los requisitos y sistema
Identificar y priorizar las condiciones de pruebas o requisitos y datos requeridos de la prueba

basados en los tems de la prueba, la especificacin, comportamiento y estructura
Disear y priorizar casos de prueba de alto nivel
Disear la configuracin del ambiente de pruebas e identificar cualquier infraestructura o

herramienta requerida
Crear una trazabilidad bidireccional entre la base de pruebas y los casos de prueba
Implementacin y Ejecucin de Pruebas

Es la actividad donde las condiciones son transformadas en casos de prueba, se configura el ambiente
de pruebas, y se ejecutan las pruebas.
Contiene las siguientes tareas fundamentales:
Finalizar, implementar y priorizar los casos de prueba
Desarrollar y priorizar casos de prueba, crear datos de prueba
Crear juegos de pruebas a partir de los casos de prueba
Verificar que el ambiente de pruebas ha sido correctamente configurado
Verificar y actualizar una trazabilidad bidireccional entre la base de pruebas y los casos de
prueba
Ejecutar los casos de prueba manualmente o de forma automtica
Comparar los resultados reales con los resultados esperados
Reportar discrepancias en forma de incidencias y analizarlas con vistas a establecer sus causas
Repetir las actividades de prueba como resultado de una medida adoptada para cada incidencia
Repetir actividades de prueba para confirmar una correccin

Ejecutar prueba de regresin
19

Evaluacin de los Criterios de Salida e Informes

Posee las siguientes tareas:
Evaluar la ejecucin de la prueba con respecto a objetivos definidos (por ejemplo, criterios de
salida) en la planificacin de la prueba
Evaluar si son necesarias ms pruebas o si los criterios de salida deben ser modificados
Elaborar un informe resumen de las pruebas para enviar a las partes interesadas
Actividades de Cierre de Pruebas

Recogen todos los datos de las actividades de prueba completadas para consolidar experiencia, hechos
y nmeros.
Incluyen las siguientes tareas:
Comprobar qu entregables planificados han sido entregados
Cerrar los informes de defectos o elevar informes de cambios para defectos que se mantienen
abiertos
Documentar la aceptacin del sistema
Finalizar y archivar los productos de soporte de prueba (testware) para su posterior uso
Entregar los productos de soporte de prueba a la organizacin de mantenimiento
Analizar las lecciones aprendidas para futuras versiones y proyectos
Utilizar la informacin recopilada para mejorar la madurez de las pruebas
Roles y Responsabilidades
Desarrollador
Implementa requisitos
Desarrolla estructuras
Disea y programa el software
Su xito consiste en la creacin de un producto software
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
20

Percepcin
La actividad del desarrollador es constructiva! La actividad del probador es destructiva!
Error!
Las pruebas tambin constituyen una actividad constructiva,
su propsito es la eliminacin de defectos en un producto software!
Caractersticas personales de un buen probador (tester)
Curioso, perceptivo, atento a los detalles - no todo error se manifiestan de forma evidente
Con el objeto de comprender los escenarios prcticos del cliente
Con el objeto de poder analizar la estructura de la prueba
Con el objeto de descubrir detalles de dnde se pueden manifestar fallas
Escptico y con actitud crtica
Los objetos de prueba contienen defectos. Usted solo debe encontrarlos
No creer todo lo dicho por los desarrolladores
No se debe temer al hecho de que se pudieran detectar defectos de importancia que

pudieran tener un impacto sobre la evolucin del proyecto
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 del sistema, deben ser entendidas
y comunicadas
Una comunicacin positiva puede ayudar a evitar o facilitar situaciones difciles
Para establecer una relacin de trabajo con los desarrolladores a corto plazo
Experiencia
Factores personales influyen en la ocurrencia de errores
La experiencia ayuda a identificar dnde se pueden acumular errores
21

Pruebas Independientes
La separacin de las responsabilidades en el proceso de pruebas apoya / promueve la evaluacin

independiente de los resultados de las pruebas
En el siguiente diagrama se representa el grado de independencia a travs de un grfico de barras:
Organizacin de pruebas - Tipos
Pruebas de desarrollador
- El desarrollador nunca analizar su creacin de forma imparcial (apego afectivo)
Sin embargo, l conoce el objeto de prueba mejor que nadie

Habr costos adicionales debido a la formacin / informacin de otras personas
respecto del objeto de prueba
- Las personas tienden a pasar por alto sus propios defectos
Los desarrolladores corren el riesgo de no reconocer defectos evidentes
- Errores cometidos como consecuencia de una mala interpretacin de los requisitos se

mantendrn sin ser detectados
El establecimiento de grupos de prueba donde los desarrolladores prueben los

productos de otros ayuda a evitar o, al menos, reducir la posibilidad de ocurrencia de
este tipo de anomala
Equipos de desarrollado
- Los desarrolladores hablan el mismo lenguaje

- Los costos de formacin / informacin en lo relativo a objetos de prueba se mantienen en
un nivel moderado, especialmente cuando los equipos intercambian objetos de prueba
- Peligro de generacin de conflictos entre equipos de desarrollo
Un desarrollador que busca y encuentra un defecto no ser el mejor amigo del autor
del objeto de prueba analizado
- Mezcla de actividades de desarrollo y pruebas
Cambios frecuentes en la forma de pensar

Dificulta el control del presupuesto del proyecto
Equipos de pruebas
- La creacin de equipos de pruebas que den servicio a diferentes reas de proyecto

mejora la calidad de las pruebas
- Es importante que los equipos de prueba de diferentes reas en el proyecto trabajen de
forma independiente
22

Subcontratacin de pruebas (externalizacin)
- La separacin de las actividades de pruebas y desarrollo aportan la mxima

independencia entre los objetos de prueba y el probador
- Las actividades de pruebas subcontratadas (externalizadas) son ejecutadas por personal

con un conocimiento relativamente pequeo de los objetos de prueba y de los
antecedentes del proyecto
-La curva de aprendizaje implica altos costes, por lo tanto, se deberan involucrar a
expertos independientes en etapas tempranas del proyecto
- Los expertos externos cuentan con un alto nivel de conocimiento (know how) del
proceso de pruebas
-Est asegurado un diseo de pruebas apropiado

-Se alcanza la optimizacin en el uso de mtodos y herramientas
Dificultades
Incapacidad de comprensin mutua
- Los desarrolladores deberan contar con un conocimiento bsico de pruebas

- Los probadores (testers) deberan contar con un conocimiento bsico de desarrollo software
-
Especialmente en situaciones de tensin, la deteccin de errores cometidos por alguien

frecuentemente conduce a conflictos
- La forma de documentar los defectos y la forma en la cual el defecto es descrito determinar

cmo se desarrollar la situacin
- Las personas no deberan ser criticadas, los defectos deben ser descritos en trminos
objetivos
- La descripcin de los defectos debera ayudar al desarrollador a encontrar el error
- Los objetivos comunes siempre deben ser la cuestin principal
La comunicacin entre probadores y desarrolladores es insuficiente o inexistente. Este hecho

puede hacer imposible el trabajo conjunto
- Los probadores son vistos nicamente como portadores de malas noticias

- Mejora: intente ponerse en el lugar (rol) de la otra persona
-
Un proceso de pruebas slido requiere la distancia apropiada con respecto al objeto de

prueba
- Se adquiere un punto de vista independiente e imparcial a travs de la distancia con respecto

al desarrollo
- 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
23

I/06 Cdigo tico
Cdigo de Conducta
Los individuos involucrados en el proceso de pruebas software tienen acceso a informacin muy
privilegiada y crtica. El cdigo de tica es necesario para asegurar que la informacin es utilizada de
forma apropiada.
Pblico
Los probadores de software certificados actuarn en coherencia con el inters pblico.
Cliente y Empleador
Los probadores de software certificados actuarn en el mejor de los intereses de su cliente y empleador,
en coherencia con el inters pblico.
Producto
Los probadores de software certificados garantizarn que los productos entregables que proporcionan
(por lo que respecta a los productos y sistemas que prueban) se ajustan a los ms altos estndares
profesionales.
Criterio
Los probadores de software certificados mantendrn la integridad y la independencia en su criterio/
juicio profesional.
Gestin
Los jefes y lderes de pruebas de software certificados suscribirn y fomentarn un enfoque tico en la
gestin de las pruebas de software.
Profesin
Los probadores de software certificados aumentarn la integridad y la reputacin de la profesin en
coherencia con el inters pblico.
Compaeros
Los probadores de software certificados sern equitativos y apoyarn a sus compaeros fomentando la
cooperacin con los desarrolladores de software.
Nivel Individual
Los probadores de software certificados participarn en un aprendizaje a lo largo de toda la vida por lo
que respecta a la prctica de su profesin y fomentarn la adopcin de un enfoque tico en la prctica
de su profesin.
24

0 - I - Istqb CTFL

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

0 - I - Istqb CTFL

Transféré par

Droits d'auteur :

Formats disponibles

Luis Mercadal & Asociados

Curso Oficial de ISTQB Certified Tester Foundation Level

Introduccin + Fundamentos de Pruebas

Luis Mercadal & Asociados

Captulo I - Fundamentos de pruebas

I/ 01 Porqu son necesarias las pruebas?

Captulo II - Pruebas a travs del ciclo de vida del software

II/01 Modelos de desarrollo de software

Captulo III - Tcnicas estticas

III/01 Tcnicas estticas y el proceso de pruebas

Luis Mercadal & Asociados

Captulo IV - Tcnicas de diseo de pruebas

IV/01 Proceso de desarrollo de prueba

Captulo V - Gestin de pruebas

V/01 Organizacin de prueba

Captulo VI - Herramientas de pruebas

VI/01 Tipos de herramientas de prueba

ISTQB - International Software Testing Qualifications Board - www.istqb.org

Luis Mercadal & Asociados

HASTQB - Hispanic America Software Testing Qualifications Board - www.hastqb.org

Objetivos de Aprendizaje / Niveles de Conocimiento

Objetivos de Aprendizaje / Niveles de Conocimiento por captulo

Luis Mercadal & Asociados

Captulo I - Fundamentos de Pruebas

I/ 01 Porqu son necesarias las pruebas?

I/ 01 Porqu son necesarias las pruebas?

Programas, procedimientos y documentacin y datos asociados, relacionados con la operacin de

Conjunto de tres componentes:

Los programas proporcionan la funcionalidad requerida manipulando datos

Documentos como manuales de usuario y de operacin son necesarios para permitir

Luis Mercadal & Asociados

La importancia econmica del software

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

No es posible imaginar grandes sistemas, en el mbito de las finanzas ni el control de trfico

Calidad del software

Pruebas para la mejora de la calidad

Ejemplo de falla 1: Lanzamiento del Ariane 5

Causas de Fallas en el Software

Luis Mercadal & Asociados

Error, Defecto, y Falla

Defecto (bug, falta, problema)

Falla (fallo, fallo de prueba)

El rol de las pruebas de software en el desarrollo, mantenimiento y operaciones

Contribuir a la calidad del producto software

Reducir el riesgo de complicaciones durante las operaciones

Cumplir con requisitos contractuales o legales, o estndares especficos del sector

El costo de los defectos

La deteccin de defectos en etapas tempranas permite la correccin de los mismos a costos

Ms se demoren en encontrar un defecto, ms costoso ser repararlo

Luis Mercadal & Asociados

Un modelo de calidad describe entonces estas caractersticas y sus relaciones.

Atributos funcionales de la calidad

Atributos no-funcionales de la calidad

ISO (International Organization for Standardization)

IEC (International Electrotechnical Commission)

ISO/IEC 9126-1:2001 - Software Engineering -- Product Quality -- Part 1: Quality Model

El estndar ISO/IEC 25010 reemplaza y actualiza al estndar ISO/IEC 9126-1

Luis Mercadal & Asociados

Atributos Funcionales de la Calidad

La funcionalidad satisface los atributos / capacidades requeridos

Atributos No-Funcionales de la Calidad

Luis Mercadal & Asociados

Luis Mercadal & Asociados