Capitulo 1

CAPÍTULO 1.
FUNDAMENTOS DE
PRUEBAS
Capítulo 1. Fundamentos de Pruebas
1.1 ¿Qué es probar?
1.1.1 (K1) Objetivos típicos de las pruebas.
1.1.2 (K2) Pruebas y depuración.
1.2 ¿Por qué son necesarias las pruebas?
1.2.1 (K2) Contribución de las pruebas al éxito del proyecto.
1.2.2 (K2) Aseguramiento de calidad y pruebas.
1.2.3 (K2) Errores, defectos y fallos.
1.2.4 (K2) Defectos, causa raíz y efectos.
1.3 Siete principios de las pruebas
1.4 Proceso de pruebas
1.4.1 (K2) El contexto del proceso de pruebas.
1.4.2 (K2) Actividades y tareas de pruebas.
1.4.3 (K2) Productos de trabajo de pruebas.
1.4.4 (K2) Trazabilidad entre las bases de pruebas y los productos de trabajo de
pruebas.
1.5 La psicología de las pruebas
1.5.1 (K1) Psicología y pruebas.
1.5.2 (K2) La mentalidad del tester y del desarrollador.
“Una falla en los sistemas

Hoy en día las organizaciones dependen puede provocar…”
del software para funcionar y llevar a cabo Daño a la
sus operaciones, sistemas, maquinaria, etc., reputación
por lo que cualquier fallo provoca
Perdidas
problemas: como perdidas millonarias, económicas
La muerte
daños a la reputación o incluso la muerte.
Esta dependencia al software, obliga a que

la calidad de este, sea un factor clave para
el éxito de las empresas en cualquier sector,
las pruebas contribuyen a mejorar la
calidad de los sistemas de software.
Las pruebas son una
forma de evaluar la calidad
del software para reducir
el riesgo de que falle
Algunas pruebas involucran la ejecución del componente o sistema
como es el caso de las pruebas dinámicas, existen otros casos en los
cuales las pruebas no involucran la ejecución, estas se enfocan en la
revisión de productos de trabajo como requisitos, historias de
usuario y código fuente, a estas les llamamos pruebas estáticas.
Las pruebas se enfocan en verificar que el sistema cumple con los

requisitos especificados, pero también en validar que el sistema
cumple con la necesidades de los involucrados [usuarios o cualquier
implicado en el proyecto] y los ambientes operativos.
Las actividades de prueba se organizan y llevan a cabo de manera

diferente en diferentes ciclos de vida.
Existe una percepción errónea de que las pruebas sólo

consisten en ejecutar pruebas, es decir, ejecutar el
software y verificar los resultados.
“Las pruebas son mucho

más que ejecutar”
Un proceso de pruebas efectivo incluye:
• Actividades previas a la ejecución: planeación,

análisis, diseño de pruebas, implementación.
• Actividades después de ejecución: evaluación de
criterios de salida, elaboración de informes y
actividades de cierre de prueba.
• Actividades de seguimiento y control: se realizan
durante todo el ciclo de vida del proyecto.
El proceso de pruebas debe incluir también análisis

estático (Revisión de documentos y código).
LA CALIDAD SE
CONSTRUYE DESDE
EL PRINCIPIO
Objetivos típicos de las pruebas
• Prevenir defectos. • Validar si el objeto de

• Encontrar defectos y pruebas está completo y
fallas. funciona como esperan los
• Reducir el nivel de riesgo. implicados.
• Crear confianza en el nivel • Evaluar productos de

de calidad del objeto de trabajo: requisitos,
prueba. historias de usuario,
• Generar información para diseño y código.
la toma de decisiones • Cumplir con requisitos o
informadas. estándares contractuales.
Los objetivos de las pruebas pueden variar, dependiendo del contexto
del sistema, el nivel de prueba y el modelo de ciclo de vida de
desarrollo de software. Estas diferencias pueden incluir, por ejemplo:
• Pruebas durante el análisis del software,

pueden enfocarse a detectar defectos de
definición para evitar errores en la
construcción.
• Las pruebas unitarias que realiza el

programador, pueden tener como objetivo
encontrar tantas fallas como sea posible y
corregirlas de inmediato.
• Las pruebas que realiza el usuario tienen

como objetivo confirmar que la funcionalidad
ha sido construida tal cual lo requirió.
Proceso de pruebas y el proceso de depuración

PROCESO DE PRUEBA PROCESO DE DEPURACIoN PROCESO DE PRUEBA
0100101010 0100101010
1010101010 1010101010
1010101010 1010101010
La prueba La depuración Después La prueba de

detecta un fallo identifica los fallos corrige confirmación
(confirmation test)
verifica que un fallo
específico ha sido resuelto
Pruebas y pruebas de confirmación son parte del proceso
de pruebas…
Depuración y corrección son parte del proceso
de desarrollo
1.2.1 (K2) Contribución de las pruebas al éxito.
1.3 Siente principios de las pruebas
1.4.4 (K2) Trazabilidad entre las bases de pruebas y los productos de
trabajo de pruebas.
Las pruebas reducen el riesgo de

