Capítulo No. 1

18/10/2020
ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS
NO ESTÁ AUTORIZADO SU USO COMERCIAL

PREPARACIÓN PARA
LA CERTIFICACIÓN
ISTQB NIVEL BÁSICO
BIENVENIDOS!!!!
APLICAN ACUERDOS DE CONFIDENCIALIDAD

PROHIBIDO
• Grabar el curso
• Compartir el material
• Más de una persona por computador

EMPEZAMOS!!!!
1
18/10/2020


0. GENERALIDADES
Introducción

¿QUÉ ES ISTQB?
International Software Testing Qualifications Board
El Comité Internacional de Certificaciones de Pruebas de

Software es una organización internacional sin fines de lucro,
creada en Noviembre de 2002, en Edimburgo, y registrada
legalmente en Bélgica, basada en el trabajo voluntario de
cientos de expertos en pruebas de software a nivel mundial. https://www.istqb.org/

¿QUE ES HASTQB?
Hispanic America Software Testing

Qualifications Board.
El HASTQB surge como la localización en Hispano

América del ISTQB®. Esta organización internacional http://hastqb.org/
(ISTQB®), delega en comités miembros alrededor del
mundo la administración de su esquema de
certificaciones (Países o Regiones). 18 Países.
La presidenta es
Colombiana!!!!
2
18/10/2020


¿QUE ES ISQI?
International Software Quality Institute
El Instituto de Calidad de Software Internacional

tiene sus oficinas corporativas en Potsdam
(Alemania), con subsidiarias en Boston (EUA),
Londres (Reino Unido) y Amstelveen (Holanda); es
proveedor líder de exámenes de certificación en
todo el mundo.

¿QUE ES CTFL?
Certified Tester Foundation Level
Es la certificación que van a obtener una vez

terminen este curso, repasen, estudien, presenten
y pasen el examen de certificación con 40/40. CTFL
es lo que van a poner en su HV, LinkedIn, Facebook,
Instagram….

http://hastqb.org/
3
18/10/2020


https://www.istqb.org/
10

¿Por qué la ISTQB® Certified Tester es el

esquema de certificaciones
certificación de con mayor cobertura en el
ISTQB®? mundo, y sus planes de
estudio, contenidos y
glosario se han convertido
en referencia de facto en la
industria para la profesión
de pruebas de Software.
11
Las características del esquema de certificación

incluyen:
• Planes de Estudio de Alta Calidad: Todos los planes de estudio

son desarrollados y revisados por profesionales en pruebas líderes
en la academia e industria.
• Reconocimiento Mundial: Las certificaciones son reconocidas

a nivel mundial debido a la aplicación consistente de las políticas y
procedimientos de ISTQB®, por parte de los comités miembros.
• Lenguaje Común: El glosario de ISTQB® proporciona un

vocabulario común para la profesión.
• Objetividad: la evaluación de las capacidades del probador se

lleva a cabo de forma independiente por ISTQB® y proporciona
verificación objetiva de competencias.
• Adhesión a un Código de Ética: Todos los probadores

certificados por ISTQB® se adhieren al Código de Ética definido
por ISTQB®.
12
4
18/10/2020
Las características del esquema de certificación incluyen:


• Disponibilidad Pública: El glosario y los planes de estudio de
ISTQB® están disponibles gratuitamente en el sitio web de ISTQB®
y en los sitios web de los comités locales.
• Abierta al Público: Los materiales de ISTQB® se desarrollan

sobre una base voluntaria y están abiertos a las contribuciones de
cualquier persona interesada en formar parte de los grupos de
trabajo de ISTQB®.
• Independencia: La naturaleza sin ánimo de lucro de ISTQB®

garantiza que el contenido no está limitado por metodologías o
tecnologías particulares, y es capaz de aprovechar las mejores
prácticas de una amplia variedad de fuentes.
• Mejora Continua: Los planes de estudio y otros documentos

son mejorados continuamente para satisfacer las necesidades de
las organizaciones empresariales de todo el mundo y seguir el
ritmo de desarrollo de la profesión.
• Posicionamiento Profesional: Ser certificado ofrece ventajas

para los individuos y las organizaciones, garantizando que los
profesionales de pruebas cumplen con los altos estándares
establecidos por ISTQB®.
13

¿A quién va dirigida? CTFL
La certificación de nivel Básico está dirigida a profesionales

que necesiten demostrar conocimiento práctico de los
conceptos fundamentales de las pruebas de Software. Esto
incluye personas en roles como: diseñadores de pruebas,
analistas de pruebas, ingenieros de pruebas, consultores,
gerentes de pruebas, probadores de aceptación de usuarios
y profesionales de la industria TI.
La certificación de nivel básico también es apropiada para

cualquier persona que necesite un conocimiento básico de
las pruebas de software, tales como: directores de
proyectos, gerentes de calidad, directores de desarrollo de
software, analistas de negocio, directores de TI y
consultores de gestión.
14

EL EXAMEN
40 preguntas de selección múltiple.
Se otorga 1 punto por cada respuesta correcta.
Un porcentaje de aprobación del 65% requerido (26 puntos o

más).
Una duración de 60 minutos (o 75 minutos para los candidatos

que toman el examen en un idioma diferente a su idioma
nativo o local).
15
5
18/10/2020


CONTENIDO
Temario
https://www.istqb.org/
16
El presente curso se ha desarrollado de acuerdo con el programa

de estudios de Probador Certificado – Nivel Básico (“Certified

Tester Foundation Level”).
Consta de siete capítulos:
• Capítulo 0 Generalidades
• Capítulo I Fundamentos de Pruebas
• Capítulo II Pruebas a través del Ciclo de Vida Software
• Capítulo III Técnicas Estáticas
• Capítulo IV Técnicas de Pruebas
• Capítulo V Gestión de Pruebas
• Capítulo VI Herramientas de Soporte de Prueba
17

CAPÍTULO No.1
FUNDAMENTOS DEL PROCESO
DE PRUEBAS
18
6
18/10/2020

1.1. ¿Qué es probar?

CAPITULO No.1 1.2. ¿Por qué es necesario probar?
1.3. Siete principios de la prueba

Fundamentos del proceso de
pruebas 1.4. Proceso de prueba
1.5. La Psicología de la prueba

1.6. Código de ética
19

