Capítulo No.1 ISTQB Probador

Probador Certificado –
Nivel Básico
Formación para el “Probador Certificado – Nivel Básico”
de acuerdo al programa de estudios 2010 del ISTQB
Versión V.1.2a_V ES.1.0

Probador Certificado – Nivel Básico
0. Generalidades
01. Introducción
Formador
Jaime Orlando Padilla Castro
Jaime.Padilla@claro.com.co
Tel: 7429797 Ext. 60373
Cel: 300-5564220
0. Generalidades
02. Contenido
El presente curso se ha desarrollado de acuerdo con el programa de estudios del año 2010
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 Diseño de Pruebas
Capítulo V Gestión de Pruebas
Capítulo VI Herramientas de Prueba
I. Fundamentos de pruebas
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
Contenido

01. ¿Porqué son necesarias las pruebas?
La importancia económica del software

- El funcionamiento de maquinaria y equipamiento depende en gran medida de un
producto software
- No es posible imaginar grandes sistemas, en el ámbito de las finanzas ni el control de
tráfico automotor, entre otros, funcionando sin un software
Calidad software
- Cada vez más, la calidad software se ha convertido en un factor determinante del éxito
de sistemas técnicos o comerciales y productos
Pruebas para la mejora de la calidad

- Las pruebas y revisiones aseguran la mejora de la calidad de productos software así
como de la calidad del proceso de desarrollo en sí
Ejemplo de fallo 1: Lanzamiento del Ariane 5

Vuelo 501, tuvo lugar el 4 de junio de 1996, fue la primera prueba de vuelo del sistema de
lanzamiento desechable del Ariane 5. No fue un éxito, la lanzadera se destruyó 37
segundos después del lanzamiento debido a un mal funcionamiento en el software de
control, haciendo del mismo defecto software uno de los más caros de la historia.
El software del Ariane 5 reutilizó las especificaciones del Ariane 4, pero la trayectoria de vuelo del
Ariane 5 era considerablemente distinta y superaba el rango para el cual el código reutilizado había
sido diseñado. En particular, la mayor aceleración del Ariane 5 provocó un fallo en los ordenadores
de respaldo (“back-up”) y navegación inercial primarios, tras lo cual las toberas de la lanzadera
fueron dirigidas por datos espurios. Las pruebas previas al vuelo nunca fueron ejecutadas sobre el
código reajustado bajo condiciones de vuelo simuladas del Ariane 5, por lo tanto el error no fue
descubierto antes del lanzamiento.
Fuente: Wikipedia.com
Ejemplo de fallo 2: Rayos X letales

Una serie de pacientes recibieron una dosis letal de radiación debido a un fallo de
software:
El Therac-25 era una máquina para radiación terapéutica producida por la empresa Atomic Energy
of Canada Limited. Estuvo involucrada con, al menos, seis accidentes conocidos entre 1985 y 1987,
en los cuales los pacientes fueron objeto de una sobredosis masiva de radiación que, en algunos
casos, fueron del orden de centenas de “gray”. Al menos cinco pacientes murieron por sobredosis.
Estos accidentes destacan los riesgos del control software de sistemas de seguridad crítica (“safety-
critical systems”).
Fuente: Wikipedia.com
Causas de fallos (“failure”) software

- Error humano
- Un defecto ha sido introducido en el código software, en los datos o en los parámetros de
configuración
Causas de error humano
Plazos, demandas excesivas debidas a la complejidad,
distracciones
- Condiciones ambientales
- Cambios en las condiciones ambientales
Causas de condiciones ambientales negativas/adversas
Radiación, magnetismo, campos electromagnéticos,
polución, manchas solares, fallo de discos duros,
fluctuaciones en el suministro de energía eléctrica
Error (“Error”) , defecto (“defect”), fallo (“failure”)
- Error (“Error”) (IEEE 610):