detectar defectos durante la
operación de los sistemas. Reduce riesgos
Contribuyen a mejorar la calidad de
Contribuye
los mismos, siempre y cuando los
defectos sean detectados antes de la a la calidad
Cumplimiento
liberación en producción. de requisitos
contractuales
También sirven para verificar que se
cumplan requisitos contractuales,
legales o estándares de industria.
…porque los
sistemas fallan!!
…porque los sistemas no cumplen

con las necesidades de los
usuarios!!
¿Cómo pueden contribuir las pruebas al éxito del proyecto?
Involucrando a los testers…
• Para detectar defectos en productos de trabajo.

• En revisiones de requisitos o refinamiento de historias del
usuario. Eliminando defectos en requisitos reducimos el riesgo de
construir una funcionalidad incorrecta o no comprobable.
• Colaborando con los diseñadores, para incrementar la
comprensión del diseño y cómo probarlo.
• Con los desarrolladores mientras crean código, puede reducir el
riesgo de defectos dentro del código y las pruebas.
• En actividades de verificación y validación antes de la entrega para
detectar fallas, incrementando la probabilidad de que el software
cumpla con las necesidades de las partes interesadas y satisface los
requisitos.
Aseguramiento de Calidad y Pruebas
• No son lo mismo, pero están relacionadas a través de la gestión de
la calidad.
• La gestión de la calidad incluye todas las actividades que dirigen y
controlan una organización con respecto a la calidad.
Gestión de Calidad
Aseguramiento de calidad Control de calidad
Se enfoca en los procesos para brindar confianza Conjunto de actividades diseñadas para evaluar
en que se lograrán los niveles adecuados de la calidad de un componente o sistema.
calidad.
Mejoran la calidad del producto, a través de Involucra varias actividades, incluyendo
garantizar la ejecución correcta del proceso. actividades de prueba, que apoyan el logro de
niveles adecuados de calidad.
Previenen defectos. Contribuye a la calidad del producto.
Análisis de causa raíz.

Un software tiene calidad

cuando satisface por
completo la necesidad o
requisito del cliente
• ¿QUÉ PROBARIAS?
Modelo de calidad del producto de software (SQuaRE)
Adecuación Funcional
Representa la capacidad del producto software para proporcionar funciones que
satisfacen las necesidades explícitas e implícitas, cuando el producto se usa en
las condiciones especificadas. Esta característica se subdivide en:
• Completitud funcional: Grado en el cual el conjunto de funcionalidades

cubre todas las tareas y los objetivos del usuario especificados.
• Corrección funcional: Capacidad del producto o sistema para proveer
resultados correctos con el nivel de precisión requerido.
• Funcionalidad apropiada: Capacidad del producto software para
proporcionar un conjunto apropiado de funciones para tareas y objetivos de
usuario especificados.
Eficiencia de Desempeño
Esta característica representa el desempeño relativo a la cantidad de recursos
utilizados bajo determinadas condiciones. Esta característica se subdivide en:
• Comportamiento temporal: Los tiempos de respuesta y procesamiento de

un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas
en relación contra lo esperado (benchmark).
• Utilización de recursos: Las cantidad y tipos de recursos utilizados cuando el
software lleva a cabo su función bajo condiciones determinadas.
• Capacidad: Grado en que los límites máximos de un parámetro de un
producto o sistema software cumplen con los requisitos.
Compatibilidad
Capacidad de dos o más sistemas o componentes para intercambiar
información y/o llevar a cabo sus funciones requeridas cuando comparten el
mismo entorno hardware o software. Esta característica se subdivide en:
• Co-existencia: Capacidad del producto para coexistir con otro software

independiente, en un entorno común, compartiendo recursos comunes sin
detrimento.
• Interoperabilidad: Capacidad de dos o más sistemas o componentes para
intercambiar información y utilizar la información intercambiada.
Usabilidad
Capacidad del producto software para ser entendido, aprendido, usado y
atractivo para el usuario, cuando se usa bajo determinadas condiciones. Esta
característica se subdivide en:
• Capacidad para reconocer su adecuación: Capacidad del producto que permite al

usuario entender si el software es adecuado para sus necesidades.
• Capacidad de aprendizaje: Capacidad del producto que permite al usuario aprender
su aplicación.
• Capacidad para ser usado: Capacidad del producto que permite al usuario operarlo y
controlarlo con facilidad.
• Protección contra errores de usuario: Capacidad del sistema para proteger a los
usuarios de cometer errores.
• Estética de la interfaz de usuario: Capacidad de la interfaz de usuario de agradar y
satisfacer la interacción con el usuario.
• Accesibilidad: Capacidad del producto que permite que sea utilizado por usuarios con
determinadas características y necesidades especiales.
Fiabilidad
Capacidad de un sistema o componente para desempeñar las funciones
especificadas, cuando se usa bajo condiciones y periodo de tiempo
determinados. Esta característica se subdivide en:
• Madurez: Capacidad del sistema para satisfacer las necesidades de fiabilidad