El software es una parte de nuestras vidas. Hoy

día todo tiene software (bancos), hospitales,
hasta los productos de consumo
(Automóviles).
¿Te imaginas que pasa si no funcionan como

deben funcionar?
20
¿Sabías que cuando el software no

funciona correctamente puede causar

muchos problemas?
1) Frustración
2) Pérdida de Dinero
3) Pérdida de Tiempo
4) Pérdida de Reputación de la empresa
5) Causar lesiones
6) Incluso la muerte
21
7
18/10/2020


Evitar frustración
22

23
Evitar pérdida$, daños, lesiones,

impactos a la imagen o muerte

Ejemplo de fallo 1:
• Samsung Galaxy Note 7
24
8
18/10/2020
Evitar lesiones o muerte


Ejemplo de fallo 2: Rayos X letales
• Una serie de pacientes recibieron una

dosis letal de radiación debido a un fallo
de software del Therac-25. cada vez que
alguien se tomaba un examen iba
aumentando en 1 la radiación hasta que
se volvió mortal.
25
¡Probar es una forma de evitar y reducir el riesgo de

Cuando nosotros hacemos pruebas y encontrar todo lo que vimos en las diapositivas
anteriores!
evitamos todo eso, básica y

humildemente nos convertimos en….
¡Probar el software es una forma de evaluar la calidad del

software y de reducir el riesgo de fallos en un entorno
de operaciones o en producción.!
26

Probar es mucho más que ejecutar
pruebas y verificar resultados!!!

• Nosotros también:
1) Planeamos la prueba
2) Analizamos
3) Diseñamos
4) Implementamos
5) Ejecutamos
6) Verificamos resultados
7) Informamos el avance
8) Informamos los resultados
9) Evaluamos la calidad del objeto de prueba
27
9
18/10/2020
• ¿Sabes la diferencia entre pruebas

Estáticas y pruebas Dinámicas?

Pruebas estáticas
Estático quiere decir que NO se ejecuta el Objeto de

pruebas
La revisión de documentos, código fuente y la realización

de análisis estático también ayudan a prevenir la
aparición de defectos en el código
28

¡Probar no es solo revisar documentos,

probar también es mirar el software!
A veces creen que nosotros como Tester nos centramos

únicamente en la verificación de requisitos, historias de
usuario u otras especificaciones. Las pruebas ayudan a
comprobar que el sistema cumple con lo que se definió
en los documentos, pero también ayudan a validar que
el sistema cumple las necesidades de los usuarios y
otros implicados en sus entornos de operación.
29
• ¿Sabes la diferencia entre pruebas

Estáticas y pruebas Dinámicas?

Pruebas dinámicas
Dinámico quiere decir que SI se ejecuta el

Objeto de pruebas.
Las pruebas dinámicas nos ayudan a validar

en el sistema, lo que el cliente pidió en los
documentos
30
10
18/10/2020
OBJETIVOS DE LAS
PRUEBAS

Los objetivos de las pruebas pueden incluir pero no están
limitados a:
1. Evaluar productos de trabajo tales como requisitos,

historias de usuario, diseño y código.
2. Verificar el cumplimiento de todos los requisitos
especificados.
3. Validar si el objeto de pruebas está completo y
funciona como los usuarios y otros implicados
esperan.
4. Generar (lograr) confianza respecto del nivel de
Calidad del objeto de pruebas.
5. Prevenir defectos
31
OBJETIVOS DE LAS
PRUEBAS
Los objetivos de las pruebas pueden incluir pero no están limitados a:
6) Encontrar (Detectar) defectos y fallos.
7) Proporcionar (Aportar) suficiente información a los implicados para

que puedan tomar decisiones informadas, especialmente en relación
con el nivel de calidad del objeto de pruebas.
8) Reducir el nivel de riesgo de calidad inadecuada del software (por

ejemplo, fallos que se producen durante la operación que no han sido
detectados anteriormente).
9) Cumplir con requisitos o normas contractuales, legales o

reglamentarias, y/o verificar el cumplimiento de dichos requisitos o
normas por parte del objeto de prueba.
32
Los objetivos de las pruebas pueden variar , dependiendo

del contexto del componente o sistema que se está
probando. También depende del nivel de prueba y el

modelo de ciclo de vida de desarrollo software.
Por ejemplo: incluir pero no están limitados a:
• En las pruebas de componente el objetivo es encontrar la mayor cantidad de

fallos para que sean corregidos los defectos de forma temprana. También un
objetivo es dar la mayor cobertura de pruebas al código.
• En las pruebas de aceptación, un objetivo es asegurar que el sistema está

completo y hace lo que tiene que hacer. Otro objetivo puede ser informar a
los implicados el riesgo de liberar en un momento dado.
33
11
18/10/2020

¿SABÍAS QUE LAS PRUEBAS Y DEPURACIÓN (“DEBUGGING”) SON DIFERENTES?...

DEPURACIÓN (DEBUGGING)
Encontrar Analiza Corrige Repetición de pruebas

Prueba defectos Defectos defectos (re-test)
La ejecución de La depuración es la La prueba de

pruebas puede actividad de desarrollo confirmación (Re-
test, Repetición de pruebas)
mostrar fallos causados por que encuentra (detecta, localiza),
posterior, comprueba si las
defectos del software. analiza y corrige los defectos que correcciones han resuelto
causaron los fallos. los defectos.
Normalmente el Tester hace prueba y re-test. Desarrollo hace Depuración y pruebas de componente (unitarias), pero…..
34
RESUMEN DE LO
• Probar el software es una forma de evaluar la calidad del software y de

VISTO….. reducir el riesgo de fallos en un entorno de operaciones o en
producción.
• Pruebas estáticas no se ejecuta el objeto de pruebas. (HU, requisitos).
• Pruebas dinámicas si se ejecuta el objeto de pruebas. (Aplicaciones,

SW).
• 9 Objetivos de las pruebas pero no están limitados a esos.
• Pruebas y pruebas de confirmación (retest-reprueba-repetición de la

prueba) son tareas propias del tester.
• La depuración (Encontrar, Analizar y corregir) es tarea propia del

desarrollador.
35


CAPITULO No.1 1.2. ¿Por qué es necesario probar?
1.3. Siete principios de la prueba

