TESTER

Nivel 01

Lección 01

Ética profesional. Asegura a tus clientes que tu desempeño es profesional, apóyate en códigos
de normas y valores como:
Cuidar la integridad de tu cliente y empleador en el ámbito personal y en el público
Garantizar que los productos que entregas cumplan con los más altos estándares de calidad
Mostrar tu honestidad
Comunicar los resultados
No alterar datos de tu cliente sin consultarlo
Fomentar un ambiente ético en la gestión de las pruebas y entregar resultados.

Medidas de seguridad y salud laboral.

Lección 02

Principios de las pruebas

1. Sirven para demostrar que existen defectos en el software, efectuar una prueba donde
no se encuentren defectos, no significa que estos no existan, solo que la prueba no
pudo detectarlos.
2. No es posible realizar una prueba que cubra todas las variables y necesidades del
cliente.
3. Se realizan al inicio del ciclo de vida de los productos.
4. Agrupar por tipo para revisar el software, esto te ayudará a detectar el mismo tipo de
defecto más rápido.
5. Deben actualizarse periódicamente para nuevos errores.
6. Se efectúan dependiendo del funcionamiento del software.
7. El producto final debe cumplir con las expectativas del usuario.

Proceso de pruebas

Se conforma de cinco elementos principales que contemplan todo el ciclo de vida de un

producto.
 Planificación y control. La planificación de pruebas es la actividad para definir los objetivos y
cumplir metas establecidas, tales como identificar defectos, aumentar el nivel de calidad del
software, facilitar información para la toma de decisiones, evitar la aparición de defectos.

Análisis y diseño de pruebas. Transforman los objetivos en tareas que debemos hacer, por
ejemplo, revisar la base de pruebas, requisitos e informes de análisis de riesgo, identificar y dar
prioridad a las condiciones de la prueba con base en el análisis de los elementos la especificación,
el comportamiento y la estructura del sistema, diseñar y ordenar los casos de prueba, identificar
los datos de prueba, diseñar la configuración del entorno de las pruebas.

Ejecución. Es la actividad en la que se especifican los procedimientos, esta incluye las siguientes
tareas: verificar que el entorno de las pruebas haya sido debidamente configurado, implementar
los casos de prueba, registrar los resultados de la ejecución.

Evaluación de los criterios de salida e informes. Es la actividad que compara la ejecución de las
pruebas contra los objetivos definidos, consta de las siguientes tareas: comprobar los resultados
contra los valores previstos en la planificación de la prueba, evaluar si se requieren más pruebas,
elaborar un resumen de las pruebas para tu equipo de trabajo y tu cliente.

Actividades de cierre. Aquí se recopilan los datos de las pruebas terminadas y además se
realizan las siguientes actividades: comprobar que documentos han sido entregados, cerrar los
informes de incidencias, documentar cuantos usuarios aceptaron el sistema, archivar los
productos de soporte, entorno y la infraestructura para usarlos en futuras prueba, utilizar la
información recopilada para mejorar la madurez de las pruebas.

Modelos de prueba

Contiene la forma en la que puedes aplicar los diferentes tipos de prueba para software.

Modelo V o desarrollo secuencial. Se basa en los siguientes cuatro niveles de prueba:

 Nivel 1 Pruebas de componente
 Nivel 2 Pruebas de integración
 Nivel 3 Pruebas de sistema
 Nivel 4 Pruebas de aceptación

Durante el proceso de trabajo, este modelo podría contener más niveles.

Modelo de desarrollo iterativo-incremental. Es un proceso que forma un grupo de tareas, las

cuales pertenecen solo a una pequeña parte del sistema y sirven para probarlo, las iteraciones son
el número de veces que realizas una prueba modificando algunas condiciones y es incremental
porque no se puede pasar a la siguiente prueba sin haber terminado la anterior.
 Niveles de prueba

Pruebas de componentes. Tienen como objetivo localizar defectos y probar el funcionamiento

de los módulos del software de forma neutral y están enfocadas en los requisitos de los
componentes. Por ejemplo, una compañía que ha desarrollado un software tiene los siguientes
módulos:
 Inicio de sesión
 Saldo pendiente
 Pagos y recargas
 Historial de llamadas

Pruebas de integración. Se hacen con base a la arquitectura del sistema o a las tareas
funcionales con el fin de facilitar la tarea de integración y disminuir los riesgos, las pruebas de
integración consisten en checar el flujo de información entre los módulos, por ejemplo,
analicemos la integración entre el saldo pendiente, pagos y recargas:
Un cliente se encuentra en el módulo saldo pendiente y ve que tiene una deuda de 500 pesos,
después se dirige a pagos y recargas para saldar la deuda, al regresar al módulo de saldo
pendiente, su cuenta debe estar en ceros.

Pruebas de sistemas. Sirve para revisar el funcionamiento de un software en su totalidad, su

principal objetivo es constatar que el software cumpla con los requisitos funcionales y no
funcionales para minimizar la posibilidad de errores.