en condiciones normales.
• Disponibilidad: Capacidad del sistema o componente de estar operativo y
accesible para su uso cuando se requiere.
• Tolerancia a fallos: Capacidad del sistema o componente para operar según
lo previsto en presencia de fallos hardware o software.
• Capacidad de recuperación: Capacidad del producto software para
recuperar los datos directamente afectados y reestablecer el estado deseado
del sistema en caso de interrupción o fallo.
Seguridad
Capacidad de protección de la información y los datos de manera que personas
o sistemas no autorizados no puedan leerlos o modificarlos. Esta característica
se subdivide en:
• Confidencialidad. Capacidad de protección contra el acceso de datos e

información no autorizados, ya sea accidental o deliberadamente.
• Integridad. Capacidad del sistema o componente para prevenir accesos o
modificaciones no autorizados a datos o programas de ordenador.
• No repudiación: Capacidad de demostrar las acciones o eventos que han
tenido lugar, de manera que dichas acciones o eventos no puedan ser
repudiados posteriormente.
• Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de
una entidad.
• Autenticidad. Capacidad de demostrar la identidad de un sujeto o un
recurso.
Mantenibilidad
Esta característica representa la capacidad del producto software para ser modificado
efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta
característica se subdivide en:
• Modularidad.: Capacidad de un sistema (compuesto de componentes) que permite

que un cambio en un componente tenga un impacto mínimo en los demás.
• Reusabilidad: Capacidad de un activo que permite que sea utilizado en más de un
sistema software o en la construcción de otros activos.
• Analizable: Facilidad con la que se puede evaluar el impacto de un determinado
cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el
software, o identificar las partes a modificar.
• Capacidad para ser modificado: Capacidad del producto que permite que sea
modificado de forma efectiva y eficiente sin introducir defectos o degradar el
desempeño.
• Capacidad para ser probado: Facilidad con la que se pueden establecer criterios de
prueba para un sistema o componente y con la que se pueden llevar a cabo las
pruebas para determinar si se cumplen dichos criterios.
Portabilidad
Capacidad del producto o componente de ser transferido de forma efectiva y
eficiente de un entorno hardware, software, operacional o de utilización a otro.
Esta característica se subdivide en:
• Facilidad de instalación: Capacidad con la que el producto se puede instalar

y/o desinstalar de forma exitosa en un determinado entorno.
• Capacidad para ser reemplazado: Capacidad del producto para ser utilizado
en lugar de otro producto software determinado con el mismo propósito y en
el mismo entorno.
• Adaptabilidad: Capacidad del producto que le permite ser adaptado de
forma efectiva y eficiente a diferentes entornos determinados de hardware,
software, operacionales o de uso.
Los errores pueden ocurrir por…
Errores Humanos
• Errores de programación.
• Construir obviando la definición del requisito.
• Presión de tiempo.
• Complejidad del código, diseño, arquitectura.
• Falta de control del código fuente.
• Involucrados en el proyecto sin experiencia/poca capacitación.
Condiciones Ambientales
• Radiación, campos electromagnéticos y contaminación.
• Cambios o falta del suministro de energía eléctrica.
• Fallas en discos duros.
• Tormentas solares.
Defectos, causa raíz y efectos
Las causas raíz de los defectos son las primeras acciones o
condiciones que contribuyeron a crear los defectos.
Generalmente para resolver cualquier problema, revisamos la causa raíz.

En las pruebas de software el mejor enfoque es el análisis de causa
raíz.
Los defectos se pueden analizar para identificar sus causas raíz, a fin de
reducir la aparición de defectos similares en el futuro.
Al centrarse en las causas

más importantes, el análisis
de la causa raíz puede
conducir a mejoras en los
procesos que impidan la
introducción de defectos en
el futuro.
Durante el análisis se revisa ¿QUÉ, CUÁl es

desde la última acción el problema ¿POR QUÉ
posible hacía la anterior, y así principal? SUCEDIÓ?
sucesivamente hasta llegar al
origen del problema y al
punto exacto en el que se
introdujo un defecto.
¿cuándo
ocurrió? ¿cómo se puede
Algunas preguntas que evitar?
podemos hacer para obtener
información:
1.2 ¿Por qué es necesario probar?
El análisis también sirve para prevenir defectos. Identificando los
factores más comunes que provocan los defectos en cada fase del ciclo
de vida del software para rastrear el origen del defecto y el momento
en el que se inyectó en el sistema.
Algunos ejemplos de causas:
• Requisitos inadecuados
• Falta de pruebas unitarias
• Problema de comunicación
• Supuesto incorrecto
• Brechas de diseño
• Ambiente inapropiado
• Cobertura de pruebas deficiente
• Datos de prueba ineficaces
trabajo de pruebas.
1.3 Siete principios de pruebas
1. Las pruebas muestran la presencia de defectos
Las pruebas pueden mostrar

que hay defectos en el
objeto de prueba, pero no la
ausencia de los mismos.
2. No es posible realizar pruebas exhaustivas
Establecer un enfoque de pruebas