- Acción humana que produce un resultado incorrecto. [Según IEEE 610]. Ejemplo un error de
programación
- Defecto (“Defect”):
- Desperfecto en un componente o sistema que puede causar que el componente o sistema falle
en desempeñar las funciones requeridas, por ejemplo, una sentencia o una definición de datos
incorrectas. Si se localiza un defecto durante una ejecución puede causar un fallo en el
componente o sistema
Error (“Error”) , defecto (“defect”), fallo (“failure”)
- Fallo (“Failure”):
- Manifestación física o funcional de un defecto. Si un defecto es encontrado durante la
ejecución de una aplicación puede producir un fallo
- Desviación de un componente o sistema respecto de la prestación, servicio o resultado
esperados. [Según Fenton]
Los defectos causan un fallos
El icono del libro en el ángulo superior derecho de la diapositiva significa que las definiciones han sido extraídas del glosario del
ISTQB
El papel del proceso de prueba en el proceso de desarrollo, mantenimiento y

operaciones
- 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
El coste de los defectos coste relativo

de la corrección
de 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

EJEMPLO
• Especificación $5
• Diseño $4
• Construcción $3
• Pruebas $7
• Aceptación $5
• Operación $3
$ 315
Pruebas y la Calidad
- Definición: Software (según IEEE 610):
- Programas de ordenador, procedimientos y posiblemente documentación y datos
pertenecientes a la operación de un sistema basado en un ordenador. [IEEE 610]
- Definición: Calidad software (según ISO/IEC 9126):

- La totalidad de la funcionalidad y prestaciones de un producto software que contribuyen con su
capacidad de satisfacer necesidades explícitas o implícitas. [Según ISO 9126]
- Definición: Calidad (según IEEE Std 610):

- Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o
necesidades y expectativas del usuario/cliente.
[Según IEEE 610]
Pruebas y la Calidad
De acuerdo a la norma ISO/IEC 9126 la calidad software consiste en:
- Funcionalidad Atributos funcionales de calidad
- Fiabilidad
- Usabilidad
- Eficiencia Atributos no-funcionales de calidad
- Mantenibilidad
- Portabilidad
Tipos de Aseguramiento de la Calidad (QA):

- 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
- 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
Aseguramiento de la calidad constructivo

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

en el pasado no deben ser
repetidos
Métodos
Herramientas
- Prevenir defectos
Técnico
Lenguajes
Listas / plantillas
Entorno de Desarrollo Integrado (IDE)
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
Pruebas y la Calidad – Atributos funcionales de calidad

Funcionalidad significa:
- Corrección: La funcionalidad satisface los atributos/capacidades requeridos
- Completitud: La funcionalidad satisface todos los requisitos (funcionales)
Funcionalidad (“functionality”) incluye (según ISO/IEC 9126):

- Adecuación (“suitability”)
- Exactitud (“accuracy”)
- Interoperabilidad (“interoperability”)
- Seguridad (“security”)
- Cumplimiento de funcionalidad(“functionality compliance”)
Pruebas y la Calidad – Atributos no funcionales de calidad (1)

Fiabilidad (“reliability”):
- Madurez(“maturity”), tolerancia a defectos (“fault tolerance”), recuperabilidad (“recoverability”),
cumplimiento de fiabilidad (“reliability compliance”)
- Características: En determinadas condiciones, el software/sistema mantendrá su
capacidad/funcionalidad a lo largo de un período de tiempo
- Fiabilidad = Calidad/tiempo
Usabilidad (“usability”):
- Comprensibilidad (“understandability”), aprendibilidad (“learnability”), operabilidad (“operability”),
atractivo (“attractiveness”), cumplimiento de usabilidad(“usability compliance”)
- Características : Fácil de usar, fácil de aprender, conforme a normas, uso intuitivo

Eficiencia (“efficiency“):
- Comportamiento del sistema: funcionalidad y respuesta temporal
- Características: El sistema requiere la utilización de un mínimo de recursos (por ejemplo tiempo
de CPU) para ejecutar una tarea determinada
Mantenibilidad (“maintainability”):
- Analizabilidad (“analysability”), modificabilidad (“changeability”), estabilidad (“stability”),
testabilidad (testability”), cumplimiento de mantenibilidad (“maintainability compliance”)
- Características: Medida del esfuerzo requerido para realizar cambios en los componentes de un
sistema