Fundamentos del proceso de
pruebas 1.4. Proceso de prueba
1.5. La Psicología de la prueba

1.6. Código de ética
36
12
18/10/2020

1.2. ¿Por qué es necesario probar?
Mejora de la calidad de un producto software:


El proceso de prueba ayuda a suministrar/aportar al
software los atributos deseados, por ejemplo retirar
defectos que conducen a fallos
Reducción del riesgo de detectar errores:

Actividades de pruebas software adecuadas
reducirán el riesgo de encontrar errores durante
la fase de operaciones software
Satisfacer compromisos:
La ejecución de pruebas puede ser un requisito
obligatorio por parte del cliente, debido a
normas legales así como al cumplimiento de
estándares propios de una industria
37

Las pruebas contribuyen al éxito del Software
El uso de técnicas adecuadas, en los niveles de pruebas adecuados, con la

experiencia necesaria y en los puntos del ciclo de vida del software correctos,
pueden promover el éxito del proyecto, el éxito del software y de todos los
productos de trabajo.
Por ejemplo:
• Cuando los Tester encontramos defectos en los documentos (Req, HU,etc) y estos se corrigen,
reduce el riesgo que se desarrollen funcionalidades incorrectas.
• Cuando los Tester trabajamos con los diseñadores del sistema, entendemos el sistema,
entendemos como probarlo e identificamos de forma temprana las pruebas a aplicar más
adelante. También podemos encontrar problemas en el diseño.
38

Las pruebas contribuyen al éxito del Software
• Cuando los Tester trabajamos con los desarrolladores, podemos entender el código y su lógica. Entendemos como
probarlo e identificamos de forma temprana las pruebas a aplicar más adelante. También podemos encontrar
problemas en el código.
• Cuando los Tester Verificamos y Validamos el software antes de liberarlo podemos detectar fallos, para que sean
corregidos los defectos.
• Si cumplimos con todos los objetivos que describimos hace unas diapositivas, estamos promoviendo el éxito del
software.
39
13
18/10/2020

ASEGURAMIENTO DE LA CALIDAD (QA – Quality Assurance) Y EL PROCESO DE PRUEBAS


Aseguramiento de la Calidad (QA) y pruebas no son lo mismo, pero están relacionados.
La gestión de la calidad los une.
La gestión de la calidad incluye:
1. Aseguramiento de la calidad. (Procesos)

2. Control de la calidad. (Productos)
Las pruebas aportan en ambos escenarios.
40

ERROR, DEFECTO Y FALLO

ERROR: Pensamiento,
equivocación Humana
DEFECTO: El error se ha
plasmado en un
documento. También
conocido como la FALLO: El defecto no
“Causa de los fallos” fue encontrado y se
Los defectos causan fallos incluyó en el código. La
aplicación falló al
¿Qué encontramos nosotros? ejecutarla
¿Qué corrigen los desarrolladores? APLICAN ACUERDOS DE CONFIDENCIALIDAD
41

CAUSA RAÍZ - DEFECTO - EFECTO

CAUSA RAÍZ: Es el
motivo por el cual se
ocasionó un defecto.
Por ejemplo: Un error,
DEFECTO: El error se ha
cansancio humano,
plasmado en un
definición incorrecta,
documento
etc (D)-EFECTO: Es la
consecuencia de dejar
pasar un defecto
42
14
18/10/2020

¿Porqué se producen los fallos (“failure”) en el software?

Error humano Condiciones ambientales
Un defecto ha sido introducido en el Cambios en las condiciones
código software, en los datos o en los ambientales
parámetros de configuración
Causas de condiciones ambientales
Causas de error humano negativas/adversas
Plazos, demandas excesivas debidas a la Radiación, magnetismo, campos

complejidad, distracciones, participantes electromagnéticos, polución,
sin experiencia, falta de comunicación, manchas solares, fallo de discos
Complejidad, Malos entendidos, Nuevas duros, fluctuaciones en el
tecnologías… suministro de energía eléctrica.
43

No todos los resultados inesperados, son fallos

FALSOS POSITIVOS
Se dan cuando se cometen errores en la forma en que se ejecutaron las pruebas,

o defectos en los datos de prueba, o problemas en el entorno de pruebas, o
problemas con otro producto de prueba, o por muchas razones.
FALSOS NEGATIVOS
Son pruebas que no detectan defectos que deberían haber detectado.
44

• EL COSTO DE ARREGLAR LOS FALLOS EN

PRODUCCIÓN
VEAMOS UN VIDEO
45
15
18/10/2020


coste relativo
de la
corrección de
El coste de los defectos errores
El coste de eliminar defectos

se incrementa con el tiempo
de permanencia del defecto
en el sistema
La detección de defectos en
etapas tempranas permite
la corrección de los mismos
a costes reducidos
Source: B. Boehm (1981)
Especificación Diseño Construcción Pruebas Aceptación

Operación
46

EJEMPLO
AQUÍ SE INYECTÓ
• Especificación $5
• Diseño $4
• Construcción $3
• Pruebas $7
• Aceptación $5
• Operación $3
AQUÍ SE ENCONTRÓ
$ 315
Se debe multiplicar
APLICAN ACUERDOSdesdeDE
donde se ENCONTRÓ hasta donde se INYECTÓ
CONFIDENCIALIDAD
47

ISO 9126 – ISO/IEC 25010

CALIDAD SOFTWARE
¿Qué significa probar la Funcionalidad?:

Corrección (Que esté correcto): La funcionalidad satisface los atributos/capacidades requeridos
Completitud (Que esté completo): La funcionalidad satisface todos los requisitos (funcionales)
Los atributos funcionales de la calidad según la norma ISO/IEC 9126 - ISO/IEC 25010 son:
Precisión y/o Exactitud

Interoperabilidad
Cumplimiento de funcionalidad
Adecuación
Seguridad
P.I.C.A.S.
48
16
18/10/2020

ISO 9126 – ISO/IEC 25010


CALIDAD SOFTWARE
También existen los atributos NO funcionales:
Fiabilidad: Madurez, tolerancia a defectos, recuperabilidad.

Usabilidad: fácil de usar, de aprender, de utilizar
Eficiencia: Como utiliza los recursos disponibles, memoria, etc
Mantenibilidad: va a ser fácil mantenerlo, cambiarlo, probarlo
Portabilidad: Adaptable, instalable, portable, coexistencia
F.U.E.M.P.
49