Pruebas de aceptación. El cliente determina si el sistema tiene éxito de esta forma confirma si
es confiable su uso y su comportamiento.

Clasificación de pruebas

Pruebas funcionales. Pueden aplicarse en cualquier nivel del proceso y verificar que el software
opere con sus especificaciones, deben validar tanto las funciones principales como por ejemplo, el
acceso del usuario y también las de uso básico.

Pruebas no funcionales. También pueden aplicarse en cualquier nivel del proceso y contienen
diferentes pruebas, pero deben realizarse después de las funcionales, su objetivo es checar que el
software funciona bien, así como su fiabilidad y rendimiento.

Pruebas de caja blanca. Conocidas como prueba de estructura, están basadas en el

funcionamiento del código interno del software, durante estas verifica los siguientes puntos: fallas
en la seguridad interna, trayectorias mal estructuradas o rotas en los procesos de codificación, el
flujo de los valores de entrada a través del código y los resultados esperados, la funcionalidad de
los bucles condicionales. Todo esto con el objetivo de fortalecer la seguridad, mejorar el diseño y
usabilidad de los sistemas.
 Pruebas de caja negra. Verifican la seguridad del software, sin examinar la estructura del
código interno, los pasos para ejecutar estas pruebas son los siguientes: reconoce los
requerimientos y especificaciones del software que probarás, escoge valores de entrada que sean
válidos e inválidos para constatar cómo son procesados por el software, determina cuales son las
respuestas esperadas para cada uno de los valores elegidos, construye casos de prueba para los
valores de entrada y ejecútalos, compara las respuestas obtenidas con las esperadas y determina
si hay errores.

Repetición de pruebas y pruebas de regresión. Se ejecutan para confirmar que los cambios
hechos en el código no han afectado otras funciones, estas variantes pueden incluir: corrección de
fallas, cambios en el código o nuevas características del software.

Métricas y mediciones

Al conjunto de mediciones de un software, se le conoce como métrica, estás se hacen con la

finalidad de tener una idea clara sobre el estado actual del producto y si realmente existe alguna
mejora en la corrección de errores. Entre las métricas de software más comunes están:
 Métricas de tamaño. Se hacen para determinar la longitud del software, se hace
contando las líneas de código que los forman.
 Métricas de calidad. Utilizan el número de defectos encontrados en el producto.
 Métrica de seguridad. Se usa para determinar si el sistema podrá resistir ataques de
acceso no autorizado.

Para determinar métricas adecuadas, toma en cuenta los siguientes aspectos:

1. Debes definir un número limitado de métricas que sean útiles para evitar discusiones
futuras y problemas de interpretación.
2. Las métricas se definen por metas ya sea para un proceso, una tarea, un componente o
un sistema.
3. El seguimiento y recopilación de métricas debe estar automatizado para reducir los
tiempos de revisión.
4. El uso de métricas te permitirá comunicar a tu cliente y equipo de trabajo información
importante.

Lección 03

Tipos de herramientas

Herramientas de gestión. Se pueden emplear durante todo el ciclo de vida del software y en
cualquier actividad, dentro de estas herramientas destacan:

 Herramientas de gestión de pruebas. Ofrecen interfaces para ejecutar pruebas,

localizar defectos y verificar los requerimientos, además de la elaboración de reportes.
  Herramientas de gestión de requisitos. Almacena los requisitos y sus atributos para
proporcionar indicadores únicos lo que ayuda a identificar los requisitos faltantes.
 Herramientas de gestión de incidencias. Guardan y administran información sobre las
fallas y peticiones.
 Herramientas de gestión de configuraciones. Contienen y administran las versiones de
soporte del software, son útiles cuando se configura más de un entorno.

Herramientas de ejecución. Permiten detectar las fallas del software en una etapa temprana
durante el desarrollo de las pruebas, entre las más importantes se encuentran:

 Herramientas de revisión. Almacenan y comunican los informes de las fallas y los

comentarios acerca de las revisiones.
 Herramientas de análisis estático. Ayudan a localizar defectos sin la necesidad de
realizar pruebas dinámicas y analizan la estructura y su dependencia.
 Herramientas de modelado. Sirven para validar modelos de software, además localizan
y enumeran los defectos.

Herramientas de ejecución y registro. Ejecutan pruebas de forma automática utilizando scripts

que tienen valores de inicio y de respuesta esperada, además generan un registro por cada vez
que se aplica la prueba, dentro de estas herramientas destacan:

 Herramientas de marco de trabajo. Simulan el entorno de trabajo de un módulo que se

desea probar, esto se hace al crear códigos de imitación llamados stubs y otros
llamados controladores, el controlador sustituye a un módulo principal por lo que
siempre pedirá información, mientras que el stub siempre entregará información.
 Comparadores. Establecen las diferencias entre archivos, bases de datos o resultados
de prueba.
 Herramientas de medición de cobertura. Identifican qué porcentaje de los elementos
de un código han sido cubiertos.
 Herramientas de seguridad. Evalúan la capacidad del software para proteger la