Portabilidad (“portability”):
- Adaptabilidad (“adaptability”), instalabilidad (“installability”), coexistencia (“co-existence”),
reemplazabilidad (“replaceability”), cumplimiento de portabilidad (“portability compliance”)
- Capacidad del software de ser transferido a un nuevo entorno (software, hardware, organización)
- Características: Fácil de instalar y desinstalar, parámetros
Atributos de la calidad
- Algunos atributos de la calidad de un producto software se influyen mutuamente. Debido a esta
interdependencia y, en función del objeto de prueba, los atributos deberán ser caracterizados por
una prioridad. Por ejemplo eficiencia versus portabilidad
- Se realizarán distintos tipos de pruebas con el objeto de medir distintos tipos de atributo
Objetivos de las pruebas

- 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
- Confirmación de la funcionalidad
- La funcionalidad del sistema debe ser implementada tal y como ha sido especificada
- 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
- 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
¿Cuantas pruebas son suficientes?

- Criterios de salida (“exit criteria”)
- No encontrar (más) defectos es un criterio apropiado para finalizar las actividades de prueba. Sin
embargo son necesarias otras métricas para reflejar de forma adecuada el nivel de calidad
alcanzado
- Pruebas basadas en riesgos (“risk-based testing”)

- Los niveles de riesgo determinan el grado en el cual se ha probado, es decir: responsabilidad en
caso de fallos, probabilidad de la ocurrencia de fallos, aspectos relativos a factores económicos y
propios del proyecto
- Pruebas basadas en plazos y presupuesto (“time and budget testing”)

- La disponibilidad de recursos: (personal, tiempo, presupuesto) pueden determinar la medida del
esfuerzo del proceso de prueba
Caso de prueba (“test case”), base de prueba (“test basis”)

Caso de prueba (“test case”) según IEEE Std 829:
La definición de un caso de prueba incluye, al menos, la siguiente información (según IEEE Std 610)
- Precondiciones
- Conjunto de valores de entrada
- Conjunto de resultados esperados
- Poscondiciones esperadas
- Identificador único
- Dependencia de otros casos de prueba
- Referencia al requisito que será probado
- Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados (opcional)
- Prioridad (opcional)
- Base de 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
Desarrollo software y revisiones

- Código (“code”), código fuente (“source code”):
- Programa de ordenador escrito en un lenguaje de programación que puede ser leído por una
persona
- Depuración (“debugging”):
- Localización y corrección de defectos en el código fuente
- Desarrollo software (“software development”):

- Es un proceso complejo/secuencia de actividades cuyo objetivo es desarrollar un sistema basado
en un ordenador. Normalmente sigue un modelo de desarrollo software
Desarrollo software y revisiones

- Requisito (“requirement”):
- Un requisito describe un atributo (funcional o no funcional) deseado o considerado obligatorio
- Revisión (“review”) [según IEEE Std 1028]:

- Evaluación de un producto o del estado de un proyecto para detectar discrepancias respecto de
los resultados planificados y para recomendar mejoras
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”)
Contenido

02. ¿Qué son las pruebas?
Probar significa más que ejecutar pruebas

- La ejecución de pruebas es sólo una parte de las pruebas
- El proceso de prueba incluye
- Planificación y control
- Selección de condiciones de prueba
- Diseño y ejecución de casos de prueba
- Comprobación de resultados
- Generación de informes respecto del proceso de prueba y el sistema sujeto a prueba
- Finalización y completar actividades de cierre
- 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
Objetivos de las pruebas

- Detección de defectos
- Puede ser
- Pruebas de desarrollo (“development testing”):
para causar tantos fallos (“failures”) como sea posible
- Pruebas de aceptación (“acceptance testing”):
para confirmar que el sistema funciona como se espera
- Generación (logro) de confianza respecto del nivel de Calidad