PARA TENER EN CUENTA:
❖ “Para poder probar los atributos funcionales necesitamos que los atributos NO funcionales se
encuentren estables”
❖ “Los atributos NO funcionales se prueban utilizando la funcionalidad”
❖ “Se realizarán distintos tipos de pruebas con el objeto de medir distintos tipos de atributo”
50

Probador Certificado – Niv el Básico
I. Fundamentos de pruebas
02. ¿Porqué son necesarias las pruebas?
ASEGURAMIENTO DE LA CALIDAD - QA
51
17
18/10/2020


Existen 2 tipos de Aseguramiento de la Calidad (QA):
- Aseguramiento de la calidad (QA) Constructivo: Actividades constructivas con el objeto de prevenir defectos, por
ejemplo a través de la aplicación de métodos apropiados de ingeniería de software
- Aseguramiento de la calidad (QA) Analítico: Actividades analíticas con el objeto de detectar defectos, por ejemplo a
través de pruebas conducentes a la corrección de defectos y prevención de fallos, incrementando así la calidad del software
QA = Quality Assurance
52

Aseguramiento de la calidad constructivo

Proceso de calidad – Gestión de la calidad
Guías Consigna
Estándares
Organización
Listas de comprobación
Reglas de proceso y normas - Los defectos evitados no
Requisitos legales
requieren ser reparados
QA Constructivo
- Los defectos introducidos

en el pasado no deben ser
Métodos repetidos
Herramientas
Técnico
Lenguajes
Listas / plantillas - Se deben prevenir los
Entorno de Desarrollo Integrado (IDE)
defectos
53

Aseguramiento de la calidad analítico

- Calidad de producto – Procedimiento de Verificación y Pruebas
Partición de equivalencia Consigna:

caja negra
Análisis de valores límite

Pruebas de transición de estado - Los defectos deben ser
Tablas de decisión detectados tan pronto como
Pruebas de casos de uso sea posible respecto del
Dinámico
proceso
Técnicas basadas en la experiencia
QA Analítico
Cobertura de sentencia - Pruebas estáticas

caja blanca
Cobertura de rama evaluación sin la ejecución

Cobertura de condición del programa
Cobertura de camino
Revisiones / revisiones guiadas - Pruebas dinámicas incluye

la ejecución del programa
Estático
Análisis del flujo de control

Análisis del flujo de datos
Métricas del compilador / analizador
54
18
18/10/2020

CARACTERÍSTICAS DE LAS PRUEBAS

1. Adquirir conocimiento sobre los defectos en un objeto de prueba (“test object”)
Los defectos contenidos en un objeto de prueba deben ser detectados y descritos de tal forma que se facilite su corrección
2. Confirmación de la funcionalidad
La funcionalidad del sistema debe ser implementada tal y como ha sido especificada
3. Generar información
Se debe proporcionar información relativa a los posibles riesgos relativos a un sistema software antes de su entrega a los usuarios. La
obtención de esta información puede ser uno de los objetivos de las pruebas
4. Ganar confianza
Un sistema software que ha sido probado de forma adecuada se considera que cumple con la funcionalidad esperada y cuenta con un
alto nivel de calidad
55

¿Cuantas pruebas son suficientes? - ¿Cuándo debemos parar?

- Cuando se cumplen los Criterios de salida (“exit criteria”) definidos con el cliente
- Cuando probamos lo más riesgoso - Pruebas basadas en riesgos (“risk-based testing”)
- Cuando se acaba el tiempo o la plata - Pruebas basadas en plazos y presupuesto (“time and budget testing”)
56

ALGUNAS DEFINICIONES
- OBJETO DE PRUEBA: Lo que vamos a probar.
- BASE DE PRUEBAS: Toda la documentación existente.
- CAMA DE PRUEBAS: El entorno de pruebas.
- ORÁCULO DE PRUEBAS: Predecir los resultados esperados.
- REQUISITO: lo que pide el cliente.
- REQUERIMIENTO: Lo que pide el cliente pero en un documento con lenguaje formal.
- PRODUCTO DE TRABAJO: Como su nombre lo indica es el producto o entregable de una

trabajo realizado. ¿Ejemplos?
57
19
18/10/2020

¿QUÉ DEBE TENER UN CASO DE PRUEBA?


Según la IEEE 610 que evolucionó en la IEEE 829 y que a su vez evolucionó en la
ISO/IEC/IEEE 29119 nos habla de toda la documentación del proceso de pruebas, la
definición de un caso de prueba incluye, al menos, la siguiente información:
1. Identificador único (ID)

2. Conjunto de valores de entrada
3. Conjunto de resultados esperados
4. Precondiciones
5. Poscondiciones esperadas
6. Dependencia de otros casos de prueba (Primero debo probar tin y después tal)
7. Referencia al requisito que será probado (trazabilidad)
8. Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados (opcional)
9. Prioridad (opcional)
58

Resumen
- Los fallos del software pueden causar importantes daños
- La calidad del software es la suma de los atributos que se refieren a la capacidad del software
de satisfacer un conjunto de requisitos dados
- El aseguramiento de la calidad constructivo se ocupa de la prevención de defectos
- El aseguramiento de la calidad analítico se ocupa de la detección y corrección de defectos
- Los atributos funcionales y no funcionales de la calidad definen la calidad total del sistema
- Cada prueba debe contar con criterios de salida (“exit criteria”). Al alcanzar los criterios de
salida concluirán las actividades de prueba
- Los probadores (“testers”) buscan fallos en el sistema e informan sobre los mismos (proceso
de prueba – “testing”).
- Los desarrolladores buscan defectos y los corrigen (depuración – “debugging”)
59

60
20
18/10/2020

Contenido
Capítulo I – Fundamentos de pruebas

- I/01¿Porqué son necesarias las pruebas?
- I/02 ¿Qué son las pruebas?
- I/03 Siete principios del proceso de prueba
- I/04 Proceso de prueba básico
- I/05 Psicología en el proceso de prueba
- I/06 Código ético
61