integridad de la información.
 Herramientas de rendimiento y monitorización. Ayudan a localizar fallas y solo pueden
detectarse si se usa el software, entre estas herramientas destacan:
 Herramientas de carga. Simulan el número esperado de usuarios que utilizarán
la aplicación y que realizarán un número de operaciones durante un tiempo
determinado.
 Herramientas de estrés. Simulan carga hasta saturar el software, va duplicando
la cantidad de usuarios que se agregan a la aplicación hasta exceder el límite de
funcionamiento.
 Herramientas de estabilidad. Generan una carga continua esperada durante un
largo período de tiempo.
  Herramientas de monitorización. Analizan, comprueban y reportan el uso de recursos
del sistema.

Lección 04

Análisis de riesgo. Un elemento fundamental para el desarrollo correcto de cualquier proyecto

es el análisis de riesgo y consta de una serie de pasos:

 Identificación de los riesgos. Durante el desarrollo de un proyecto existen diversos

tipos de problemas que puedes encontrar:
 Riesgos del proyecto. Se definen como cualquier evento incierto que puede impactar al
proyecto tiene tres categorías principales:
 Riegos organizacionales. Son los que están relacionados con los recursos
humanos involucrados en el proyecto.
 Riesgos técnicos. Son los que causan más pérdidas por la mala ejecución de las
pruebas.
 Riesgos de negocios. Son un factor externo al proyecto, como pueden ser los
clientes o socios.
 Riegos del producto. Se refiere a la posibilidad de que el software o sistema, no cumpla
con las expectativas del cliente, generalmente está relacionado con problemas de
funcionalidad.

Análisis de impacto. Existe la posibilidad de que un riesgo ocurra por lo cual debes verificar el
impacto que pueda causar en el proyecto.
Probabilidad alta o nivel 3. Exista una alta posibilidad de que ocurra un problema.
Probabilidad media o nivel 2. Existe un 50% de probabilidad de que ocurra un problema.
Probabilidad baja o nivel 1. Es poco probable de que suceda un problema.

Prioridad
Alta o nivel 6 al 9. Se deben atender inmediatamente y monitorear los problemas relacionados
todos los días hasta que se resuelvan.
Media o nivel 3 al 5. Requiere que los problemas asociados sean monitoreados y tratados en
juntas internas.
Baja o nivel 1 y 2. Es necesario monitorear el problema ocasionalmente.

Para saber el nivel de prioridad, debes multiplicar los valores de la probabilidad y el impacto.

Toma de contramedidas. Se refiere a las estrategias que se aplican para la reducción de

problemas, lo que incluye registro, monitoreo y control de riesgo.

Estimación de pruebas.
 ¿Cómo hacer una estimación?
Para poder realizar la estimación de cualquier proyecto, sin importar su tamaño sigue estos
puntos:
 Divide todo el proyecto en tareas y subtareas de tal forma que cada una de esas piezas
sea lo más explícita.
 Asignación, cada una de las tareas es asignada a algún miembro del equipo.
 Estimación del esfuerzo por tarea. Existen varias técnicas para hacer la estimación, en
seguida se mostrará la más sencilla:
 Estimación de los tres puntos. Es una técnica que está basada en la experiencia o en las
mejores prácticas, el punto “A” es el escenario óptimo, en el cual tienes al equipo de
mejores probadores y todos los recursos disponibles, el punto “M” es el escenario más
probable, es un caso común donde tienes los recursos suficientes y un equipo de
probadores adecuado, el punto “B” es el peor escenario en donde tu equipo no tiene la
experiencia y además tienes escasos recursos.

Por último, ya que tengas la estimación, debes enviarla a los administradores del proyecto que
serán los encargados de dar la aprobación de la misma, es posible que durante el desarrollo del
proyecto, éste sufra alteraciones en el tiempo estimado, por eso es recomendable que agregues
un tiempo de reserva.

Plan de pruebas
Análisis. El primer paso, es el análisis del producto que probarás y para lograrlo, estudia la
documentación del software.
Estrategia de prueba. Se desarrolla lo cual es crítico dentro de la planeación, esta etapa consta
de cuatro puntos:
Determinación del alcance de prueba. A los elementos del sistema que se les va a realizar la
prueba se les conoce como bajo cobertura, debes considerar lo siguiente para determinar el
alcance de la prueba:
Los requerimientos del cliente
Las especificaciones del producto
El presupuesto asignado
Las habilidades y número de integrantes de tu equipo de trabajo

Los elementos que no están bajo prueba, pero están claramente definidos se les llama fuera de
cobertura.

Identificación de tipos de prueba. Existen diferentes tipos de prueba, cada una diseñada para
detectar un error, así que no es posible tener los recursos suficientes para efectuar todas, por ello,
debes enfocarte en las metas del proyecto.
 Análisis de riesgo. Se le conoce como riesgo a un evento futuro incierto que tiene cierta
posibilidad de que ocurra y en consecuencia genere pérdidas, una vez que este evento ocurre se le
conoce como falla.