- Aportación de información para la toma de decisiones
- Prevención de defectos
Términos: Desarrollo Software

- Depuración (“debugging”):
- Proceso de encontrar, analizar y eliminar las causas de los fallos en el software
- Requisito (“requirement”):
- Condición o capacidad necesaria para un usuario con el objeto de solucionar un problema o
lograr un objetivo que debe ser alcanzado o poseído por un sistema o componente de un
sistema, para satisfacer un contrato, estándar, especificación u otro documento impuesto
formalmente. [Según IEEE 610]
- Revisión (“review”):
- Evaluación de un producto o del estado de un proyecto para detectar discrepancias con los
resultados planificados y para recomendar mejoras. Algunos ejemplos incluyen la revisión de
gestión, revisión informal, revisión técnica, inspección y revisión guiada. [Según IEEE 1028]
Pruebas y depuración (“debugging”)

Depuración
Detección - Repetición de
Corrección de
Prueba identificación de pruebas
defectos (re-test)
defectos
Probar y repetir la prueba (repetición de prueba – “re-testing”) son actividades propias

del proceso de prueba.
- Las pruebas muestran los fallos
- La repetición de pruebas (“re-testing”) verifica que el defecto ha sido corregido
La depuración y la corrección de defectos son actividades propias del desarrollador

- A través de la depuración los desarrolladores pueden reproducir los fallos, analizar el estado del
programa y detectar el defecto correspondiente con el objeto de corregirlo
Resumen
El proceso básico de prueba incluye
- Planificación y control
- Selección de condiciones de prueba
- Diseño y ejecución de casos de prueba
- Comprobación de resultados
- Generación de informes respecto del proceso de prueba y el sistema sujeto a prueba
- Finalización y completar actividades de cierre
- Los objetivos de las pruebas pueden ser: la detección de defectos, el nivel de calidad, la
información para la toma de decisiones, prevención de defectos
- El proceso mental y las actividades involucradas en el diseño de prueba de forma
temprana en el ciclo de vida
- Las pruebas dinámicas significan la ejecución del software, las pruebas estáticas
significan la revisión de documentos
- Las pruebas dinámicas muestran fallos que han sido causados por defectos, la
depuración detecta, analiza y elimina la causa del fallo
Contenido

03. Siete principios del proceso de prueba
Principio 1: El proceso de prueba demuestra la presencia de defectos

- El proceso de prueba puede probar la presencia de defectos
- Las desviaciones identificadas a lo largo del proceso de prueba demuestran la presencia de un
fallo
- La causa de un fallo puede no ser obvia
- El proceso de prueba 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 fallos no demuestran la corrección de un producto software
- El mismo proceso de prueba puede contener errores
- Las condiciones de prueba pueden ser inapropiadas para detectar errores
Principio 2: No es posible realizar pruebas exhaustivas

- Pruebas exhaustivas (“exhaustive testing”)
- Enfoque de prueba donde el conjunto de pruebas abarca todas las combinaciones de valores de
entrada y precondiciones
- Explosión de casos de prueba (“test case explosion”)

- Define el incremento factorial de esfuerzo y coste en el caso de pruebas exhaustivas
- Prueba de Muestra (“sample test”)

- La prueba incluye solamente un subconjunto (generado de forma sistemática o aleatoria) de
todos los posibles valores de entrada
- En condiciones reales, se utilizan generalmente una prueba de una muestra. Probar todas las
combinaciones posibles de entradas y precondiciones sólo es económicamente viable en casos
triviales
Principio 3: Pruebas tempranas (“early testing”)

- Cuanto más temprana es la detección de un defecto, menos costosa es su corrección
- Se obtiene una máxima rentabilidad cuando los errores son corregidos antes de la
implementación
- Los conceptos y especificaciones también pueden ser probados
- Los defectos detectados en la fase de concepción son corregidos con los menores esfuerzo y
coste
- La preparación de una prueba también consume tiempo

