1. ¿Qué son los casos de prueba?

Miden la funcionalidad de un conjunto de condiciones para verificar el resultado esperado

o son el conjunto de pasos y resultados esperados que se crean a partir de los requisitos
de software que se van a probar

Describa como están compuestos

-Pasos

-Resultado esperado

-Resultado obtenido

1-ID de casos de prueba: Debe de llevarlo como ID únicos para representarlos

2- Descripción de la prueba: Detalla, describe que función o característica se está
probando o que es lo que se está verificando
3-Supuestos y condiciones previas: Esto implica que se cumplan las condiciones antes de la
ejecución del caso de prueba. Ej requerir una cuenta de Outlook válida para iniciar sesión.
4-Datos de prueba: Son variables y sus valores Ej cuando se inicia sesión por correo
electrónico, sería el nombre de usuario y la contraseña de la cuenta
5-Pasos a Ejecutar: estos son los pasos fácilmente repetibles ejecutados desde la
perspectiva del usuario final Ej
-Abra la página web del servidor de correo electrónico
-Introduzca su nombre de usuario
-Introduzca la contraseña
-Haga clic en el botón “Entrar” o “Iniciar sesión”
6-Resultado esperado: Este resultado es el que va después de la ejecución del paso del
caso de prueba: Ej inicio de sesión exitoso
7-Resultado real y condiciones posteriores: Este es el estado de caso de prueba. Ej la
condición posterior es lo que sucede como resultado de la ejecución del caso, como ser
dirigido a la bandeja de entrada del correo electrónico
8-Contraseña errónea: La determinación del estado de aprobado/reprobado depende de
cómo se comparan entre sí el resultado esperado y el resultado real

Diferencia de prueba frente a caso de prueba

Un script de prueba es un programa corto destinado a probar ciertas funciones y un caso
de prueba es un documento que deben completarse según lo planeado con anticipación
 2. ¿Cuál es la diferencia entre verificar y validar?

Verificación y validación: Conjunto de procesos de comprobación y análisis que aseguran que el

software que se desarrolló está acorde a su especificación y cumple las necesidades de los
clientes.

En la verificación nos preguntamos:

¿Estamos construyendo el producto correctamente?

Es decir, se comprueba que el software cumple los requisitos funcionales y no funcionales de su

especificación.

En la validación nos preguntamos:

¿Estamos construyendo el producto correcto?

Es decir, se comprueba que el software cumple las expectativas que el cliente espera

Verificación: Acción de comprobar que lo que decimos que estamos haciendo lo estamos
haciendo bien
Validación: Es lo que confirma lo que estamos haciendo

3. ¿Diferencia entre pruebas estáticas y pruebas dinámicas?

Estáticas: Se utilizan para comprobar si hay defectos en el rendimiento sin ejecutar código,
se usan para evitar errores en etapas tempranas del desarrollo porque es más fácil
resolver e identificar los errores
No requieren de la ejecución del software
Revisan el producto de trabajo como documento de requerimientos, casos de prueba,
planes de prueba, código y guías de usuario
Técnicas usadas:
- Revisión técnica
- Inspección
- Revisión de código

Dinámicas: Mientras el código está en ejecución su objetivo es asegurar que el software se

comporte de acuerdo con los requerimientos del negocio mediante el uso y aplicación de
pruebas funcionales y pruebas no funcionales

4. ¿Cuáles son las pruebas de caja blanca y vs pruebas de caja negra?

Caja Blanca: Examina la estructura interna el diseño y la codificación, así como el

funcionamiento interno del software. Verifican el flujo de entradas y salidas a través de la
aplicación, mejoran la usabilidad, el diseño y refuerzan la seguridad.
Caja Negra: Se prueba la funcionalidad de la aplicación ignorando la parte interna, se
basan en los requerimientos de la aplicación y sus especificaciones técnicas solo se centra
en las entradas y salidas, se centra en que, si se realiza una acción, la salida sea la indicada
según los requerimientos
 5. ¿Qué son las pruebas de humo?

Son una prueba rápida realizada para confirmar que el sistema que se está probando está
operativo, incluso si solo funciona en un nivel básico. También o pueden hacer una conexión
rápida de dispositivos electrónicos para confirmar que funcionan como <<Pruebas de humo>> En
este caso, el equipo se enchufa y se enciende para comprobar si hay problemas obvios

6. ¿Qué son pruebas de verificación?