Creación de logística de la prueba. En este punto se debe definir quíén ejecutará la prueba y
cuando lo hará, para eso debes considerar:
Las habilidades de cada tester y los requerimientos del cliente
El tester debe tener una buena cooperación y atención al detalle
Deben existir las especificaciones de la prueba y los documentos requeridos
Capital humano

Definición de objetivos de prueba. El objetivo de toda prueba es encontrar la mayor cantidad

de errores y asegurar que el software esté libre de fallas, cuando lo adquiera el usuario final.

Para definir estos objetivos atiende lo siguiente:

Determinar todas las aplicaciones del software que necesitan probarse
Planificar las pruebas de acuerdo con la importancia de las funciones del software

Criterios de prueba. Es un estándar que se establece durante el proceso de pruebas con el que
se ahorra tiempo, existen dos tipos:
 Criterio de suspensión. Determina el punto crítico del ciclo de pruebas, si se suspende,
se reanudará hasta que el criterio sea solucionado, por ejemplo, al iniciar el ciclo de
pruebas, se determina que si el 35% del total de los casos de prueba fallan el ciclo se
suspende hasta que los desarrolladores reparen los problemas encontrados.
 Criterio de salida. Determina la finalización exitosa de una fase de pruebas, se
considera el objetivo esperado y es necesario para pasar a la otra fase. Para determinar
el criterio de salida, se deben tomar en cuenta los siguientes aspectos:
 Tasa de ejecución. Es el porcentaje de número de pruebas esperado entre el
número de casos de prueba totales, es obligatorio que se alcance el 100%.
 Tasa de éxito. Es el porcentaje del número de casos de prueba exitosos entre el
número de casos de prueba ejecutados, depende del alcance del proyecto pero
siempre debemos conseguir un alto porcentaje.

Planeación de recursos. En esta etapa se debe hacer un resumen detallado de todos los
recursos disponibles para la realización del proyecto ya sean humanos, económicos o de equipo.

Planeación del ambiente de pruebas. Es aquél que trata de recrear el escenario real al que se
enfrentará la aplicación dentro del software o hardware.

Calendarización. Es la técnica utilizada para monitorear el avance del proyecto, toma en cuenta
los siguientes aspectos: La cantidad de gente disponible para las pruebas, los días laborales y la
fecha de entrega, los riesgos del proyecto.
 Entregables. Se refieren a todos los documentos, herramientas o componentes que se aplican
en el proceso de pruebas como los siguientes: Documentación del plan de prueba y de los casos de
prueba, simuladores, reportes de defectos y resultados.

Nivel 02

Lección 01

Creación de casos de prueba.

Casos de prueba es el conjunto de acciones que sirve para verificar una característica o función
específica de un software. Por ejemplo, el usuario ingresa nombres y contraseñas válidas, nombre
y contraseña inválidos, nombre y contraseña vacío entre otros, para verificar la respuesta en un
caso de prueba, necesitas tener valores de entrada conocidos como datos de prueba, la
documentación de este componente es importante para ahorrar tiempo y evitar complicaciones.

Las Pre-Condiciones y Post-Condiciones son elementos opcionales en casos de prueba, un

ejemplo de pre-condición es que el software a probar esté en la versión más actualizada y uno de
post-condición puede ser que una vez que el sistema de acceso a la banca móvil se inicie un
conteo del tiempo conectado.

Cuando escribas los casos de prueba, debes tener en mente los siguientes aspectos:
 Utiliza el lenguaje más simple para que cualquier persona pueda usarlo.
 Si distintas pruebas usan el mismo caso de prueba, úsalo como pre-condición.
 Sigue siempre las especificaciones documentadas, nunca asumas alguna característica
o funcionalidad.

Diseño de pruebas
Estas técnicas se utilizan para diseñar los casos de prueba:

Tabla de decisión. Es útil cuando se prueba un software que admite más de un valor de
entrada y genera una respuesta a cada combinación, entre más combinaciones existan, la tabla de
decisión toma mayor importancia, para entender mejor este tema veamos el siguiente ejemplo,
en el cual analizaremos el comportamiento del botón reservar en la aplicación de un hotel:
Combinación 1. Los campos, fecha y de llegada y de partida están en blanco, en seguida se
coloca el valor falso en la tabla de decisión, esta combinación da como resultado falso, lo que
significa que el botón reservar está deshabilitado.
Combinación 2. El campo fecha de llegada tiene un valor, pero fecha de partida no, entonces
coloca los valores verdadero y falso en la tabla lo que da como resultado falso.
Combinación 3. El campo fecha de llegada está vació pero fecha de partida no, entonces coloca
los valores falso y verdadero en la tabla, lo que da como resultado falso.
 Combinación 4. Los campos de fecha de llegada y de partida tienen un valor, por lo cual coloca
el valor de verdadero en la tabla, esta combinación da como resultado verdadero, es decir el
botón de reservar está habilitado.