03. Siete principios del proceso de prueba
Principio 1: El proceso de prueba demuestra la presencia de defectos más no la ausencia de los mismos.
- El proceso de prueba puede probar la presencia de defectos
- La causa de un fallo puede no ser obvia
El proceso de prueba no puede demostrar la ausencia de defectos
- El mismo proceso de prueba puede contener errores

- Las condiciones de prueba pueden ser inapropiadas para detectar errores
62

Principio 2: No es posible realizar pruebas exhaustivas

- Pruebas exhaustivas (“exhaustive testing”)

- Abarcar todas las combinaciones de valores de entrada y precondiciones
- Explosión de casos de prueba (“test case explosion”)

- A medida que se adicionan condiciones los casos crecen exponencialmente
- Prueba de Muestra (“sample test”)

- Se deben escoger muestras de datos, pequeños subconjuntos
¿Probarías todas estas

combinaciones?
63
21
18/10/2020

Principio 3: Las Pruebas tempranas (“early testing”) ahorran tiempo y dinero

- Cuanto más temprana es la detección de un defecto, menos costosa es su corrección
- Es mas económico corregir un documento que un desarrollo
- La preparación de una prueba también consume tiempo

- Las actividades de prueba pueden ser preparadas antes de que el desarrollo se haya completado
- Modelo W – toda actividad de desarrollo dispara una actividad de pruebas
- También conocido como “Desplazamiento a la izquierda”
64

Principio 4: Agrupamiento de defectos (“defect clustering”) – Los defectos se agrupan

- !Encuentre un defecto y encontrará más defectos “cerca”!

- Vale la pena investigar un mismo módulo donde se ha detectado un defecto. Los defectos aparecen agrupados como hongos o
cucarachas
- Los probadores (“testers”) deben ser flexibles

- Habiendo sido detectado un defecto, es conveniente volver a considerar el rumbo de las pruebas posteriores
- La identificación/localización de un defecto puede ser investigada con un mayor grado de detalle, por ejemplo, realizando pruebas
adicionales o modificando pruebas existentes
65

Principio 5: Cuidado con la Paradoja del pesticida

- Repetir pruebas en las mismas condiciones no es efectivo

- Si se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar nuevos defectos. Se deben cambiar las combinaciones
y la estrategia.
- Las pruebas deben ser revisadas/modificadas regularmente para los distintos módulos de código
- Retest
- Regresión - automatización
66
22
18/10/2020

Principio 6: Las pruebas dependen del contexto

- Las pruebas se llevan a cabo de forma diferente en diferentes contextos
- Ver dibujitos
- Objetos de prueba diferentes son probados de forma diferente
- Entorno de prueba (“test environment”, cama de prueba - “test bed”) vs. entorno de producción (“production environment”):
- Aunque los entornos deberían ser lo mas parecidos, nunca lo son.
67

Principio 7: La falacia de la ausencia de errores

- Un proceso de prueba adecuado detectará los fallos más importantes
- En la mayoría de los casos el proceso de prueba no detectará todos los defectos del sistema (ver Principio 2), pero los defectos más
importantes deberían ser detectados
- Esto por sí solo no prueba 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 través de las pruebas, la calidad tiene que construirse desde el principio!
68

Resumen
- El proceso de prueba demuestra la presencia de defectos mas no la ausencia de ellos.

- No es posible realizar pruebas exhaustivas
- Pruebas tempranas
- Agrupamiento de defectos
- Paradoja del pesticida
- Las pruebas dependen del contexto
- La falacia de la ausencia de errores
69
23
18/10/2020


70

Contenido


71

04. Proceso de prueba básico
El proceso de prueba como proceso dentro del proceso de desarrollo software

- Dependiendo del enfoque seleccionado el proceso de prueba tendrá lugar en diferentes puntos del proceso de
desarrollo
- La prueba constituye un proceso en sí misma
- El proceso de prueba está determinado por las siguientes fases:
1. Planificación de pruebas y Control

2. Análisis de pruebas y diseño de pruebas
3. Implementación de pruebas y ejecución de pruebas
4. Evaluación de criterios de salida de pruebas y generación de informes de pruebas
5. Actividades de cierre de pruebas
- Las fases del proceso de prueba se podrán superponer
72
24
18/10/2020

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

- ¡El proceso de prueba es más Planificación de pruebas
que la ejecución de pruebas!
Análisis de pruebas
- Incluye superposición y y Diseño de pruebas
vuelta atrás (“backtracking”)
Control de pruebas
Implementación de pruebas
- Cada fase del proceso de
pruebas tiene lugar de forma y Ejecución de pruebas
concurrente con las fases del
proceso de desarrollo software
Evaluación del criterio de salida
y Generación de informes
Actividades de cierre
de pruebas
73

Planificación de pruebas
y Diseño de pruebas
Control de pruebas
y Ejecución de pruebas

Compleción de pruebas
de pruebas
Compleción: Acción de completar

74

Control de pruebas – tareas principales

- El control de pruebas es una actividad continua
- Influye en la planificación de las pruebas.
- Si es necesario se modifica El plan maestro de prueba (“master test plan”).
- Planeado Vs Progreso Real Planificación de pruebas
- ¿Hemos avanzado?
- ¿Dimos la cobertura? Análisis de pruebas
- ¿Toca cambiar el enfoque o estrategia?
Control de pruebas
- ¿Se han cumplido los criterios de salida acordados? Implementación de pruebas

- Se inician medidas correctivas

- Se preparan y toman decisiones
de pruebas
75
25
18/10/2020

Planificación de pruebas – tareas principales

- Determinar el alcance y riesgos
- Identificar los objetivos de las pruebas y
los criterios de salida de pruebas Análisis de pruebas
Control de pruebas
- Determinar el enfoque: técnicas de pruebas,
cobertura de pruebas, equipo de pruebas Implementación de pruebas
- Implementar el método o estrategia Evaluación del criterio de salida

de prueba, planificación del período de
tiempo para el desarrollo de las actividades
a seguir Actividades de cierre
de pruebas
- Adquirir/obtener y programar recursos requeridos por las pruebas: personal, entorno de prueba, presupuesto de
prueba
76

- Plan maestro de prueba (“master test plan”):

- Es un documento en el que se describe el alcance, enfoque, recursos y calendario (“schedule”) de las actividades de prueba previstas.
Este documento incluye, pero no está limitado a, los elementos de prueba (“test items”), características que serán probadas, recursos y
la planificación de contingencias
- Estrategia de prueba (“test strategy”):