que incluya todas las
combinaciones de valores de
entrada y precondiciones que un
objeto de prueba puede tener,
representa un costo y esfuerzo alto y
al final resulta imposible.
En lugar de pretender hacer pruebas
exhaustivas se debe centralizar el
esfuerzo de las pruebas, utilizando
por ejemplo un enfoque de pruebas
basadas en riesgos.
3. Pruebas tempranas
Realizar pruebas en una etapa

temprana del proyecto permite
mejorar la calidad del objeto de
prueba, ya que se detectan
defectos desde las
especificaciones y con ello se
reduce el costo de corrección de
defectos.
Las pruebas estáticas y dinámicas
deben iniciar lo antes posible en el
ciclo de vida del desarrollo .
4. Los defectos se agrupan
El esfuerzo de las pruebas debe
enfocarse en la densidad de
defectos, es posible que por las
pruebas tempranas o
experiencia sabemos que
algunos módulos son los más
problemáticos, por lo que
deberá enfocarse un mayor
esfuerzo de pruebas para los
mismos. Generalmente los fallos
detectados se encontrarán en un
número reducido de módulos.
5. La paradoja del pesticida
Realizar las mismas pruebas en las mismas
condiciones provocará que se dejen de
detectar defectos.
Para vencer la “Paradoja del Pesticida”:

• Revisa los casos de prueba y reescribe
nuevas pruebas.
• Prueba con datos de prueba distintos,
diferentes perfiles, diferentes ambientes.
• Asegúrate de que el objeto de prueba se
evalué desde otros ángulos con el
propósito de encontrar nuevos defectos y
que estos se solucionen de raíz.
• Realiza intercambios en el equipo.
6. Las pruebas dependen del contexto
Las pruebas se llevan a cabo dependiendo

del contexto del objeto de prueba.
Las pruebas que se planean para un sitio

de comercio electrónico, varían respecto a
las pruebas que se realizan en un software
de seguridad crítica.
La diferencia de contextos en los sistemas

también da origen a priorizar ciertas
pruebas no funcionales sobre otras al igual
que la profundidad que se necesita en la
pruebas, por ejemplo dos sistemas pueden
ser similares pero tener riesgos diferentes.
7. La falacia de la ausencia de errores
Ningún proceso de pruebas puede asegurar

que el objeto de prueba esta libre de
defectos.
En muchas ocasiones los ambientes de
prueba y operación pueden tener variaciones
por procesamiento de datos o configuración,
que podrían provocar fallos que el proceso de
pruebas no logro detectar. Debemos
considerar también el hecho de que el
software puede no cumplir con las
expectativas del usuario, lo que provocará
que sea inservible.
1.4.4 (K2) Trazabilidad entre las bases de pruebas y los
productos de trabajo de pruebas.
No existe un proceso de prueba de software universal, pero existen

conjuntos de actividades de prueba que incrementan las probabilidades
de alcanzar los objetivos establecidos. A estos conjuntos de actividades
de prueba se les conoce como Proceso de prueba.
Un proceso de prueba específico y adecuado depende de muchos

factores. Por lo que se tiene que definir qué actividades de prueba están
involucradas cómo se implementan y cuándo ocurren.
Esto se define en la estrategia de pruebas de una organización.

LA PRUEBA DE SOFTWARE
ES UN PROCESO, NO UNA
SOLA ACTIVIDAD
Existen factores que influyen en el proceso de prueba, como:
• Modelo de desarrollo de software y metodologías en uso.

• Niveles y tipos de prueba considerados.
• Riesgos de producto y proyecto.
• Dominio de negocio.
• Restricciones operativas, como:
• Presupuestos y recursos.
• Tiempo disponible.
• Complejidad
• Requisitos contractuales y reglamentarios.
• Políticas y prácticas organizativas.
• Estándares/normas requeridos tanto internos como externos.
En la definición de un proceso de pruebas se tienen que considerar
algunos aspectos generales, tales como:
• Actividades y tareas de pruebas.

• Productos de trabajo.
• Trazabilidad entre la bases de prueba y los productos de
trabajo.
• Criterios de cobertura definidos. Estos pueden actuar como
indicadores clave de rendimiento (KPI) para impulsar las
actividades que demuestran el logro de los objetivos de la
prueba.
La norma ISO/IEC/IEEE 29119-2

tiene más información sobre los
procesos de prueba.
Un proceso de pruebas consiste principalmente Planeación de

Pruebas
en los siguientes grupos de actividades:
Control y Seguimiento de las pruebas

Cada grupo de actividades está compuesto por Análisis de Pruebas
tareas individuales que varían de un proyecto a
otro.
Diseño de Pruebas
Hay que considerar que estas actividades no
tienen que ejecutarse secuencialmente, si se Implementación de
requiere optimizar tiempo, las actividades la Prueba
pueden realizarse en paralelo.

Ejecución de
Pruebas
El proceso de pruebas y sus entregables se
deben adaptar al contexto y necesidad de cada Finalización de la
proyecto. Prueba
Entrada:
Base de Pruebas
Planeación de Salida:
• Plan de Pruebas Maestro
Pruebas • Cronograma
Objetivo
Análisis de Pruebas
Durante esta fase se identifica la