Prueba la habilidad del programa para manejar datos que se encuentren en los límites
aceptables, como por ejemplo el número de dígitos para un número de decula. Este tipo
de pruebas se han realizado sobre tiempo de desarrollo usando herramientas del
navegador y depurando las fallas en tiempo de ejecución
7. ¿Cuál es la diferencia entre severidad y prioridad?
Severidad: Medida en que un defecto puede crear un impacto del defecto en la
funcionalidad del software
Prioridad: Parámetro que decide el orden en que debe corregir un defecto

8. ¿qué es la trazabilidad bidimensional?

Trazabilidad: capacidad de rastrear todos los aspectos del producción y distribución de un

producto. Es una herramienta de identificación y registro de información que hace posible
la mejora de los procesos de control de un producto. Se aplica para mejorar estos
procesos y aumentar la eficiencia de la compañía, así como reducir los costes ante fallos,
mejorar el servicio al cliente, etc.

9. ¿qué es un análisis de impacto?

También conocido como análisis de cambio, este trata de identificar las posibles consecuencias de
un cambio o estimar qué es necesario modificar para lograr un cambio

10. Platícame el día a día de tus actividades laborales:

Básicamente llevo a cabo la ejecución de pruebas de sistema el cual se evalúa el
comportamiento y capacidades de todo el proyecto aplicando pruebas funcionales,
pruebas de usabilidad, pruebas de rendimiento y pruebas de integración, de estas últimas
son las que más esto realizando en este momento ya que se prueba las interacciones entre
los componentes o sistemas como por ejemplo cuando se integra el frontend y backend y
se muestra en la interfaz de usuario los datos traídos por una API la cual trae datos de la
BD y se verifica que estos datos se muestran correctamente en la interfaz
11.- Definición de:

Error: Una acción humana que conduce a un resultado incorrecto

Este es el que comete el analista o el desarrollador al momento de que el programador invoca de

manera incorrecta un método o una expresión

Es una equivocación que por lo general es cometida por una persona, ya sea en el código del
software o en algún otro producto de trabajo

Equivocaci
Error
ón

Defecto: Es un procesamiento incorrecto de un programa o software

Este ocurre en el software ya que el sistema no se comporta como debería

Es lo mismo que un problema o falta y también es conocido como un bug por los desarrolladores.
Por tanto, un defecto puede definirse como una imperfección en un componente o sistema que
puede causar que este no desempeñe las funciones requeridas

Es un proceso incorrecto de un componente o sistema que causa que no se desempeñe las

funciones requeridas

Fallo: Es el resultado incorrecto del error

Son los defectos negativos del software dependiendo de este

es la discrepancia visible que se produce al ejecutar un programa con un defecto, el cual es

incapaz de funcionar correctamente, es decir, una falla es un síntoma de un defecto
Nombre de la prueba Definición
Pruebas Manuales Estas son ejecutadas directamente
por el Tester simulando las
acciones del usuario final
Pruebas de Estas se usan cuándo se tienen
Automatización diversos Test Case de manera
repetitiva y por un periodo de
tiempo extenso son idóneas para
ampliaciones de funciones
Pruebas de Usabilidad Se usan para pruebas de sitios
web.
Pruebas de Integración Aquí se examinan las interfaces
entre grupos de componente o
subsistemas. Es un tipo de prueba
funcional y se realiza de forma
automatizada. Se realizan para
probar componentes individuales
con el objetivo de verificar cómo
los módulos, que trabajan de
manera individual, funcionan
cuando estén integrados
Prueba de Integración Es la comprobación de las
Prueba de Interfaz transferencias de datos entre dos
componentes. Prueba de
interfaces como servicios web,
API, entre otros
Pruebas Funcionales Se prueba la funcionalidad del
sistema teniendo los
requerimientos del sistema, está
validan y verifican que el producto
cumpla con lo especificado y hace
lo que tiene que hacer
Objetivo
Es detectar el mayor número
de defectos, sirven para
mejorar la experiencia del
usuario
Para generalizar lo que no se
a modificado siga
funcionando
Validan que llegará y si se
actualizará la información en
el portal
Para asegurar que son
llamadas cuando es necesario
y que los datos o mensajes
que se transmitan son los
requeridos. Usualmente nos
ayudan a identificar
problemas en las operaciones
de la interfaz de usuario,
formatos de datos, invocar
API, accesos a bases de datos,
entre otras
Es verificar que los
componentes estén
sincronizados entre sí. Ayuda
a determinar que diferentes
funciones, como la
transferencia de datos entre
los diferentes elementos del
sistema, se realizan de
acuerdo con la forma en que
fueron diseñadas
Pruebas de Componentes Se ejecutan de forma Es verificar su funcionalidad
independiente para comprobar y/o usabilidad de los
que el resultado sea el requerido. componentes
Estas pruebas pueden ser
cualquier elemento que tenga
entrada y debe generar alguna
salida
Pruebas de Componentes 1.-Para usabilidad y accesibilidad
1.-Prueba de UI 2.- Para asegurar el rendimiento
2.- Prueba de carga 3.- a través de componentes de UI
3.- Inyección de SQL para asegurar la seguridad
4.- Pruebas de login 4.- Con credenciales válidas e
inválidas
Pruebas Unitarias Son las que aseguran que cada Son útiles porque identifican
parte del código brinde los la mayoría de los errores en
resultados adecuados. Se observa una fase temprana del ciclo
la interfaz y la especificación de un de desarrollo, lo que hace que
componente. Si usas pruebas sean más baratos y fáciles de
funcionales son pruebas unitarias solucionar
puede haber resultados fallidos
Verifican si las funcionalidades
más significativas de la aplicación
funcionan o no, Estas son las
primeras que se deben realizar
Pruebas de Humo