- Descripción a alto nivel de los niveles de prueba a llevar a cabo y las pruebas asociadas a ellos para una organización o programa (uno o
más proyectos)
- Enfoque de prueba (“test approach”)

- Normalmente incluye la decisiones tomadas con el objeto de lograr los objetivos del proyecto (de prueba) y el análisis de riesgo, puntos
de inicio (“starting points”) respecto del proceso de prueba, técnicas de diseño de pruebas a aplicar, criterios de salida y tipos de prueba
a ejecutar
- Cobertura de pruebas (“test coverage”):

- Que tanto hemos probado de lo que está definido?. 9 funcionalidades de 10 (90%)
77

Análisis y diseño de pruebas – tareas principales (1)

- Revisar la base de prueba (“test basis”)

(requisitos, arquitectura del sistema, diseño, Planificación de pruebas
interfaces)
- Analizar la testabilidad
Control de pruebas
-
Identificar y priorizar condiciones de prueba
(“test conditions”) en función de: Evaluación del criterio de salida
- Análisis de los elementos de prueba (“test item”)

- Especificaciones de prueba de pruebas
- Comportamiento y estructura del software
78
26
18/10/2020


- Diseñar pruebas/casos de prueba
- Crear y priorizar casos de prueba

lógicos/ de alto nivel Análisis de pruebas
- Los casos de prueba positivos dan muestra
Control de pruebas
de la funcionalidad,
- los casos de prueba negativos comprueban y Ejecución de pruebas
situaciones en las que hay tratamiento de errores
- Identificar condiciones de prueba específicas y
datos de prueba (“test data”) necesarios Actividades de cierre
de pruebas
- Evaluar la disponibilidad de datos de prueba y/o la viabilidad de generación de datos de prueba
79


- Diseñar el entorno de prueba

(“test environment”) Planificación de pruebas
[cama de prueba – (“test bed”)]
- (Exclusivo) disponibilidad del entorno de y Diseño de pruebas
Control de pruebas
prueba, ventanas temporales

(“time window”), etc. Implementación de pruebas
- Definir la operación del entorno de Evaluación del criterio de salida

prueba, incluyendo la administración y Generación de informes
de usuario
de pruebas
- Cargar conjuntos de datos (“data sets”) y
parámetros del sistema (“system parameters”)
- Conectar al entorno de prueba con los sistemas adyacentes
80


- Probar la infraestructura y herramientas de

prueba (“test tools”), si fuera necesario Planificación de pruebas
- Procesos, procedimientos y Análisis de pruebas

responsabilidades
Control de pruebas
- Seleccionar, proveer, instalar y operar

herramientas de prueba y Ejecución de pruebas
- Crear trazabilidad bidireccional (De aquí para allá y del Evaluación del criterio de salida
mismo modo pero en sentido contrario)
de pruebas
- Entre las bases de las pruebas y casos
de prueba
81
27
18/10/2020

Implementación y ejecución de pruebas (1)

- Finalizar, implementar y priorizar casos de
prueba
- Identificar datos de prueba
Control de pruebas
- Desarrollar y priorizar procedimientos de
prueba y Ejecución de pruebas
- Crear datos de prueba

- Preparar arneses de prueba* (“test harness”) Evaluación del criterio de salida
[opcional]
- Redactar guiones de prueba automatizados* Actividades de cierre
de pruebas
(“automated test script”), si fuera necesario
- Crear juegos de prueba* (“test suites”) de los procedimientos para una ejecución de prueba eficiente
- Verificar el entorno de prueba* (cama de prueba)

*Ver glosario
82


- Verificar y actualizar la trazabilidad (bases de

prueba – casos de prueba)
- Ejecutar prueba (de forma manual o
automática) Análisis de pruebas
- Seguir la secuencia de prueba establecida en el plan de y Diseño de pruebas

Control de pruebas
prueba (juego de pruebas, orden de los casos de prueba) Implementación de pruebas

- Registrar resultados de prueba y análisis Evaluación del criterio de salida

- Registrar las identidades y versiones y Generación de informes
del software herramientas de prueba/

productos de soporte de prueba de pruebas
(“testware”)
83


- Comparar resultados reales (“actual results”)

con resultados esperados (“expected results”) Análisis de pruebas
Control de pruebas
- Informar y analizar incidencias con el objeto Implementación de pruebas

de establecer sus causas
- Código/datos de prueba/documento/ejecución Evaluación del criterio de salida
- Repetir actividades de prueba para Actividades de cierre

de pruebas
confirmar una corrección:
- Repetición de prueba (“re-test”)
[después de la corrección de un defecto]
- Ejecutar prueba de regresión con el fin de asegurar que los cambios (después de instalar una nueva versión o corrección de un
defecto) no han expuesto otros defectos o introducido nuevos defectos
84
28
18/10/2020

- Juego de pruebas (“test suite”)/secuencia de pruebas (“test sequence”):

- Conjunto de casos de prueba para un componente o sistema en prueba, donde la poscondición de una prueba es utilizada como
precondición de la siguiente
- Especificación de procedimiento de pruebas (“test procedure specification”) (escenario de prueba – “test scenario”):
- Documento que especifica la secuencia de acciones para la ejecución de una prueba. También conocido como script de prueba o
script de prueba manual. [Según IEEE 829]
- Ejecución de prueba (“test execution”):

- Proceso de practicar una prueba produciendo resultados reales
85

- Registro de prueba (“test log”) [protocolo de prueba – (“test protocol”), informe de pruebas – “test report”]:
- Registro cronológico de los detalles relevantes respecto a la ejecución de pruebas. [IEEE 829]: cuando se desarrollaron las pruebas,
qué resultados fueron generados
- Pruebas de regresión (“regression tests”):

- Pruebas de un programa previamente probado que ha sufrido modificaciones, para asegurarse que no se han introducido o
descubierto defectos en áreas del software que no han sido modificadas como resultado de los cambios realizados. Se realiza
cuando el software o su entorno han sido modificados
- Repetición de prueba (“re-testing”):

- Repetición de una prueba tras la corrección de un defecto con el objeto de confirmar que el defecto ha sido eliminado con éxito
86

Evaluación de criterios de salida – tareas principales

- Evaluar la ejecución de pruebas con