- El proceso de prueba implica más que sólo la ejecución de la prueba
- Las actividades de prueba pueden ser preparadas antes de que el desarrollo se haya completado
- Las actividades de prueba (incluidas las revisiones) deben se ejecutadas en paralelo a la
especificación y diseño software
Principio 4: Agrupamiento de defectos (“defect clustering”)

- !Encuentre un defecto y encontrará más defectos “cerca”!
- Los defectos aparecen agrupados como hongos o cucarachas
- Vale la pena investigar un mismo módulo donde se ha detectado un defecto
- 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
Principio 5: Paradoja del pesticida

- Repetir pruebas en las mismas condiciones no es efectivo
- Cada caso de prueba debe contar con una combinación única de parámetros de entrada para un
objeto de prueba particular, de lo contrario no se podrá obtener información adicional
- Si se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar nuevos defectos
(“defects”)
- Las pruebas deben ser revisadas/modificadas regularmente para los distintos módulos
de código
- Es necesario repetir una prueba tras una modificación del código (corrección de
defectos, nueva funcionalidad)
- La automatización de pruebas puede resultar conveniente si un conjunto de casos de
prueba se debe ejecutar con frecuencia
Principio 6: Las pruebas dependen del contexto

- Las pruebas se llevan a cabo de forma diferente en diferentes contextos
- Objetos de prueba diferentes son probados de forma diferente
- El controlador del motor de un coche requiere pruebas diferentes respecto de aquellas
para una aplicación de “e-Commerce”
- Entorno de prueba (“test environment”, cama de prueba - “test bed”) vs. entorno de
producción (“production environment”)
- Las pruebas tienen lugar en un entorno distinto del entorno de producción. El entorno
de prueba debe ser muy similar al entorno de producción
- Siempre habrá desviaciones entre el entorno de prueba y el entorno de producción.
Estas desviaciones ponen en tela de juicio las conclusiones que se obtuvieran tras las
pruebas
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!
Resumen
- Las pruebas pueden ayudar a detectar defectos en el software, sin embargo las mismas
no pueden demostrar la ausencia de defectos
- Para casos no triviales las pruebas exhaustivas son imposibles, la prueba de muestras
son necesarias
- Las pruebas tempranas ayudan a reducir costes dado que los defectos descubiertos en
fases tempranas del proceso software son corregidos con menor esfuerzo
- Los defectos se presentan agrupados. El encontrar un defecto en una ubicación
determinada significa que probablemente se encontrará otro defecto a su alrededor
- La repetición de pruebas idénticas no genera nueva información
- Cada entorno particular determina la forma en la cual se ejecutarán/desarrollarán las
pruebas.
- Un software libre de errores no implica su adecuación al uso
Contenido

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:
- Planificación de pruebas y Control
- Análisis de pruebas y diseño de pruebas
- Implementación de pruebas y ejecución de pruebas
- Evaluación de criterios de salida de pruebas y generación de informes de pruebas
- Actividades de cierre de pruebas
- Las fases del proceso de prueba se podrán superponer
El proceso de prueba a lo largo del proceso de desarrollo software

- ¡El proceso de prueba es más
que la ejecución de pruebas! Planificación de pruebas
- Incluye superposición y
Análisis de pruebas
vuelta atrás (“backtracking”) y Diseño de pruebas
Control de pruebas
- Cada fase del proceso de
Implementación de pruebas
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
Control de pruebas – tareas principales

- El control de pruebas es una actividad continua que influye en la planificación de las pruebas. El
plan maestro de prueba (“master test plan”) puede ser
Planificación de pruebas
modificado en función de la información
adquirida a partir del control de prueba
y Diseño de pruebas
Control de pruebas
- El estado del proceso de prueba se determina y Ejecución de pruebas
comparando el progreso logrado con respecto
al plan de pruebas. Se iniciarán aquellas Evaluación del criterio de salida
actividades que se consideraran necesarias
consecuentemente
- Se miden y analizan resultados de pruebas
- La evolución de las pruebas, la cobertura de las pruebas y el cumplimiento de los criterios de salida (“exit
criteria”) de pruebas son objeto de seguimiento y son documentados
- Se inician medidas correctivas
- Se preparan y toman decisiones
Planificación de pruebas – tareas principales