Pruebas de Regresión Se realizan para asegurar que los
cambios o adiciones no hayan
alterado ni eliminado las
funcionalidades existentes
Es encontrar errores que
pueden haber sido
introducidos accidentalmente
en la compilación existente y
así garantizar que los errores
eliminados continúen así

Pruebas de Cordura Después de las pruebas de

regresión se realizan estas
pruebas. Con estas se determina
que las modificaciones realmente
hayan sido solucionadas y que
dichas correcciones no hayan
generado un problema
Diferencia entre las Las pruebas de Humo se inician en
pruebas de cordura y las la compilación desde el inicio y se
de humo inspeccionan las funcionalidades
importantes. Mientras que en las
de Cordura analizan
profundamente las compilaciones
 de software, es decir, las primeras
confirman la estabilidad del
producto, mientras que las
segundas aseguran la racionalidad
del producto
Pruebas de Aceptación Estas forman parte de la última Asegurar la calidad más
del usuario fase del proceso de testing, aquí importante que puedes
los usuarios reales del software lo implementar para entregar
usan para verificar que cumpla con desarrollos productos y/o
las tareas requeridas en un aplicaciones de otro nival
ambiente real
Pruebas de Rendimiento Verifican el comportamiento del
sistema frente a un crecimiento de
carga de consultas, accesos, etc,
frente a diferentes
comportamientos de nivel de uso
y ocupación
Pruebas de Caja Blanca:

Técnicas de prueba de caja blanca

Hay muchas maneras de analizar el software con pruebas de caja blanca. La mayoría de los
probadores utilizarán un proceso llamado análisis de cobertura de código para eliminar las lagunas
en las pruebas del código. Hay una variedad de técnicas que puede utilizar para lograr esto,
incluyendo:

 Cobertura de la declaración: Esta técnica garantiza que cada línea del código se

pruebe al menos una vez para encontrar más fácilmente el código defectuoso.
 Cobertura de la sucursal: Mediante esta técnica, se comprueba la exactitud de
cada posible camino o punto de decisión de una aplicación informática.
 Cobertura de condiciones: Se comprueban todas las condiciones individuales.
 Cobertura de múltiples condiciones: Todas las combinaciones imaginables de
todos los resultados de condiciones imaginables se prueban al menos una vez.
 Pruebas de ruta de base: Los gráficos de control se crean a partir de diagramas de
flujo o de código. A continuación se calcula la complejidad ciclomática para definir
el número de rutas independientes, de modo que se pueda diseñar el número
mínimo de casos de prueba para cada ruta.
  Anotación de diagramas de flujo: Esta técnica utiliza un grafo dirigido formado
por nodos y aristas, donde cada nodo representa un punto de decisión o una
secuencia de afirmaciones.
 Complejidad ciclomática: Es la medida de la complejidad lógica y ciclomática de
un software. Se utiliza para definir cuántos caminos independientes hay.
 Pruebas en bucle: Los bucles se utilizan habitualmente en las pruebas de caja
blanca y son fundamentales para muchos algoritmos. Los problemas suelen
encontrarse al principio o al final de un bucle. Las pruebas de bucles pueden
dividirse en bucles simples, bucles anidados y bucles concatenados.

Tipos de pruebas de caja blanca

Para medir la usabilidad de una aplicación o un paquete de software específico se utilizan diversos
tipos de pruebas:

Pruebas unitarias

El programador suele realizarlo como prueba inicial de una aplicación. En este método, cada bloque
de código se prueba a medida que se desarrolla. El desarrollador prueba unas pocas líneas de
código, una sola función o un objeto para comprobar su correcto funcionamiento. Las pruebas
unitarias son útiles porque identifican la mayoría de los errores en una fase temprana del ciclo de
desarrollo, lo que hace que sean más baratos y fáciles de solucionar.