respecto a los objetivos definidos
(por ejemplo, criterios de salida)
Control de pruebas
- Evaluar los registros de prueba

(resumen de las actividades de pruebas, y Ejecución de pruebas
resultados de prueba, comunicar criterio
de salida) Evaluación del criterio de salida
- Proporcionar información con el objeto Actividades de cierre

de pruebas
de dar lugar a la decisión de llevar a
cabo pruebas adicionales
87
29
18/10/2020

Actividades de cierre de pruebas (“test closure”) –

tareas principales (1)
- Recopilar datos de las actividades del proceso Análisis de pruebas

de prueba finalizadas con el objeto de
Control de pruebas
consolidar la experiencia, producto de soporte Implementación de pruebas
de prueba ("testware"), hechos y números y Ejecución de pruebas
- Cerrar informes de incidencia o generación Evaluación del criterio de salida

de solicitudes de cambio para cualquier punto
que permaneciera abierto Actividades de cierre
de pruebas
- Comprobar qué entregables planificados han
sido entregados y probados
88

Actividades de cierre de pruebas (“test closure”) –

tareas principales (2)
- Documentar la aceptación del sistema Planificación de pruebas
- Finalizar y archivar los productos de soporte de prueba Análisis de pruebas

("testware"), el entorno de prueba y la infraestructura y Diseño de pruebas
Control de pruebas
de prueba para un uso posterior,

transferencia/traspaso a operaciones Implementación de pruebas
- Analizar las lecciones aprendidas para futuros Evaluación del criterio de salida
proyectos y Generación de informes
- Utilizar la información recopilada para mejorar la Actividades de cierre

de pruebas
madurez del proceso de prueba
89

Resumen
El proceso de prueba se puede dividir en diferentes fases.
- Planificación de pruebas (“test planning”) abarca actividades como la definición del enfoque de pruebas para todas las fases así como
la planificación de los recursos (tiempo, personal, máquinas)
- Diseño de pruebas (especificación) abarca el diseño de casos de prueba y sus resultados esperados
- Ejecución de pruebas abarca la definición de datos de prueba, la ejecución de pruebas y la comparación de resultados
- Evaluación de pruebas y generación de informes abarca la evaluación del criterio de salida y el registro de los resultados de pruebas
en forma escrita
- Control de prueba consiste en el control de las actividades que cubren todas las fases del proceso de prueba
90
30
18/10/2020


91

Contenido


92

05. Psicología en el proceso de prueba
Roles y responsabilidades
Rol: Desarrollador Rol: Probador (“Tester”)

- Implementa requisitos - Planifica las actividades de pruebas.
- Desarrolla estructuras - Diseña casos de prueba
- Diseña y programa el software - Su única preocupación es encontrar
- Su éxito consiste en la creación de un defectos
producto - Encontrar errores producidos por un
desarrollador es su éxito
Percepción:
¡La actividad del desarrollador es ¡La actividad del probador (“tester”) es
constructiva! destructiva!
¡Error!
¡Las pruebas también constituyen una actividad constructiva,
su propósito es la eliminación de defectos de un producto!
93
31
18/10/2020

Características personales de un buen probador (“tester”) (1)

- Curioso, perceptivo, atento a los detalles – no todo error se manifiestan de forma evidente
- Con el objeto de comprender los escenarios prácticos del cliente
- Con el objeto de poder analizar la estructura de la prueba
- Con el objeto de descubrir detalles de dónde se pueden manifestar fallos
- Escéptico y con actitud crítica

- Los objetos de prueba contienen defectos. Usted sólo 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 evolución
del proyecto
94

Características personales de un buen probador (“tester”) (2)

- Aptitudes para la comunicación

- Necesarias para llevar malas noticias a los desarrolladores
- Necesarias para vencer estados de frustración
- Tanto cuestiones técnicas como prácticas, relativas al uso del sistema, deben ser entendidas y comunicadas
- Una comunicación positiva puede ayudar a evitar o facilitar situaciones difíciles
- Para establecer una relación de trabajo con los desarrolladores a corto plazo
- Experiencia
- Factores personales influyen en la ocurrencia de errores
- La experiencia ayuda a identificar dónde se pueden acumular errores
95

Diferencias: diseñar – desarrollar – probar

- El proceso de prueba requiere un modo de pensar distinto a la del diseño y desarrollo de sistemas software
- Objetivo común: aportar un buen producto software
- Cometido del diseño: ayudar al cliente a proveer/suministrar los requisitos adecuados
- Cometido de los desarrolladores: convertir los requisitos en funciones
- Cometido de los probadores (“testers”): evaluar la correcta implementación de los requisitos del cliente
- En principio, una persona puede asumir los tres roles en su trabajo

- Se deben tener en cuenta las diferencias en objetivos y modelos de roles
- Es difícil pero posible
- Otras soluciones (pruebas independientes) pueden ser más sencillas y aportar mejores resultados
96
32
18/10/2020

Pruebas independientes – Grados de independencia de las pruebas

- La separación de las responsabilidades en el proceso de prueba apoya/promueve la evaluación independiente de los
resultados de las pruebas
- En el siguiente diagrama se representa el grado de independencia de las a través de un gráfico de barras
97

Organización de pruebas – tipos (1)

- Pruebas de desarrollador
- El desarrollador nunca analizará su “creación” de forma imparcial (apego afectivo)
- Sin embargo, él conoce el objeto de prueba mejor que nadie
- Habrá costes adicionales debido a la formación/información 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 interpretación de los requisitos se mantendrán 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 anomalía
98


- Equipos de desarrollado
- Los desarrolladores hablan el mismo lenguaje
- Los costes de formación/información en lo relativo a objetos de prueba se mantienen en un nivel moderado, especialmente
cuando los equipos intercambian objetos de prueba
- Peligro de generación 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
99
33
18/10/2020


- Equipos de pruebas
- La creación de equipos de prueba 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
100


- Subcontratación de pruebas (“externalización”)