- Determinar el alcance y riesgos Planificación de pruebas
- Identificar los objetivos de las pruebas y Análisis de pruebas
los criterios de salida de pruebas y Diseño de pruebas
Control de pruebas
- Determinar el enfoque: técnicas de pruebas, Implementación de pruebas
y Ejecución de pruebas
cobertura de pruebas, equipo de pruebas
- Implementar el método de prueba/estrategia Evaluación del criterio de salida
de prueba, planificación del período de

tiempo para el desarrollo de las actividades Actividades de cierre
de pruebas
a seguir
- Adquirir/obtener y programar recursos requeridos por las pruebas: personal, entorno de
prueba, presupuesto de prueba
- 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”)
- La implementación de la estrategia de prueba para un proyecto específico. 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
- Criterios de salida (“exit criteria”) [según Gilb and Graham]:
- Conjunto de condiciones genéricas y específicas, acordadas con los involucrados, para que un
proceso sea considerado formalmente concluido. El propósito de los criterios de salida es evitar
que una tarea se considere concluida habiendo partes destacadas de la misma sin completar. Los
criterios de salida son utilizados como referencia para la elaboración de informes y para
planificar cuando se deben finalizar las pruebas. Lo anterior debe ser realizado para cada nivel
de pruebas.
Análisis y diseño de pruebas – tareas principales (1)

- Revisar las bases de prueba (“test basis”) Planificación de pruebas
(requisitos, arquitectura del sistema, diseño,

interfaces) Análisis de pruebas
Control de pruebas
Análisis de la arquitectura del sistema,
diseño del sistema incluyendo las interfaces Implementación de pruebas
entre los objetos de prueba
- Analizar la testabilidad Evaluación del criterio de salida
- Evaluación de la testabilidad de las bases Actividades de cierre

de la pruebas y casos de prueba de pruebas
- Identificar y priorizar condiciones de prueba (“test conditions”) en función de:

- Análisis de los elementos de prueba (“test item”)
- Especificaciones de prueba
- Comportamiento y estructura del software

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

lógicos/ de alto nivel (casos de prueba sin datos Análisis de pruebas
de prueba específicos)
Control de pruebas
- Los casos de prueba positivos dan muestra Implementación de pruebas
de la funcionalidad, los casos de prueba
negativos comprueban situaciones en las Evaluación del criterio de salida
que hay tratamiento de errores
de pruebas
- Identificar condiciones de prueba

específicas y datos de prueba (“test data”) necesarios
- Evaluar la disponibilidad de datos de prueba y/o la viabilidad de generación de datos de prueba

- Diseñar el entorno de prueba Planificación de pruebas
(“test environment”)
[cama de prueba – (“test bed”)] Análisis de pruebas
- (Exclusivo) disponibilidad del entorno de
Control de pruebas
prueba, ventanas temporales Implementación de pruebas
(“time window”), etc.
- Definir la operación del entorno de Evaluación del criterio de salida
prueba, incluyendo la administración

de usuario Actividades de cierre
de pruebas
- Cargar conjuntos de datos (“data sets”) y

parámetros del sistema (“system parameters”)
- Conectar al entorno de prueba con los sistemas adyacentes

- Probar la infraestructura y herramientas de Planificación de pruebas
prueba (“test tools”), si fuera necesario

- Procesos, procedimientos y Análisis de pruebas
responsabilidades
Control de pruebas
- Seleccionar, proveer, instalar y operar Implementación de pruebas
herramientas de prueba
- Crear trazabilidad bidireccional
- Entre las bases de las pruebas y casos Actividades de cierre

de prueba de pruebas
- Datos de prueba (“test data”):