Valor de entrada
Llegada Partida Respuesta Acción/Botón
Combinación 1 Falso Falso Falso Deshabilitado
Combinación 2 Verdadero Falso Falso Deshabilitado
Combinación 3 Falso Verdadero Falso Deshabilitado
Combinación 4 Verdadero Verdadero Verdadero Habilitado

Diagrama de Transición de estados

Esta técnica es útil cuando tienes que probar las diferentes transacciones presentes en un
sistema, está compuesta por cuatro elementos que son los siguientes:
 Los estados que el software puede ocupar
 Transición de un estado a otro
 Eventos
 Acciones

Analizaremos el comportamiento de un sistema de acceso para banca en línea, sin en el primer

intento se escribe el nombre de usuario y contraseña correcta el sistema dará acceso a la
aplicación, en caso contrario, la pantalla de inicio solicitará de nuevo la información, con la
oportunidad de cuatro intentos más, si no se bloqueará el acceso, las transacciones que te servirán
para hacer la prueba son:
 El acceso del usuario al primer intento
 El bloqueo de la cuenta después del cuarto intento fallido
 El acceso correcto después de haber fallado la primera vez.

Valores límite
Las técnicas facilitan el proceso de prueba y cubren las más importantes:

Equivalencia de particiones. Es una técnica de caja negra y puede aplicarse en cualquier nivel
de prueba y consiste en dividir los casos en conjuntos que puedan considerarse lo mismo, por
ejemplo:
Un hotel saca una aplicación para que sus clientes puedan reservar su estancia con un tiempo
no mayor a 60 días, de no cumplir con lo anterior, la aplicación desplegará un letrero que indica
fecha no válida, las condiciones de prueba que nos permitirán obtener las particiones son las
siguientes:
 Cualquier fecha anterior a la que se realiza la reservación es inválida
 Cualquier fecha mayor a 60 días de la fecha en la que se realiza la reservación es
inválida
  Cualquier fecha a partir del día de la reservación y menor a 60 días es válida

Debes elegir un valor de cada partición y ejecutar la prueba en cada uno, la hipótesis de esta
teoría es que si un valor dentro de la partición del grupo pasa la prueba todos los harán, pero si no
lo pasa ninguno lo hará.

Análisis de valores límite. En esta técnica, los valores que se prueban son los límites entre las
particiones, siguiendo con el ejemplo anterior se hará la prueba tomando de referencia la fecha 17
de marzo del 2015, los valores límite son el 16 de marzo que es el primer valor inválido por ser
anterior a la fecha en que se intenta hacer la reservación y 17 de marzo que es el primer valor
válido, el día 16 de mayo del 2015 es el último día válido y el 17 de mayo es el primer valor
inválido fuera del rango permitido.

El análisis de valores límite y la equivalencia de particiones están estrechamente relacionadas

y pueden usarse simultáneamente.

Lección 02

Pruebas de calidad. Existen tipos de prueba que están enfocados a garantizar la calidad del
software por lo cual es importante conocerlos para desempeñar bien tu trabajo.

 Pruebas de exactitud y de adecuación. Comprueban que el software cumple con los

requerimientos específicos mientras que las pruebas de adecuación verifican y evalúan
la capacidad de un conjunto de funciones para la realización de tareas específicas.

 Pruebas de interoperabilidad. En estas pruebas se examina que una aplicación funcione

correctamente en todos los entornos, es decir, la forma en la que estos se relacionan
entre sí.

 Pruebas de usabilidad. Están enfocadas en medir el grado de adecuación del software

la flexibilidad en el control y el logro de objetivos, estas pruebas deben realizarse
durante la fase del diseño del software y su objetivo es analizar los siguientes factores:
 Eficacia, capacidad del software para permitir a los usuarios finales cumplir con
los objetivos específicos incluye facilidad y exactitud.
 Eficiencia, el sistema permite la navegación de los usuarios entre pantallas y
que haya uniformidad en la aplicación.
 Precisión, no deben existir datos obsoletos o incorrectos así como no pueden
haber enlaces rotos.
 Satisfacción, el usuario está conforme con el uso del software.
  Pruebas de accesibilidad. Se ejecutan para asegurar que el software bajo prueba puede
ser utilizado por personas con algunas necesidades particulares o discapacitados:
 Software de reconocimiento de voz
 Software de lectura de pantalla
 Software de ampliación de pantalla
 Teclado especial

Pruebas técnicas. Hay tipos de pruebas que tienen como meta verificar la función del producto
para asegurar su calidad:

Pruebas de seguridad. Su meta es encontrar todas las debilidades del sistema que comúnmente
son errores de diseño, configuración o bugs de software, se encargan de validar la calidad que
tiene el software para impedir los ataques de seguridad más comunes: accesos no autorizados,
copias no autorizadas de aplicaciones o de información, denegar el servicio, ruptura de códigos de
encriptación.

Pruebas de fiabilidad. Su objetivo es determinar una medida estadística para comparar la

confiabilidad real con la esperada, como por ejemplo, el tiempo de recuperación en los errores y el
periodo entre fallas.