- La separación de las actividades de prueba y desarrollo aportan la máxima independencia entre los objetos de prueba y el
probador (“tester”)
- Las actividades de prueba subcontratadas (externalizadas) son ejecutadas por personal con un conocimiento relativamente
pequeño de los objetos de prueba y de los antecedentes del proyecto
- La curva de aprendizaje implica altos costes, por lo tanto, se deberían involucrar a expertos independientes en etapas tempranas
del proyecto
- Los expertos externos cuentan con un alto nivel de conocimiento (“know how”) del proceso de prueba
- Está asegurado un diseño de pruebas apropiado
- Se alcanza la optimización en el uso de métodos y herramientas
- Diseño de casos de prueba de forma automática
- Generación de casos de prueba asistida por ordenador, por ejemplo casos de prueba basados en documentos de
especificaciones formales, también es independiente
101

Dificultades (1)
- Incapacidad de comprensión mutua

- Los desarrolladores deberían contar con un conocimiento básico de las pruebas
- Los probadores (“testers”) deberían contar con un conocimiento básico de desarrollo software
- Especialmente en situaciones de tensión, la detección 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á cómo se desarrollará la situación
- Las personas no deberían ser criticadas, los defectos deben ser descritos en términos objetivos
- La descripción de los defectos debería ayudar al desarrollador a encontrar el error
- Los objetivos comunes siempre deben ser la cuestión principal
102
34
18/10/2020

Dificultades (2)

- La comunicación entre probadores (“testers”) y desarrolladores es insuficiente o inexistente. Este hecho puede hacer
imposible el trabajo conjunto
- Los probadores (“testers”) son vistos únicamente como “portadores de malas noticias”
- Mejora: intente ponerse en el lugar (rol) de la otra persona. ¿Mi mensaje ha sido transmitido? ¿Me ha llegado la respuesta?
- Un proceso de prueba sólido requiere la distancia apropiada con respecto al objeto de prueba
- Se adquiere un punto de vista independiente e imparcial a través 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
103

Resumen
- Las personas cometen errores, toda implementación 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
- El desarrollo es constructivo - algo que no estaba ahí previamente es creado
- El proceso de prueba resulta destructivo a primera vista - ¡Se detectarán defectos!
- Juntos, el desarrollo y las pruebas son constructivas en su objetivo de obtener un producto software con la menor cantidad de
defectos posible
- Las pruebas independientes aumentan la calidad del proceso de prueba:
En lugar de equipos de desarrolladores utilice equipos de prueba (probadores – “testers”) o equipos con personal externo para
pruebas
104

105
35
18/10/2020

Contenido

106

06. Código ético – Código Deontológico
Código de conducta (1)

Los individuos involucrados en el proceso de prueba software tienen acceso a información muy privilegiada y crítica. El
código de ética es necesario para asegurar que la información es utilizada de forma apropiada.
- Público – Los probadores software certificados deben actuar conforme con el interés de su cliente y empleador, conforme con el
interés público, especialmente en aquellos trabajos relacionados con sistemas de seguridad crítica donde , por ejemplo, se le podría
solicitar la eliminación de un informe de defectos de forma discreta
- Cliente y empleador – Los probadores software certificados deben actuar conforme con el interés de su cliente y empleador,
conforme con el interés público. Por ejemplo, no filtrando a Internet información interna o privada del cliente o empleador
107

06. Código ético

- Producto – Los probadores software certificados asegurarán que los entregables que suministran (sobre los productos y sistemas que
prueban) alcanzan los estándares profesionales más altos. Significa que, trabajando como consultor, no se omitan detalles importantes
al cliente
- Juicio – Los probadores software certificados mantendrán su integridad e independencia en su juicio profesional. Tal vez un jefe de
proyecto solicitara que se ocultaran defectos de importancia al promotor del proyecto (“business sponsor”), en el caso de que el
probador accediera a la petición resultaría en un menoscabo a la independencia y un fallo ético
108
36
18/10/2020

06. Código ético

- Gestión – Los gestores de prueba software certificados y responsables (“leaders”) suscribirán y promoverán un enfoque ético en la
gestión de las pruebas software. Favorecer a un probador respecto a otro con el objeto de establecer una relación de carácter
personal podría ser una seria contravención a la ética de la gestión
- Profesión – Los probadores software certificados promoverán la integridad y reputación de la profesión consistente con el interés
público. Hacer público el efecto y formas en las que las pruebas software son un beneficio para la sociedad
- Compañeros de profesión – Los probadores software serán justos y solidarios con sus compañeros de profesión, y promoverán la
cooperación con los desarrolladores de software
109

06. Código ético

- Individualmente – Los probadores software certificados participarán en procesos de formación relacionados con su práctica
profesional de forma permanente y promoverán un enfoque ético en la práctica de la profesión. Una forma de mantener un alto nivel
de conocimiento podría ser atendiendo a cursos de formación y leyendo libros
110

111
37

Capítulo No. 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo No. 1

Cargado por

Copyright:

Formatos disponibles

18/10/2020

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

NO ESTÁ AUTORIZADO SU USO COMERCIAL

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

International Software Testing Qualifications Board

El Comité Internacional de Certificaciones de Pruebas de

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

Hispanic America Software Testing

El HASTQB surge como la localización en Hispano

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

International Software Quality Institute

El Instituto de Calidad de Software Internacional

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

Certified Tester Foundation Level

Es la certificación que van a obtener una vez

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

¿Por qué la ISTQB® Certified Tester es el

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

Las características del esquema de certificación

• Planes de Estudio de Alta Calidad: Todos los planes de estudio

• Reconocimiento Mundial: Las certificaciones son reconocidas

• Lenguaje Común: El glosario de ISTQB® proporciona un

• Objetividad: la evaluación de las capacidades del probador se

• Adhesión a un Código de Ética: Todos los probadores

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

Las características del esquema de certificación incluyen:

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

• Abierta al Público: Los materiales de ISTQB® se desarrollan

• Independencia: La naturaleza sin ánimo de lucro de ISTQB®

• Mejora Continua: Los planes de estudio y otros documentos

• Posicionamiento Profesional: Ser certificado ofrece ventajas

APLICAN ACUERDOS DE CONFIDENCIALIDAD

ESTE MATERIAL ES DE USO PERSONAL E INTRANSFERIBLE

PROHIBIDAS LAS COPIAS NO AUTORIZADAS

¿A quién va dirigida? CTFL

La certificación de nivel Básico está dirigida a profesionales

La certificación de nivel básico también es apropiada para

APLICAN ACUERDOS DE CONFIDENCIALIDAD