- Datos que existen en el sistema antes de que una prueba sea ejecutada, y que afecta o es
afectado por el componente o sistema sujeto a pruebas
- Datos de entrada (“input data”):

- Variable que es leída por un componente (almacenada tanto dentro como fuera del sistema)
- Cobertura de pruebas (“test coverage”):

- Grado en el que un elemento de especificado ha sido practicado por un juego de pruebas
(expresado como un porcentaje). Utilizado con mayor frecuencia en pruebas de caja blanca con
el objeto de determinar la cobertura de código
- Oráculo de prueba (“test oracle”):

- Fuente que permite determinar los resultados esperados de un software sujeto a pruebas:
comparativas (“benchmarks”) (también resultado de pruebas previas), manuales de usuario o
conocimiento especializado. No debe ser el código.
Implementación y ejecución de pruebas (1)

- Finalizar, implementar y priorizar casos de Planificación de pruebas
prueba
- Identificar datos de prueba Análisis de pruebas
- Desarrollar y priorizar procedimientos de
Control de pruebas
prueba y Ejecución de pruebas
- Crear datos de prueba Evaluación del criterio de salida

- Preparar arneses de prueba* (“test harness”)
[opcional] Actividades de cierre
de pruebas
- Redactar guiones de prueba automatizados*
(“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

- Verificar y actualizar la trazabilidad (bases de Planificación de pruebas
prueba – casos de prueba)

- Ejecutar prueba (de forma manual o Análisis de pruebas
Control de pruebas
automática)
- Seguir la secuencia de prueba establecida en el plan de prueba
(juego de pruebas, orden de los casos de prueba)

- Registrar resultados de prueba y análisis y Generación de informes
- Registrar las identidades y versiones Actividades de cierre

de pruebas
del software herramientas de prueba/
productos de soporte de prueba
(“testware”)

- Comparar resultados reales (“actual results”) Planificación de pruebas
con resultados esperados (“expected results”)

- Informar y analizar incidencias con el objeto de establecer Análisis de pruebas
Control de pruebas
sus causas Implementación de pruebas
- Código/datos de prueba/documento/ejecución
- Repetir actividades de prueba para Evaluación del criterio de salida

confirmar una corrección
- Repetición de prueba (“re-test”)
de pruebas
[después de la corrección de un defecto]

- Ejecutar prueba de regresión
- 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
- 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
- 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
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)
- Evaluar los registros de prueba y Diseño de pruebas
(resumen de las actividades de pruebas,
Control de pruebas
resultados de prueba, comunicar criterio Implementación de pruebas
de salida)
- Proporcionar información con el objeto Evaluación del criterio de salida
de dar lugar a la decisión de llevar a y Generación de informes
cabo pruebas adicionales

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

tareas principales (1)
- Recopilar datos de las actividades del proceso

de prueba finalizadas con el objeto de Análisis de pruebas
consolidar la experiencia, producto de soporte
Control de pruebas
de prueba ("testware"), hechos y números Implementación de pruebas
- Cerrar informes de incidencia o generación

de solicitudes de cambio para cualquier punto Evaluación del criterio de salida
que permaneciera abierto

- Comprobar qué entregables planificados han Actividades de cierre
de pruebas
sido entregados y probados

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

tareas principales (2)
- Documentar la aceptación del sistema

- Finalizar y archivar los productos de soporte de prueba Análisis de pruebas
("testware"), el entorno de prueba y la infraestructura
Control de pruebas
de prueba para un uso posterior, Implementación de pruebas
transferencia/traspaso a operaciones
- Analizar las lecciones aprendidas para futuros Evaluación del criterio de salida
proyectos
- Utilizar la información recopilada para mejorar la Actividades de cierre
de pruebas
madurez del proceso de prueba

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
Contenido