Pruebas de robustez. Evalúan la tolerancia del software ante fallos que ocurren de manera
externa y se comunican a través del sistema operativo.

Pruebas de recuperabilidad. Valoran la capacidad del sistema para restablecerse de una falla ya
sea de hardware, de software e incluye los siguientes aspectos:
 Failover. La prueba consiste en simular o provocar fallos controlados para después
analizar los sistemas failover y comprobar que no hubo afectación en el servicio ni
pérdida de datos.
 Backup y restablecimiento. Su objetivo es establecer medidas para minimizar las
consecuencias tras una falla.

Pruebas de mantenibilidad. Evalúan la facilidad con la que un software puede ser analizado,
modificado o probado, entre este tipo de pruebas se encuentran:
 Pruebas dinámicas de mantenimiento. Se enfocan en los procedimientos para verificar
que se alcance los niveles de servicio requeridos.
 Pruebas de mantenimiento correctivo. Miden el tiempo en el que una falla en el
sistema es corregida.
 Pruebas de mantenimiento adaptativo. Valoran tres condiciones, el esfuerzo requerido
para modificar el sistema y probar los cambios, además de la respuesta del sistema a
esas variaciones.
 Pruebas de eficiencia. Es cuando revisas que el software responde bajo circunstancias
específicas, entre estas pruebas tenemos las siguientes:
 Pruebas de carga. Miden la capacidad del sistema de soportar niveles crecientes de
carga los cuales simulan condiciones normales de operación, con estas pruebas se
logran determinar las siguientes características:
 Máxima capacidad de operación del sistema
 Determina si la infraestructura actual es suficiente para soportar la aplicación.
 Sustentabilidad de la aplicación con respecto a los picos de uso.

 Pruebas de estrés. El objetivo de ejecutar estas pruebas es para conocer su estabilidad,

confiabilidad y determinar los límites en los que falla.

 Pruebas de escalabilidad. Miden la capacidad de un sistema para satisfacer las

necesidades futuras, como por ejemplo más información almacenada o un incremento
en las operaciones realizadas.

 Pruebas de utilización de recursos. Evalúan la forma en que los sistemas utilizan los
recursos disponibles, entre los que se encuentran: ancho de banda, espacio de
memoria y capacidad del disco.

Pruebas de portabilidad. Su finalidad es medir que tan fácil puede ser transferido un sistema,
entre estas pruebas se encuentran:
 Pruebas de instabilidad. Son para verificar que el software puede ser instalado
siguiendo los pasos de un manual o un asistente de instalación.
 Pruebas de compatibilidad. Su función es checar si un software es capaz de funcionar
correctamente en diferentes sistemas operativos, entornos de red o hardware.

Prueba exploratoria. Está basada en la experiencia del tester y su objetivo es la investigación y

aprendizaje, entre sus principales características se encuentran:
 Creación simultánea de los casos de pruebas y su ejecución
 Se enfoca en la investigación del sistema o aplicación
 Se realiza con el objetivo de mejorar el diseño de pruebas
 El tester tiene el control de las pruebas ya que no sigue ningún guión predeterminado.

La prueba exploratoria consta de cinco elementos que se describen a continuación:

 Clasificación de defectos. Cataloga los errores más comunes del pasado y analiza la
causa que originó esos defectos.
 Carta de prueba. Es un documento que debe contener qué y cómo podría probarse.
 Cuadro de tiempo. Dos testers deben trabajar 90 minutos mínimo sin interrupción con
el fin de ver la reacción del sistema y preparar la respuesta correcta.
 Revisión de resultados. Se evalúan los defectos encontrados en las áreas cubiertas por
la prueba.
  Cierre. Se juntan los resultados de la prueba para verificar si se necesita una prueba
adicional.

Pruebas de teléfonos móviles. Las pruebas que se aplican a los teléfonos móviles al igual que
las aplicaciones web Se concentran en seis puntos primordiales, cada uno con su propia lista de
verificación:

 Prueba de funcionalidad. Verificar que todos los campos obligatorios trabajen como es
requerido, además deben verse en la pantalla de forma distinta a los secundarios,
validar que la aplicación soporte transacciones de pago y publicaciones a través de
redes sociales, confirmar que el usuario recibe mensajes de error, revisar que se
puedan instalar aplicaciones nuevas, si se cuenta con los recursos necesarios, sin
afectar el rendimiento de las instaladas.

 Prueba de compatibilidad. Verificar que la aplicación se desempeña bajo los

requerimientos establecidos y que su tiempo de respuesta es el correcto, revisar que
las redes 2G, 3G y 4G sean capaces de soportar diferentes niveles de carga de los
usuarios, además de que la aplicación funciona correctamente cuando el usuario
cambia a WiFi, verificar el desempeño de la red mientras el dispositivo está en
movimiento.

 Pruebas de seguridad. Validar que la aplicación, no permita el acceso a la información a

las personas no autorizadas, verificar si la aplicación y la red están protegidas de
ataques para denegar el servicio.

 Pruebas de usabilidad. Revisar que los botones de la aplicación tienen el tamaño y la