Diseño de Pruebas
necesidad del cliente para definir un
plan que permita establecer el
Implementación de
la Prueba objetivo de las pruebas y con ello las
actividades necesarias para cumplir
Ejecución de
Pruebas este objetivo.
Compleción de la
Prueba
Planeación de
Pruebas Tareas
Análisis de Pruebas • Determinar lo que esta fuera y dentro del

alcance de la prueba.
• Identificar y analizar riesgos.
Diseño de Pruebas
• Identificar el objetivo de las pruebas.
• Determinar el enfoque de la prueba
Implementación de [Técnicas a utilizar, cobertura, identificación
la Prueba
e interface con los equipos involucrados en
Ejecución de las pruebas, testware].
Pruebas • Determinar recursos humanos y materiales.
• Establecer el calendario de trabajo.
Finalización de la
Prueba • Establecer criterios de salida.
Planeación de
Pruebas
Control y Seguimiento de las pruebas Productos de Trabajo [Testware]
• “Plan de Pruebas Maestro” (Master Test
Plan), que incluye información sobre la base
Diseño de Pruebas de prueba (trazabilidad), así como los
criterios de salida o definición del "done“.
Implementación de También describe la información que se
la Prueba utilizará para el control y seguimiento de las
pruebas.
Ejecución de
Pruebas • Plan de trabajo [cronograma de actividades.
Finalización de la
Prueba
Entrada:
Plan de pruebas, Métricas.
Planeación de

Pruebas Objetivo
Esta es una actividad continua del
proyecto, compara el avance del plan
Diseño de Pruebas de trabajo planeado contra el real.
Implementación de
la Prueba Monitorea las métricas definidas en el
plan de pruebas. El control implica
Ejecución de
Pruebas tomar las acciones necesarias para
cumplir con los objetivos.
Finalización de la
Prueba
Salida:
Actualización del plan de pruebas, Informe del progreso, Informe de resumen.
Planeación de
Pruebas
Tareas
• Medir y analizar resultados (revisiones y
pruebas).
Análisis de Pruebas • Verificar los resultados de las pruebas con

respecto a los criterios de cobertura
especificados.
Diseño de Pruebas
• Evaluar el nivel del sistema según los resultados
de las pruebas y los registros.
Implementación de • Determinar si se necesitan más pruebas.
la Prueba
• Monitorear el progreso del plan de trabajo
cobertura de pruebas, criterios de salida.
Ejecución de
Pruebas
• En caso de detectar desviaciones se deben
tomar las acciones correctivas.
Finalización de la • Tomar decisiones o proporcionar información
Prueba para la toma de decisiones.
Planeación de Productos de Trabajo [Testware]

Pruebas
• Informes de prueba como: informes de

progreso e informes de resumen de
pruebas; esta documentación debe
Diseño de Pruebas proporcionar información relevante para
los involucrados.
Implementación de
la Prueba • Actualización de documentos relacionados
con la gestión de proyectos, como
Ejecución de finalización de tareas, asignación y uso de
Pruebas
recursos, y esfuerzo.
Finalización de la
Prueba • Métricas.
Planeación de
Pruebas
Entrada: Cronograma, Base
Objetivo
de Prueba, Plan de Pruebas
El análisis es la actividad en donde
Salida: Trazabilidad,
condiciones de Pruebas, definimos “QUÉ” vamos a probar.
defectos de la base de pruebas
Diseño de Pruebas
Durante esta actividad se analiza la
Implementación de
base de la prueba para identificar
la Prueba características comprobables y
definir condiciones de pruebas.
Ejecución de
Pruebas
Finalización de la
Prueba
Tareas
Planeación de Analizar las bases de pruebas, como:
Pruebas
• Requisitos de negocios, funcionales, de sistema,
historias de usuario, épicas, casos de uso o
Análisis de Pruebas productos de trabajo similares que describan el

componente funcional o no funcional deseado o
el comportamiento del sistema.
Diseño de Pruebas
• El diseño como la arquitectura del sistema o
software.
Implementación de • La implementación del componente, incluyendo
la Prueba
código, base de datos, consultas e interfaces.
• Informes de análisis de riesgo, considerando
Ejecución de
Pruebas
aspectos funcionales, no funcionales y
estructurales.
Finalización de la • Evaluar la comprobabilidad de los requisitos y el
Prueba objeto de prueba.
• Identificar las condiciones de prueba.
Planeación de
Pruebas
Productos de Trabajo [Testware]
Diseño de Pruebas • Condiciones de prueba definidas y

priorizadas, cada una rastreable a la base
Implementación de de prueba que cubre.
la Prueba • Para pruebas exploratorias, se crean las
cartas de prueba [Test charter].
Ejecución de
Pruebas
• Defectos de la base de prueba*.
Finalización de la *Ambigüedades: omisiones, inconsistencias, contradicciones,

Prueba declaraciones superfluas, entre otros.
Planeación de
Pruebas
Objetivo
Entrada: Trazabilidad, El análisis se transforma en un

diseño tangible de “casos de
condiciones de prueba
Diseño de Pruebas
prueba”, que define el “CÓMO”
Salida: Casos de prueba
priorizados, conjuntos de
prueba
probar.
Implementación de
la Prueba Durante el diseño de la prueba, se
Ejecución de
crean casos de prueba derivados
Pruebas de las condiciones de prueba.
Finalización de la
Prueba
Planeación de
Pruebas Tareas
Control y Seguimiento de las pruebas • Diseño y priorización de casos y conjuntos de
Análisis de Pruebas casos de prueba.
• Identificación de los datos de prueba necesarios
para soportar las condiciones de prueba.
Diseño de Pruebas • Diseñar la configuración del ambiente de prueba
e identificar cualquier infraestructura y
Implementación de
herramientas necesarias.
la Prueba • Actualizar la trazabilidad entre la base de prueba,
las condiciones, los casos de prueba y los
Ejecución de procedimientos de prueba.
Pruebas
La elaboración de casos de prueba regularmente
Finalización de la implica utilizar técnicas de prueba [Capítulo 4].
Prueba
Planeación de

Pruebas
• Casos de prueba concretos para datos de
entrada y resultados esperados.
Diseño de Pruebas • Casos de prueba trazables a las
condiciones de prueba que cubre.
Implementación de • Identificación de datos.
la Prueba • Las condiciones de prueba definidas en el
análisis se pueden refinar durante esta
Ejecución de etapa.
Pruebas
• Defectos de la base de prueba.
Finalización de la
Prueba
Planeación de
Pruebas Objetivo
Análisis de Pruebas Preparar procedimientos o guiones

de prueba, verificar el ambiente de

Diseño de Pruebas prueba y preparar cualquier dato
Entrada: Cronograma,
plan de Prueba, casos
que se requiera para llevar a cabo
de prueba
Implementación de
para la ejecución de las pruebas.
la Prueba
Salida: Procedimientos de
pruebas, scrpts, ambiente,
arneses, datos.
La implementación de la prueba
Ejecución de responde a la pregunta "¿Tenemos
Pruebas
todo lo necesario para ejecutar
Finalización de la las pruebas?”
Prueba
Tareas
Planeación de
• Generar y/o completar el testware necesario
Pruebas
para la ejecución de la prueba.
• Crear y priorizar procedimientos de prueba.
Análisis de Pruebas • Diseñar scripts de prueba automatizados.
• Definir suites de prueba a partir de los
procedimientos y scripts automatizados.
Diseño de Pruebas
• Calendarizar las suites para una ejecución
eficiente.
Implementación de • Crear el ambiente: arneses, virtualización,
la Prueba
simuladores, etc. Probar que todo se ha
configurado correctamente.
Ejecución de
Pruebas
• Preparar datos de prueba y verificar que se
cargan correctamente en el ambiente.
Finalización de la • Verificar y actualizar la trazabilidad bidireccional
Prueba entre la base de prueba, las condiciones, casos
de prueba, procedimientos y suites de prueba.
Planeación de
Pruebas

• Procedimientos de prueba y la secuencia

Diseño de Pruebas de ejecución.
• Suites de prueba.
Implementación de • Calendario de ejecución de pruebas.
la Prueba • Las condiciones de prueba definidas en el
análisis se pueden refinar durante esta
Ejecución de etapa.
Pruebas
Finalización de la
Prueba
Planeación de
Pruebas
Objetivo
Durante esta etapa, las suites de

Diseño de Pruebas
prueba se ejecutan de acuerdo con el
programa/calendario de ejecución de
Implementación de la prueba.
la Prueba
Entrada: Bases de prueba, casos de prueba,
scripts, procedimientos de pruebas
Ejecución de
Pruebas
Salida: Test log, incidencias.
Finalización de la
Prueba
Planeación de Tareas
Pruebas • Registro de versiones de los objetos de prueba,
Control y Seguimiento de las pruebas software y herramientas utilizadas.
• Ejecutar pruebas de forma manual o con
herramientas.
• Comparar resultados reales con resultados
esperados.
Diseño de Pruebas
• Analizar anomalías para establecer sus posibles
causas.
Implementación de • Informar defectos basados en las fallas observadas.
la Prueba • Registrar el resultado de la ejecución [Ej. Pasó,
Falló, Bloqueado].
Ejecución de • Pruebas de confirmación [Confirmation test].
Pruebas
• Pruebas de regresión.
• Verificar y actualizar la trazabilidad bidireccional
Finalización de la
entre la base de prueba, las condiciones de prueba,
Prueba
los casos de prueba, procedimientos y resultados.
Planeación de
Pruebas
Control y Seguimiento de las pruebas Productos de Trabajo [Testware]
• Documentación del estado de los casos de
prueba individuales o procedimientos de
Diseño de Pruebas
prueba.
• Informes de defectos.
Implementación de • Documentación de los objetos de prueba,
la Prueba
herramientas y software que participaron
Ejecución de en la ejecución.
Pruebas • La información anterior puede estar
descrita en la bitácora de pruebas [Test log].
Finalización de la
Prueba
Planeación de
Pruebas Objetivo
Análisis de Pruebas Recopilar datos de las actividades de
prueba completadas para consolidar
Diseño de Pruebas
experiencia, testware, datos y cifras.
Implementación de
Estas actividad se puede realizar para
la Prueba cada hito del proyecto, por ej. cuando se
libera un sistema, cuando el proyecto de
Ejecución de
Pruebas
pruebas se completa o se cancela; en
Entrada: Control de proyectos agiles cuando se termina una
iteración y se reporta durante la reunión
incidencias, informes
de prueba
Finalización de la
Prueba
de retrospectiva.
Salida: Informes de prueba y cierre,
lecciones aprendidas.
*Compleción de la prueba
Planeación de Tareas
Pruebas • Finalizar y archivar el ambiente, los datos de
Control y Seguimiento de las pruebas prueba, la infraestructura de prueba para que
Análisis de Pruebas pueda ser reutilizado.
• Entregar el testware a los equipos de

Diseño de Pruebas mantenimiento, a otros equipos de proyectos y/o
interesados [stakeholders] que podrían
Implementación de
beneficiarse con su uso.
la Prueba
• Analizar las lecciones aprendidas y determinar los
Ejecución de cambios necesarios para futuras iteraciones,
Pruebas proyectos y liberaciones.
Finalización de la • Usar la información recopilada para mejorar la

Prueba
madurez del proceso de pruebas.
Planeación de
Pruebas
• Informes de pruebas.
Diseño de Pruebas • Elementos de acción para mejorar
los siguientes proyectos o
Implementación de
la Prueba
iteraciones.
• Solicitudes de cambio o
Ejecución de
Pruebas
actualización del product backlog.
• Testware final.
Finalización de la
Prueba
Trazabilidad
La trazabilidad es la capacidad de identificar elementos relacionados en la
documentación y el software, tales como requisitos con las pruebas asociadas.
Caso de Prueba 1
Caso de Prueba 2
Caso de Prueba …
Condición de Prueba 1
Escenario de Pruebas 1
Requisito A Condición de Prueba 2
Condición de Prueba 3
Caso de Prueba 1
Condición de Prueba 1 Caso de Prueba 2
Objeto de Condición de Prueba 2 Caso de Prueba …
Requisito B
Prueba Condición de Prueba 3 Escenario de Pruebas 2
Condición de Prueba 1 Caso de Prueba 1

Requisito C Condición de Prueba 2 Caso de Prueba 2
Condición de Prueba 3 Caso de Prueba …
Escenario de Pruebas 3
Trazabilidad entre bases de prueba y los productos de trabajo
Para implementar un control y seguimiento efectivo de las pruebas, es

importante establecer y mantener la trazabilidad durante todo el
proceso de pruebas entre cada elemento de la base de prueba y los
diversos productos de trabajo asociados a estos elementos.
Una buena trazabilidad permite…

Evaluar la calidad del
producto, la capacidad
del proceso y el avance
Cumplir con los
del proyecto en
criterios de gobierno Auditar las
relación con los
de TI pruebas
objetivos de negocio
01 02 03 04 05 06
Relacionar los aspectos Mejorar la
Analizar el impacto técnicos de las pruebas comprensión de los
de los cambios con los involcrados en informes de progreso
términos que puedan y de pruebas
entender
1.3 Siente principios de las pruebas
trabajo de pruebas.
Anteriormente se consideraba que el objetivo de las pruebas era

mostrar que el sistema cumplía con los requisitos definidos. Con el
tiempo, las pruebas evolucionaron y el objetivo principal es encontrar
fallas en lugar de sólo demostrar que esté correcta la implementación
del requisito.
La identificación de defectos durante las pruebas estáticas, el

refinamiento de historias de usuario, las pruebas dinámicas y diferentes
actividades de pruebas en ocasiones se percibe como una crítica del
producto y/o al autor.
Por lo tanto, las pruebas se perciben como un proceso destructivo.

Esta percepción, viene acompañada de un elemento en la psicología

humana llamado "sesgo de confirmación“ que puede dificultar la
aceptación de información que no esté de acuerdo con las creencias
propias.
Por ejemplo, los desarrolladores esperan que su código esté correcto, el

sesgo de confirmación les dificulta aceptar que el código tiene defectos.
Como resultado de estos factores psicológicos, algunas personas

pueden percibir las pruebas como una actividad destructiva, a pesar de
que contribuye enormemente al progreso del proyecto y la calidad del
producto.
¡Pero buscar fallos es constructivo!

• Ahorran tiempo
• Mitigan riesgos
• Reducen costos
• Mejoran las habilidades de los
involucrados
La mentalidad del tester y del desarrollador
El desarrollador tiene una mente orientada a las soluciones, mientras que el tester
está orientado a los problemas, es decir, busca "cómo romper" las cosas en lugar
de "cómo construirlas“.
¿Qué puedo hacer para romper
el sw o encontrar debilidades?
¿Qué debe de hacer el sw, qué
necesito para construirlo?
El desarrollador tiene un apego emocional a su

trabajo, es difícil encontrar defectos en algo
creado por uno mismo.
El tester prueba límites, tiene curiosidad de cómo
funciona el sw, qué lo hace funcionar, sabe que tiene
defectos y su reto es encontrarlos.
Diferentes objetivos, diferentes formas de pensar…
Objetivos
El desarrollo tiene como objetivo diseñar y construir un
producto, las pruebas tienen por objetivo verificar y validar el
producto para encontrar defectos antes la liberación.
Formas de Pensar
• Tester: Incluye curiosidad, pesimismo profesional, ojo critico,
atención al detalle y una motivación para comunicar y
relacionarse de forma buena y positiva.
• Desarrolador: Incluye algunos elementos del tester, pero están

más interesados en diseñar y crear soluciones que ver lo que
podría estar mal.
Como testers debemos ser:
• Imparciales
• Consejeros
• Constructivos
• Diplomáticos
• No estamos en contra de ellos,
estamos en el mismo equipo. Tenemos
que trabajar con ellos, no contra ellos.
“La calidad es responsabilidad de todo el

equipo”
Acciones para mejorar la relación del tester y el

desarrollador…
1. Reporta las incidencias de una manera

clara, objetiva y centrada en los hechos,
sin criticar al autor.
2. Confirma que los hechos comunicados

son claramente entendidos.
3. La descripción de un defecto o fallo debe

estar enfocada en la causa y no solo en
los síntomas.
¿Cómo podemos mejorar nuestra comunicación?
1. Discute un problema, no con una persona.

2. Comunica con hechos, no con juicios.
3. Enfócate en el futuro, no en el pasado.
4. Enfatiza los beneficios de las pruebas.
5. Se específico.
6. Se empático.

Capitulo 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

Capitulo 1

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO 1.

“Una falla en los sistemas

daños a la reputación o incluso la muerte.

Esta dependencia al software, obliga a que

Las pruebas se enfocan en verificar que el sistema cumple con los

Las actividades de prueba se organizan y llevan a cabo de manera

Existe una percepción errónea de que las pruebas sólo

“Las pruebas son mucho

Un proceso de pruebas efectivo incluye:

• Actividades previas a la ejecución: planeación,

El proceso de pruebas debe incluir también análisis

• Prevenir defectos. • Validar si el objeto de

• Crear confianza en el nivel • Evaluar productos de

• Pruebas durante el análisis del software,

• Las pruebas unitarias que realiza el

• Las pruebas que realiza el usuario tienen

Proceso de pruebas y el proceso de depuración

La prueba La depuración Después La prueba de

Las pruebas reducen el riesgo de

…porque los sistemas no cumplen

• Para detectar defectos en productos de trabajo.

Análisis de causa raíz.

Un software tiene calidad

• Completitud funcional: Grado en el cual el conjunto de funcionalidades

• Comportamiento temporal: Los tiempos de respuesta y procesamiento de

• Co-existencia: Capacidad del producto para coexistir con otro software

• Capacidad para reconocer su adecuación: Capacidad del producto que permite al

• Madurez: Capacidad del sistema para satisfacer las necesidades de fiabilidad

• Confidencialidad. Capacidad de protección contra el acceso de datos e

• Modularidad.: Capacidad de un sistema (compuesto de componentes) que permite

• Facilidad de instalación: Capacidad con la que el producto se puede instalar

Los errores pueden ocurrir por…

Generalmente para resolver cualquier problema, revisamos la causa raíz.

Al centrarse en las causas

Durante el análisis se revisa ¿QUÉ, CUÁl es

Algunos ejemplos de causas:

Las pruebas pueden mostrar

Establecer un enfoque de pruebas

Realizar pruebas en una etapa

Para vencer la “Paradoja del Pesticida”:

Las pruebas se llevan a cabo dependiendo

Las pruebas que se planean para un sitio

La diferencia de contextos en los sistemas

Ningún proceso de pruebas puede asegurar

No existe un proceso de prueba de software universal, pero existen

Un proceso de prueba específico y adecuado depende de muchos

Esto se define en la estrategia de pruebas de una organización.

Existen factores que influyen en el proceso de prueba, como:

• Modelo de desarrollo de software y metodologías en uso.

• Actividades y tareas de pruebas.

La norma ISO/IEC/IEEE 29119-2

Un proceso de pruebas consiste principalmente Planeación de

Control y Seguimiento de las pruebas

pueden realizarse en paralelo.

Durante esta fase se identifica la

Análisis de Pruebas • Determinar lo que esta fuera y dentro del

Control y Seguimiento de las pruebas

Análisis de Pruebas • Verificar los resultados de las pruebas con

Planeación de Productos de Trabajo [Testware]

• Informes de prueba como: informes de

Análisis de Pruebas productos de trabajo similares que describan el

Diseño de Pruebas • Condiciones de prueba definidas y

Finalización de la *Ambigüedades: omisiones, inconsistencias, contradicciones,

Entrada: Trazabilidad, El análisis se transforma en un