05. Psicología en el proceso de prueba
Roles y responsabilidades
Rol: Desarrollador Rol: Probador (“Tester”)
- Implementa requisitos - Planifica las actividades de
- Desarrolla estructuras pruebas.
- Diseña y programa el software - Diseña casos de prueba
- Su éxito consiste en la creación - Su única preocupación es
de un producto encontrar defectos
- Encontrar errores producidos por
un desarrollador es su éxito
Percepción:
¡La actividad del desarrollador es ¡La actividad del probador
constructiva! (“tester”) es destructiva!
¡Error!
¡Las pruebas también constituyen una actividad constructiva,
su propósito es la eliminación de defectos de un producto!
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
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
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
Pruebas independientes
- 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 a través de un gráfico
de barras
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

- 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

- 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

- 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
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
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
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
Contenido

06. Código ético
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
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
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
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

Capítulo No.1 ISTQB Probador

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Capítulo No.1 ISTQB Probador

Enviado por

Direitos autorais:

Formatos disponíveis

Probador Certificado –

Versión V.1.2a_V ES.1.0

Jaime Orlando Padilla Castro

Tel: 7429797 Ext. 60373

Consta de siete capítulos:

Capítulo I – Fundamentos de pruebas

Capítulo I – Fundamentos de pruebas

La importancia económica del software

Pruebas para la mejora de la calidad

Ejemplo de fallo 1: Lanzamiento del Ariane 5

Ejemplo de fallo 2: Rayos X letales

Causas de fallos (“failure”) software

Error (“Error”) , defecto (“defect”), fallo (“failure”)

- Error (“Error”) (IEEE 610):

Error (“Error”) , defecto (“defect”), fallo (“failure”)

Los defectos causan un fallos

El papel del proceso de prueba en el proceso de desarrollo, mantenimiento y

El coste de los defectos coste relativo

Source: B. Boehm (1981)

Especificación Diseño Construcción Pruebas Aceptación Operación

- Definición: Calidad software (según ISO/IEC 9126):

- Definición: Calidad (según IEEE Std 610):

Tipos de Aseguramiento de la Calidad (QA):

Aseguramiento de la calidad constructivo

- Los defectos introducidos

Aseguramiento de la calidad analítico

Análisis de valores límite

Cobertura de sentencia - Pruebas estáticas

Cobertura de rama evaluación sin la ejecución

Revisiones / revisiones guiadas - Pruebas dinámicas incluye

Análisis del flujo de control

Pruebas y la Calidad – Atributos funcionales de calidad

Funcionalidad (“functionality”) incluye (según ISO/IEC 9126):

Pruebas y la Calidad – Atributos no funcionales de calidad (1)

Pruebas y la Calidad – Atributos no funcionales de calidad (2)

Pruebas y la Calidad – Atributos no funcionales de calidad (3)

Objetivos de las pruebas

¿Cuantas pruebas son suficientes?

- Pruebas basadas en riesgos (“risk-based testing”)

- Pruebas basadas en plazos y presupuesto (“time and budget testing”)

Caso de prueba (“test case”), base de prueba (“test basis”)

Desarrollo software y revisiones

- Desarrollo software (“software development”):

Desarrollo software y revisiones

- Revisión (“review”) [según IEEE Std 1028]:

Capítulo I – Fundamentos de pruebas

Probar significa más que ejecutar pruebas

- La revisión de documentos, código fuente y la realización de análisis estático también

Objetivos de las pruebas

- Generación (logro) de confianza respecto del nivel de Calidad

Términos: Desarrollo Software

Pruebas y depuración (“debugging”)

Probar y repetir la prueba (repetición de prueba – “re-testing”) son actividades propias

La depuración y la corrección de defectos son actividades propias del desarrollador

Capítulo I – Fundamentos de pruebas

Principio 1: El proceso de prueba demuestra la presencia de defectos

Principio 2: No es posible realizar pruebas exhaustivas

- Explosión de casos de prueba (“test case explosion”)

- Prueba de Muestra (“sample test”)

Principio 3: Pruebas tempranas (“early testing”)

- La preparación de una prueba también consume tiempo

Principio 4: Agrupamiento de defectos (“defect clustering”)

- Los probadores (“testers”) deben ser flexibles

Principio 5: Paradoja del pesticida