localización adecuada para evitar problemas a los usuarios finales, verificar que los
menús de la aplicación no estén sobrecargados para poder agilizar la navegación,
validar que la aplicación proporciona a los usuarios una forma de corregir las acciones
en caso de algún error, verificar que el texto es simple y claro, además debe tener el
tamaño adecuado.

 Pruebas de compatibilidad. Validar que la interface de la aplicación, va de acuerdo con

la pantalla del equipo, sin importar el tamaño, revisar que si se activa la alarma o entra
una llamada mientras se está utilizando la aplicación esta se minimice, en el momento
en que la llamada termina, la aplicación debe regresar.

 Pruebas de recuperabilidad. Verificar que la función de recuperabilidad es efectiva,

validar el manejo de la aplicación durante una falla de energía, verificar los procesos
después que una conexión fue suspendida, comprueba que se reestablezca la conexión
con el sistema y se recupere la información.
 Pruebas de aplicaciones web. Son seis puntos fundamentales:

 Pruebas de funcionalidad,
 Pruebas de link, debes verificar que todos los links dentro de la página se
encuentren funcionando.
 Pruebas de formato, es la forma en la que el sitio web consigue la información
de los usuarios para mantener la interacción por lo tanto deben ser probadas y
ver la respuesta del sistema ante los valores incorrectos o nulos.
 Pruebas de cookies, son pequeños archivos almacenados en las computadoras
de los usuarios, su función es mantener la sesión principal activa.
 Pruebas de bases de datos, es aquella donde tienes que verificar la integridad
de los datos y buscar posibles errores mientras se modifica, borra o actualiza la
información.
 Pruebas de usabilidad, pruebas de navegación la página debe presentarse de forma
clara para poder navegar además de ser congruente en su contenido, pruebas de
contenido, son aquellas donde debemos verificar que el contenido sea lógico
entendible y se busca errores ortográficos.
 Pruebas de interfaces, el objetivo de estas pruebas es verificar que las interfaces
interactúen entre sí, es decir, que envíen mensajes apropiados a los usuarios.
 Pruebas de compatibilidad, pruebas de navegador, es una de las partes más
importantes en las pruebas de aplicaciones web, donde tu aplicación deberá ser
compatible con varios navegadores, pruebas de sistema operativo, valida que todas las
funciones operen dentro de la aplicación.
 Pruebas de rendimiento, pruebas de carga, la página web debe ser capaz de manejar
un número creciente de usuarios sin afectar las funciones principales como son
múltiples conexiones a la base de datos o manejar grandes cantidades de información;
pruebas de estrés, se aumenta el número de usuarios hasta que la página web falla, si
existe recuperación o no, la prueba se ejecuta en distintos sistemas operativos y
diferentes condiciones de hardware.
 Pruebas de seguridad, verifica cómo reacciona la página web ante valores inválidos del
usuario y contraseña, revisa el funcionamiento de la prueba captcha para prevenir
inicios de sesión automáticos, comprueba si el protocolo SSL se usa como medida de
seguridad, si es así deben aparecer mensajes al abandonar un sitio fiable.

Proceso de mejora de pruebas. Los siguientes modelos utilizan un marco de referencia para
juzgar la capacidad de un proceso:

 Nivel 1 Inicial. Representa un estado donde no hay un proceso de pruebas,

formalmente documentado y estructurado.
 Nivel 2 Definición. Se establecen objetivos, políticas y técnicas de pruebas.
  Nivel 3 Integración. Es cuando el proceso de pruebas, se integra en el desarrollo del
ciclo de vida del producto y se documenta con normas procedimientos y métodos
formales.
 Nivel 4 Gestión y medición. Es cuando el proceso de pruebas puede ser medido,
gestionado y adaptado a proyectos específicos de forma eficaz.
 Nivel 5 Optimización. Representa el estado en el que la información obtenida puede
ser utilizada para evitar defectos en el proceso de prueba.

Modelos TPI (Test Process Improvement). El proceso de pruebas se revisa a partir de varios
puntos y estos son los principales: Ciclo de vida, Organización, Infraestructura y Herramientas.

Dentro de estos cuatro existen 20 elementos que se conocen como áreas clave y cubren todo el
proceso de prueba, las cuales se clasifican en diferentes niveles; para asegurarse que cada área es
asignada en el nivel adecuado, se deben de establecer una serie de requerimientos llamados
puntos de control, si el área clave cumple con todos los puntos de control de un nivel, se asigna a
ese nivel; cada aumento de nivel representa una mejora.

Modelo CTP (Critical Testing Process). La premisa de este modelo, es que hay determinados
procesos de prueba críticos, contribuirán al éxitos de los equipos de prueba, para emplear este
modelo se evalúan los procesos de prueba existentes que varían en función del contexto
específico, esta valoración identifica cuales de estos procesos son más fuertes y cuales más
débiles, este proceso identifica los siguientes puntos críticos:
 El proceso de prueba
 Establecimiento del contexto
 Análisis de riesgo para la calidad
 Prueba de estimación y de planeación
 Prueba del equipo y sistema de desarrollo
 Administración de la versión de prueba
 Prueba de ejecución
 Reporte de bugs y de resultados
 Cambio de administración