Prueba de calidad

Las fugas de memoria a menudo hacen que una aplicación de software se ejecute lentamente. Si
esto ocurre, se realiza una prueba de control de calidad para examinar el código.

Pruebas de penetración

Esta prueba implica atacar el código desde todas las direcciones para exponer las amenazas de
seguridad. El desarrollador o probador debe saber dónde se ejecuta la aplicación y compilar el
código de la misma, información detallada de la red y el servidor y todas las direcciones IP
conectadas.

Pruebas de mutación

Esta prueba se utiliza generalmente para encontrar las mejores técnicas de codificación en el futuro
para ampliar la aplicación de software.

¿Qué tipo de pruebas de caja negra hay?

Hay muchos tipos de prueba de caja negra, en la siguiente lista vamos a ver las más conocidas con
una pequeña descripción:
 Clase de equivalencias:
  Consisten en diseñar y clasificar entradas de datos para una funcionalidad similar
del software, esperando que sean procesados de la misma manera.

 Estas clases se pueden definir tanto para datos válidos como inválidos.

 La forma de clasificación se define según criterios en función de las salidas de

datos, valores internos, funcionalidades, eventos, etc.

 Según estos datos, se diseñan casos de prueba para cubrir todos o parte de los datos
válidos o inválidos.

 Análisis de valores límites:

 Se valen de los análisis de las pruebas de clase de equivalencias para obtener datos
limites que acoten las posibles causísticas de los datos. Basándose en criterios
como la probabilidad que se presenten más errores.

 Los valores máximos y mínimos son los valores límites.

 Se pueden aplicar para datos válidos e inválidos.

 Se diseña un caso de prueba por cada valor límite.

 Es una forma de identificar defectos de forma óptima y eficiente.

 Tablas de decisiones:
 Las tablas de decisiones son una herramienta fundamental para la documentación
de las reglas de negocio que conllevan una alta complejidad.

 Se crean a partir de las especificaciones funcionales y de las reglas de negocio.

 Las entradas y salidas se representan en muchas ocasiones con valores booleanos

(verdadero o falso).

 Las tablas de decisiones contienen secuencias de condiciones encadenadas con las

combinaciones de los valores booleanos para cada entrada de datos, así como su
resultado esperado de cada combinación.
  Las columnas de las tablas de decisiones se corresponden con una de las reglas de
negocios que se representan con la combinación de las condiciones y de su
resultados.

 Transición entre estados:

 Se basan en los diferentes estados de un software.

 Se representan en un diagrama de transición entre estados.

 Este diagrama de estados permite al tester visualizar información importante sobre

el software, como pueden ser las transiciones, entradas, salidas o eventos
encadenados.

 Una tabla de estado nos permite ver las relaciones entre los estados del software y
las entradas de datos. Nos ayuda a ver posibles transiciones inválidas.

 Pruebas de caso de uso:

 Estas pruebas de caja negra se basan en la representación de las interacciones entre
actores (usuarios o sistemas que interactúan con nuestro software). Basándose en
estas interraciones se pueden diseñar casos de prueba.

 Suelen ir acompañadas de precondiciones que deben cumplirse para los actores

funcionen de forma adecuada.

 Cada caso de uso termina con postcondiciones que serán los resultados analizados
después de la ejecución.

 Se suelen usar para definir las pruebas de aceptación en la que participan usuarios o
clientes.

 Pruebas de historias de usuario:

 Prueba muy utilizada en metodologías Ágiles como puede ser el Scrum. Los
requerimientos de usuario son preparados como historias de usuario.

 Estas historias de usuario describen una funcionalidad que puede ser desarrollada o
probada en una misma secuencia.
  En estas descripciones en las historias de usuarios suelen aparecer funcionalidades
a implementar, requerimientos no funcionales y los criterios de aceptación.

 Los criterios de aceptación abarcan la cobertura mínima requerida para la historia

de usuario.

 Los casos de pruebas se basan en estos criterios de aceptación.

Las pruebas en el ciclo de desarrollo de software.

Las pruebas de caja negra tienen su propio ciclo de vida llamado “Software Testing Life Cycle
(STLC), y dependen de cada etapa del ciclo de vida de desarrollo del software. Quiere decir que en
cada una de las etapas del ciclo de vida de un software se pueden realizar distintos tipos de pruebas.
Hoy en día es muy común que las pruebas se realicen durante cada uno de estas etapas,
consiguiendo así una mejor calidad del software.

Si quieres saber mas sobre este tema, revisa nuestros post de “Testing Funcional.“