Existen 5 pasos a seguir para mejorar el proceso una vez identificadas las áreas de mejora:
 Dar prioridad a la solución de problemas
 Planear el proceso de mejora
 Implementar el cambio y medir la mejora en el tiempo
 Consolidar el cambio para convertirlo en el modo en el que se hacen las cosas
 Volver a empezar

Modelo STEP (Systematic Test and Evaluation Process). En este método no se necesita que las
mejoras se produzcan en un orden específico, consideran a las pruebas como una actividad dentro
del ciclo de vida de un software que empiezan durante la definición de requerimientos, entre sus
premisas están:
 Las pruebas se realizan al principio del ciclo de vida
 Las pruebas se emplean como requisitos y modelos de uso
 El diseño del soporte de prueba, condice al diseño del producto
 Los probadores y desarrolladores trabajan conjuntamente

Las métricas utilizadas son: Estado de pruebas en el tiempo, requisitos de prueba y de

cobertura de tiempo, tendencia y densidad de los defectos, porcentaje de defectos detectados y
efectividad al eliminarlos, costes de las pruebas en términos de tiempo, utilización del proceso de
pruebas definido, satisfacción del cliente.

Nivel 03

Lección 01

Administración de defectos

Como Tester obtendrás resultados diferentes a los esperados por lo que es necesario que
conozcas el proceso de administración de defectos.

Proceso de administración de defectos

 Descubrimiento. El Tester debe comunicar a los desarrolladores los defectos que haya
encontrado, estos verifican que realmente existan errores, así podrán avanzar a la
siguiente etapa.
 Categorización. Es una actividad donde el Tester clasifica los defectos encontrados. Las
cuatro categorías en los que se pueden colocar son:
 Crítica, el defecto debe ser corregido de inmediato, porque puede causar un
daño muy serio al producto.
 Alta, la falla afecta a las características principales del software.
 Media, los requerimientos del producto, sufren pequeñas alteraciones.
 Baja, la falla no afecta la operación del sistema.
 Resolución de defectos. Esta fase consta de cuatro pasos que son los siguientes:
1. Asignación, los desarrolladores se encargan de reparar los defectos.
2. Programación de la reparación, el equipo de desarrolladores crean un
programa para reparar los defectos encontrados,
3. Reparación de defectos, mientras los desarrolladores reparan los errores, el
equipo de tester debe verificar que las fechas establecidas se cumplan.
4. Reporte de solución, los desarrolladores entregan un documento con la
solución de todos los defectos.
  Verificación. El equipo de pruebas verifica que los defectos hayan sido corregidos
correctamente y además que no hayan surgido nuevos errores.
 Clausura. Ya que los defectos hayan sido reparados y verificados, su estado queda
como concluido, de lo contrario los desarrolladores intervienen de nuevo.
 Reporte. Los miembros involucrados en las pruebas deben estar enterados del estado
de los defectos, por lo cual entrégales un reporte que contenga la situación actual de
las fallas.

Nivel 04

Lección 01

Profesionalización

Motivación. Para motivar a tu equipo existen diferentes formas para hacerlo las más comunes
son:
 Reconocer el trabajo realizado por tu equipo
 Escuchar las propuestas de tu equipo y aprobar las adecuadas
 Siempre propicia un ambiente de respeto entre los compañeros de tu equipo.
 En casos excepcionales, puedes dar recompensas por el trabajo realizado.
 Asegúrate de que los testers emplean métricas adecuadas para demostrar que están
haciendo un buen trabajo.

Comunicación. La comunicación entre tu equipo de trabajo debe estar encaminada a cumplir

con los objetivos establecidos por lo cual debe de ser profesional. La comunicación se presenta en
tres niveles, los cuales son:
 Documentación de productos de prueba, se comunican las estrategias, los planes de
prueba y el informe de defectos.
 Valoración de documentos, se revisan todas las especificaciones funcionales y
requisitos.
 Análisis y publicación de la información, los miembros involucrados en el proceso de
prueba, hablan sobre los resultados obtenidos.

Actualización y certificación. Las tecnologías de la información, evolucionan a una gran

velocidad por lo cual es muy importante que tomes cursos de actualización para mantenerte
vigente y que respaldes tus conocimientos con certificaciones internacionales, la International
Software Testing Qualifications Board (ISTQB), es una organización certificadora a nivel
internacional que ofrece los distintos niveles con sus especialidades:
 Nivel de fundamentos, sin especialidades
 Nivel avanzado y sus especialidades: gerente de pruebas, analista de pruebas y analista
de pruebas técnicas.
 Nivel experto y sus especialidades: mejoramiento de procesos de prueba,
administración de pruebas, automatización de pruebas y pruebas de seguridad.