Testing: Clase 01 - Introducción

Ciarallo - Jaldin
Julio 2023
Testing: Definición
• Las pruebas de software intentan demostrar que un programa hace lo
que se intenta que haga, así como descubrir defectos en el programa
antes de usarlo. (Dijkstra, 1976)
• Es una suma de metodologías, herramientas y procesos para probar y
encontrar defectos en un sistema o similar.
• Es un proceso integral en el desarrollo de software que tiene como
objetivo evaluar la calidad, el funcionamiento y el rendimiento del
software o aplicación.
Testing: Objetivo
Defect testing: Validation testing:
• Identificar la mayor • Probar que el sistema puede
cantidad de errores lo manejar un número
más tempranamente representativo de transacciones
posible de negocios.
Test exitoso Test exitoso
es el test en que es el test en que
encontramos no encontramos
errores! errores!

Testing uso combinado Testing

Ofensivo Defensivo

TESTING EXITOSO
Verificación y Validación
• Las pruebas se consideran parte de un proceso más amplio de
verificación y validación (V&V) del software. Aunque ambas no son lo
mismo, se confunden con frecuencia.
• Validación: ¿Estamos construyendo el producto correcto?
• Verificación: ¿Estamos construyendo correctamente el producto?
• El objetivo final es establecer confianza de que el sistema de software es
“adecuado”.
¿Cuando hacer testing?

Concepción

Análisis de requerimientos

Diseño del sistema

Programación

Testing

Operación
¿Cuando hacer testing?
 Pruebas estáticas y dinámicas
Pruebas
estáticas
(Inspección)

Requerimientos Arquitectura Modelos UML Esquema BD Programas

Prototipo del sistema Pruebas

dinámicas
Inspección
• Durante las pruebas, los errores pueden enmascarar (ocultar) otras fallas.
• Las versiones incompletas de un sistema se pueden inspeccionar sin costos
adicionales.
• Puede considerar también atributos más amplios de calidad de un
programa, como el cumplimiento con estándares, la portabilidad y la
mantenibilidad.
• No sustituyen a las pruebas del software.
QA y QC
• Quality Assurance: Aseguramiento de Calidad, es el encargado de
llevar adelante todo tipo de pruebas que encuentren errores en etapas
tempranas del desarrollo, asegurando la calidad antes de la salida del
producto y velando porque se cumplan todos los requerimientos del
sistema a entregar. Involucra una serie de inspecciones, revisiones, y los
test o pruebas para garantizar que cada producto de trabajo satisfaga
con los requisitos asignados.
QA y QC
• Quality Control: Control de Calidad, busca el asegurar la calidad del
servicio o producto a base de las especificaciones pautadas por la
organización donde este se desenvuelve. Un “Test Plan” sería la
documentación de cómo se realizaría el Control de Calidad a los
diferentes componentes de la solución (software, documentación,
capacitación, etc.)
 Cualidades de un tester
• Curiosidad: Más allá del conocimiento a la hora de probar, un tester debe
sentir curiosidad por el producto para poder imaginar mejores planes de
prueba.
• Observación: El tester está siempre en los detalles que el resto del equipo
no observa.
• Pensamiento lateral: Viene junto con la creatividad para intentar resolver
problemas buscando vías alternativas, siempre siendo imaginativo en los
resultados.
Calidad
• Es una característica que nos permite comparar distintas cosas del mismo
tipo. Se define, o se calcula, o se le asigna un valor, en base a un conjunto
de propiedades (seguridad, performance, usabilidad, etc.), que podrán ser
ponderadas de distinta forma.

• Conjunto de características y propiedades que determinan la excelencia del

software en términos de funcionamiento, rendimiento, confiabilidad,
usabilidad, mantenibilidad, seguridad y cumplimiento de los requisitos o
requerimientos del usuario.
Calidad
• Se refiere a la medida en que un software cumple con los requisitos
establecidos y satisface las necesidades de los usuarios.

• Según Jerry Weinberg (figura influyente en el desarrollo del pensamiento y

las prácticas de la ingeniería de software) “la calidad es valor para una
persona”.
 Testing: Clase 02 -
Historias de Usuario

Ciarallo - Jaldin
Julio 2023
Historias de usuario
• En el contexto del Agile Testing, las historias de usuario se convierten en requisitos funcionales
que provienen directamente del cliente. Al escuchar las necesidades del cliente y convertirlas
en historias de usuario, esto establece una base sólida para la comunicación y la validación.

• Desde nuestra perspectiva como testers, y a partir de la experiencia que hayamos adquirido en
testing y en ciertos negocios, facilitan nuestra participación en el proyecto en el que nos
encontremos pudiendo identificar detalles que falten y/o aspectos no funcionales que a simple
vista no se aprecian, formulando preguntas abiertas y cerradas al Product Owner (voz del
cliente) llegando de esa forma a confirmar los criterios de aceptación o hasta incluso a provocar
que sean revisados para mejorarlos.

• Tenemos que tener en cuenta que la calidad del producto se persigue entre todos, y que el
equipo de desarrollo está conformado por nosotros ( testets )y los desarrolladores.

• También tenemos que recordar que una historia de usuario no es un requerimiento.

¿Qué son las historias de usuario ?
• Las historias de usuario son una herramienta con la que podremos tratar
cualquier aspecto necesario para la creación de productos , esencialmente son
pequeñas descripciones de necesidades de un cliente .

• Lo más adecuado es el modelo que generalmente debe responder a tres

preguntas:
– ¿quién se beneficia? ¿qué se quiere? y ¿Porque se quiere?
– Cómo [rol del usuario]
– Quiero [conseguir objetivo]
Para [beneficio/valor]

• Esto nació para acercar a el equipo se desarrolladores con los Usuarios y

proponen el término historia de usuarios
Modelo de Historia de usuario

“ Como responsable de inventario quiero conocer cuando

se alcanza el stock para poder realizar mas ordenes de
compra “
 Epicas
• Son requisitos a nivel de negocio o arquitectura (está compuesta por conjunto de historias)
• Esto solamente tiene sentido , si ejecutamos todas las historias de usuarios ya que están muy
relacionadas y tendríamos que tener todo implementado para poder seguir y pasar al siguiente
nivel.
• Por ejemplo :
“ como administrador quiero a todo el personal tenga
el acceso a su recibo de sueldo de forma digital ”
1) Como administrador quiero que todos los empleados tengas un usuario para acceder al sistema
de recibos de sueldos.
2) Como Usuario quiero poder configurar mi contraseña de perfil.
3) Como administrador quiero que se envíe de forma automática un correo electrónico a cada
empleado una vez que su recibo de sueldo esté disponible.
4) Como administrador quiero que se genere un archivo en formato pdf de cada recibo de sueldo y
descargable para cada usuario.
¿Como son las historias de usuario ?
 )Card ( tarjeta ),

3C Conversation ( conversación )
Confirmation ( confirmación )

• Card: cada historia de usuario se reduce hasta hacerla fácil de memorizar y de

sintetizar en una tarjeta o post-it. La tarjeta sirve como recordatorio y promesa de
Una conversación posterior.
• Conversation: el equipo de desarrollo y el propietario del producto añaden Obs=
Si no tenemos las
criterios de aceptación a cada historia poco antes de su implementación. Los tres Cs no es una
cambios son bienvenidos en agilidad, por lo que no tiene sentido profundizar en Historia de
Usuario es un
estos detalles antes. La situación puede variar mucho desde el momento en el que post con una serie
se sintetiza la funcionalidad en la tarjeta hasta que se implementa. de requerimientos
• Confirmation: el propietario del producto o usuario de negocio confirma que el
equipo de desarrollo ha entendido y recogido correctamente sus requisitos
Revisando los criterios de aceptación. A veces se pueden presentar transformados
en escenarios de pruebas.

Historia de usuarios = card + conversation + confirmation

backlog (o pila de producto)
Criterios de aceptación basados en
comportamiento
1 Yo como cliente
2 Quiero quiero realizar una transferencia de dinero Damos un
1_ Quiero transferir 100 pesos sin 2 Quiero un máximo de 1000 en contexto a
necesidad de introducir mi clave trasferencia para evitar fraudes nuestra historia
3 Desde Mi aplicación móvil para poder devolver de usuario

a mi amigo la mitad de la cena que e pagado

1 Dado que [escenario]
2 Cuando [comportamiento]
3 Entonces[resultado]

Contexto : Describe el contexto del escenario que define un comportamiento.

Evento : Representa la acción que el usuario ejecuta, en el contexto definido para el escenario.
 ¿Qué nos aseguramos?
• De no perder funcionalidad cuando introducimos nuevas características o
nuevas historias de usuarios

• Aclaraciones:
Las historia de usuarios no están centradas en el cliente

• Existen antipatrones ejemplo:

Como desarrollador
Quiero descargar el entorno de desarrollo No tiene ningún sentido
es como decir
Para poder desarrollar (voy a subir arriba)
 ¿Otras características?
• Otro anti patrón en el Product Backlog no todo tiene que ser Historias de Usuario, puede tener
casos de uso, requerimientos técnicos,requerimientos no funcionales, puede tener cualquier cosa
que necesitemos implementar dentro de nuestro producto.
• No es recomendable expresar todo en formato de historia de usuario.
• Las historias de usuario nos tiene que aportar valor , para entender cuál es el valor que queremos
generar el software, para nuestros usuarios.
Información necesaria en historias de usuario
● Para decidir qué información incluir en una historia de usuario es preferible
no adoptarnos a formatos rigidos.

● Los resultados de scrum y agilidad no dependen de las formas, sino de la

institución y de sus principios y la implementación adecuada a las
características de la empresa y del proyecto
Campos esenciales

• Descripción: síntesis de la historia de usuario. El estilo puede ser libre pero debe
responder a tres preguntas: ¿quién se beneficia? ¿que se quiere? y ¿cual es el beneficio?

Cómo [rol del usuario], quiero [objetivo], para poder [beneficio].

• Estimación: aproximación del esfuerzo necesario (en tiempo ideal) para implementar la
historia de usuario. Puede estimarse usando unidades de desarrollo (puntos de historia), si
el equipo lo prefiere y está familiarizado con este sistema.

• Prioridad: se indica siguiendo un sistema que permita establecer el orden de

implementación de las historias
Otros campos
• ID: identificador único de la historia de usuario, funcionalidad o trabajo.
• Titulo: título descriptivo de la historia de usuario.
• Valor de negocio: valor (normalmente numérico) que aporta la historia de usuario al cliente o
usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente
en cada iteración. Este campo servirá junto con la estimación para decidir la prioridad de
implementación.
• Criterio de aceptación: pruebas de aceptación consensuadas con el cliente o usuario. A
veces se transforman en pruebas que el código debe superar para dar como finalizada la
implementación.
• Requerimiento no funcional: cualidades generales y restricciones, como la usabilidad o la
seguridad, que afectan a aplicaciones y sistemas enteros, y por tanto a las historias de
usuario individuales.
• Definición de hecho (en inglés DoD, Definition of Done): incluye las actividades o criterios
necesarios para dar por terminada una historia de usuario (desarrollada, probada,
documentada…), según lo convenido por el propietario de producto y el equipo.
Otros campos
• Dependencias: Una historia de usuario no debería depender de otra, pero a veces es
necesario mantener la relación. Este campo contendrá los identificadores de otras historias
de las que depende.

• Persona asignada: Cuando queramos sugerir la persona que pueda implementar la historia
de usuario. Recordar que en scrum el equipo se autogestiona y es quien distribuye y asigna
las tareas.

• Sprint: Puede ser útil para organización del propietario del producto incluir el número de
sprint en el que se prevé construir la historia

• Riesgo: Riesgo técnico o funcional asociado a la implementación de la historia de usuario.

• Observaciones: Para enriquecer o aclarar la informacion, o cualquier otro uso necesario.

• Módulo: Módulo del sistema o producto al que pertenece.

Ejemplos

José Pérez
Como cliente quiero cambiar
la dirección de envió de un El cliente puede cambiar la
pedido dirección de entrega de
cualquiera de los pedidos
que tiene pendiente de
envío
Testing: Clase 03 – Testing en
el proceso de desarrollo

Ciarallo - Jaldin
Julio 2023
 Ambientes
● Local: Entorno de desarrollo que se encuentra en la máquina del desarrollador.
Aquí se desarrolla y prueba el software antes de ser desplegado.

● Desarrollo: Separado del ambiente local donde los desarrolladores trabajan en

conjunto. Aquí se integran y prueban los cambios realizados por los diferentes
desarrolladores antes de ser movidos al ambiente QA.

● QA (Control de Calidad): Aquí se verifican y validan los cambios realizados, se

realizan pruebas funcionales, de rendimiento, seguridad, entre otras.
Ambientes
● Preproducción: Simula el entorno de producción y es utilizado para
realizar pruebas finales antes de la implementación del software en el
ambiente de producción. Aquí se realizan pruebas de integración.

● Producción: Es el ambiente en el cual se ejecuta y se pone a disposición

el software para su uso por parte de los usuarios finales.
Etapas de pruebas

• Pruebas de desarrollo, donde el sistema se pone a prueba durante

el proceso para descubrir errores (bugs) y defectos.

• Versiones de prueba, donde un equipo de prueba por separado

experimenta una versión completa del sistema, antes de presentarlo
a los usuarios.

• Pruebas de usuario, donde los usuarios reales o potenciales de un

sistema prueban el sistema en su propio entorno.
Pruebas de Desarrollo

• Las pruebas de unidad son el proceso de probar componentes del

programa, como métodos o clases de objetos.

• La prueba de componentes tiene que enfocarse en mostrar que la

interfaz de componente se comporta según su especificación.

• Las pruebas de usuario o del cliente son una etapa en el proceso

de pruebas donde los usuarios o clientes proporcionan entrada y
asesoría sobre las pruebas del sistema.
Tipos de pruebas de usuario
• Las pruebas alfa: Los usuarios y desarrolladores trabajan en
conjunto para probar un sistema a medida que se desarrolla

• Las pruebas beta tienen lugar cuando una versión temprana de un

sistema de software, en ocasiones sin terminar, se pone a
disposición de clientes y usuarios para evaluación.

• Las pruebas de aceptación implican a un cliente que prueba de

manera formal un sistema, para decidir si debe o no aceptarlo. La
aceptación implica que debe realizarse el pago por el sistema.
Tareas del tester

• Entender los requerimientos o requisitos.

• Confección de planes de prueba.
• Diseñar casos de prueba.
• Establecer los ambientes de pruebas necesarios.
• Realizar los casos de pruebas.
• Armar informes de pruebas.
• Enviar reportes de defectos.
 Modelo del proceso de pruebas

Casos de Datos de Resultados Reportes de

Prueba prueba de prueba prueba

Preparar Correr el Comparar

Diseñar casos
datos de programa con resultados de
de prueba
prueba datos de prueba casos de prueba
Casos de prueba: Definición
De acuerdo al Estándar IEEE 610 (1990) un caso de prueba se define
como:
“Un conjunto de entradas de prueba, condiciones de ejecución, y
resultados esperados desarrollados con un objetivo particular, tal como el
de ejercitar un camino en particular de un programa o el verificar que
cumple con un requerimiento específico.”
Casos de prueba: Definición
Digamos que el “caso de prueba” es la personalidad más famosa en el
mundo del testing.
Debe incluir varios elementos en su descripción, y entre los que queremos
destacar se encuentran:

• Flujo: secuencia de pasos a ejecutar

• Datos entrada
• Estado inicial
• Valor de respuesta esperado
• Estado final
Cobertura de Pruebas: Definición

• Es una medida de calidad de las pruebas. Se definen cierto tipo de

entidades sobre el sistema, y luego se intenta cubrirlas con las pruebas.

• Es una forma de indicar cuándo probamos suficiente, o para tomar

ideas de qué otra cosa probar (pensando en aumentar la cobertura
elegida).

• La cobertura de prueba nos dice qué porcentaje del código se ha

probado, pero tampoco significa que se haya probado en todas las
situaciones.
Requerimientos: Definición
Los requerimientos son declaraciones que identifican atributos,
características, capacidades, cualidades que necesita cumplir un
entregable para que tenga valor y utilidad. Debe cumplir:

• Completo: el requerimiento debe abarcar la totalidad de una situación o

problema obteniendo todos los recursos necesarios para lograr una
solución óptima.
 Requerimientos: Definición

• Consistente: el requerimiento debe ser coherente con los demás

requerimientos sin entrar en conflicto con otros.

• Factible: el requerimiento permite su implementación real.

• Claro: el requerimiento debe ser preciso, objetivo y fácil de interpretar

• Observable: el requerimiento debe especificar una o varias

características medibles y observables por el cliente. Estas
características deben poder identificarse objetivamente.
Metodología FURSP+
Tipos de requerimientos:

• Funcionales (F): características, capacidades y seguridad.

• Usabilidad (U):Factores humanos, ayuda, documentación, navegación.
• Confiabilidad(R): Frecuencia de fallos, capacidad de recuperación de
una falla y grado de previsión.
Metodología FURSP+
• Soporte (S): Adaptabilidad, facilidad de mantenimiento,
internacionalización, configurabilidad.
• Performance (P): Tiempos de respuesta, productividad, precisión,
disponibilidad, uso de recursos.
• Adicionales (+): Implementación: Limitación de recursos, lenguajes,
herramientas, hardware, etc. Interfaz: Restricciones impuestas para la
iteración con sistemas externos. Operaciones: Gestión del sistema en su
puesta en marcha. Legales: Licencias, etc.
Requerimientos: User stories
Describe una funcionalidad que será útil para un usuario o un cliente de un
software. Se compone de:
Como usuario
Quiero logearme y
• Card: Descripción escrita de la funcionalidad. acceder a intranet
Para poder colaborar
con mi empresa

• Conversation: Conversaciones sobre la story que dan

Puede
cuerpo a los detalles. Que pasa
con las
recordar mi
login?
cuentas
expiradas?

• Confirmation: Tests que documentan detalles que

Las cuentas expiradas no pueden
determinan cuándo una story está completa. logearse.
Recordar el usuario, no el password.
Después de 3 intentos las cuenta se
bloquea por 24hs.
Requerimientos: User stories (card)

Titulo Generar reporte de ventas

Como <ROL DE USUARIO> Como Account Manager

Quiero <OBJETIVO> Quiero recibir un reporte de ventas
Para poder <BENEFICIO> en mi email diariamente
Para poder monitorear el progreso
Criterio de aceptación: de ventas de mis clientes
(Condiciones de satisfacción)
... Criterio de aceptación:
1. El reporte debe enviarse diariamente por email
2. El reporte debe contener el siguiente detalle:..
3. El reporte debe estar en formato .csv
Requerimientos: Casos de uso
• De manera informal, son historias del uso de un sistema para alcanzar
los objetivos.

• Debemos escribir las historias de una forma sencilla. Existe el riesgo de

oscurecer una idea sencilla con niveles de sofisticación.

• Un actor es algo con comportamiento, como una persona (identificada

por un rol), un sistema informatizado u organización. Por ej. Un cajero.

• Un escenario es una secuencia específica de acciones e interacciones

entre los actores y el sistema objeto de estudio; es una historia particular
del uso del sistema, o un camino a través del caso de uso. Por ej. El
escenario de éxito de compra de artículos con pago en efectivo.
Casos de uso: Diagrama
Casos de uso: Ejemplo
● Nombre: Realizar una compra en línea

● Actores principales: Usuario, Sistema de Comercio Electrónico

● Descripción: El caso de uso describe el proceso de un usuario que

realiza una compra en línea a través de un sistema de comercio
electrónico.
 Casos de uso: Ejemplo
Flujo normal:
1. El usuario accede al sitio web del sistema de comercio electrónico.
2. El sistema muestra la página de inicio con los productos y ofertas disponibles.
3. El usuario busca y selecciona un producto de interés.
4. El sistema muestra los detalles del producto, incluyendo su descripción, precio y
opciones de personalización, si las hay.
5. El usuario agrega el producto al carrito de compras.
6. El sistema actualiza el carrito de compras y muestra el contenido actualizado.
7. El usuario decide continuar comprando o proceder a la compra.
8. Si el usuario decide continuar comprando, se repiten los pasos 3 al 7.
9. Si el usuario decide proceder a la compra, el sistema solicita al usuario que inicie
sesión o cree una cuenta si aún no la tiene.
 Casos de uso: Ejemplo
Flujo normal:
10. El usuario proporciona la información de inicio de sesión o crea una cuenta nueva.
11. El sistema valida la información proporcionada por el usuario.
12. El usuario proporciona la dirección de envío y la información de pago.
13. El sistema verifica la disponibilidad del producto y la validez de la información de
pago.
14. El sistema procesa el pago y genera una confirmación de la compra.
15. El sistema envía al usuario una confirmación de la compra por correo electrónico.
16. El sistema actualiza el inventario del producto.
17. El usuario recibe el producto en la dirección de envío proporcionada.
 Requerimientos: Casos de uso
Flujos alternativos:
● En el paso 8, si el usuario decide cancelar la compra, el caso de uso finaliza sin
realizar la compra.
● En el paso 11, si la información de inicio de sesión no es válida, el sistema
muestra un mensaje de error y solicita nuevamente la información.
● En el paso 13, si el producto no está disponible, el sistema muestra un mensaje
de error y permite al usuario elegir otro producto o cancelar la compra.
Testing funcional
• El principal objetivo es testear la funcionalidad a entregar al usuario.

• Tienen que ser regidos por los casos de uso/user stories.

• Para cada caso de uso/user stories, debe existir al menos un test

funcional.

• El test funcional es la base para diseñar los test de aceptación de

usuarios.
Testing no funcional
• De Seguridad: Valida disponibilidad, integridad y confidencialidad de
datos y servicios.

• De Performance: Verifica los tiempos de respuesta del sistema.

• De Stress: Evalúa el uso del sistema en los límites de capacidad y

verificando su comportamiento más allá de los mismos.

• Usabilidad: Evalúa la facilidad de uso del sistema.

Otros tipos de testing
• De caja negra/caja blanca

• De regresión

• De instalación

• Estático/Dinámico

• Alfa/Beta testing
 Testing: Clase 04 -
Testing en el proceso de
desarrollo
Ciarallo - Jaldin
Julio 2023
Pruebas Dinámicas y Estáticas
PRUEBAS PRUEBAS
ESTATICAS DINAMICAS

FUNCIONALES NO FUNCIONALES

DOCUMENTACION

EXPLORATORIAS CARGA
METRICAS

REGRESION ESTRES
DISEÑO DE CASOS
DE PRUEBA

SANIDAD USABILIDAD
Pruebas Dinámicas

Las pruebas dinámicas son aquellas que se realizan mientras el código está
en ejecución. Tienen como objetivo asegurar que el software se comporte
de acuerdo con los requerimientos del negocio mediante la realización de
pruebas funcionales y no funcionales.

Estas pruebas se enfocan en la detección y confirmación de la corrección

de defectos en el software. Por lo general se realizan en una etapa más
tardía que las pruebas estáticas, por lo cual, los defectos encontrados en
estas son más costosos
Pruebas Estáticas
A diferencia de las pruebas dinámicas, estas no requieren de la ejecución
de software para ser realizadas. Parte del objetivo de las pruebas estáticas es
la revisión de productos de trabajo como documentos de requerimientos, casos
de prueba, planes de prueba, código, guías de usuario.
Estas pruebas se enfocan en la prevención de defectos y en la detección
temprana de los mismos, ya que se pueden realizar en cualquier etapa del ciclo
de vida de software según la información que se tenga disponible

Cabe destacar que ambos tipos de prueba buscan el mismo objetivo general,
asegurar la calidad del producto. Si bien es cierto que cada uno tiene su
momento de aplicación particular, estos dos tipos de pruebas no son contrarios,
sino que se complementan el uno al otro.
Pruebas Dinámicas vs. Pruebas Estáticas

En Ejecución No Ejecución
Las pruebas se realizan a productos de
Las pruebas se realizan mientras el código trabajo como documentos de requerimiento
está en ejecución. ,casos de prueba planes de prueba y
código.
Detección Prevención

Estas pruebas se enfocan en la detección de Estas pruebas se enfocan en la prevención

defectos. de defectos.

Pruebas Tardía Pruebas tempranas

Esta prueba se realizan cuando el código es Estas pruebas se pueden realizar desde la
desplegable a un ambiente de pruebas. primera etapa del ciclo de vida del software.

Técnica Técnicas
Se utilizan tipos de prueba : Se utilizan técnicas como :
• Funcionales • Revisión técnica
• No funcionales • Inspección
• Revisión de código
Pruebas Funcionales
Pruebas Exploratorias: Son las pruebas que se ejecutan sin un Plan de prueba
determinado. Consiste en ejecutar las pruebas a medida que se piensa en ellas, sin
gastar demasiado tiempo en prepararlas o explicarlas, confiando en los instintos.

Pruebas De Regresión: Evita que al introducir nuevos cambios en un software se

obtengan comportamientos no deseados. Se refieren a un conjunto de pruebas que
se ejecutan para comprobar que todo funciona correctamente después de alguna
intervención o modificación.

Pruebas De Humo o Smoke Tests: Este tipo de pruebas es una revisión rápida
inicial de la versión de software entregada por desarrollo donde se verificará de forma
general sin entrar en detalle las principales funcionalidades del mismo y se aseguraré
que no tiene defectos que interrumpa el funcionamiento básico del mismo.

Pruebas De Sanidad: son un tipo de pruebas de software que los probadores

utilizan para determinar cómo funciona una compilación de software después de que
se hayan realizado cambios
Pruebas no funcionales
Pruebas de carga: es una prueba planificada para realizar un número especificado
de solicitudes a un sistema con el fin de probar la funcionalidad del sistema bajo
niveles específicos de solicitudes simultáneas. Una prueba de carga garantiza que
un sistema web pueda controlar un volumen de tráfico esperado. El objetivo de una
prueba de expectativa de usuarios.

Pruebas de estrés: Por otro lado las pruebas de estrés son realizadas
sobrecargando un sistema más allá de sus especificaciones, para verificar cómo y
cuándo fallará. Dentro de informática podemos colocar una gran carga en la base
de datos, entradas (peticiones) continuos al sistema o almacenar información más
allá de la capacidad de memoria del sistema.

Pruebas de usabilidad: son una forma de probar cómo los visitantes que navegan
en tu sitio web con el objetivo de facilitar su experiencia web y dejarla cada vez más
simple e intuitiva,
Definición: error, defecto, fallo
Para entender las pruebas debemos diferenciar los términos error, fallo y
defecto. Estos conceptos están relacionados entre sí, pero tienen
significados diferentes.
vamos a ver como las define el ISTQB:
ISTQB( International Software Testing Qualifications Board )
“certificación internacional para la calidad del software”

“Una persona puede cometer un error que a su vez puede producir un

defecto en el código de programa o en un documento. Si se ejecuta un
defecto en el código, el sistema puede no hacer lo que debiera (o hacer
algo que no debiera), lo que provocaría un fallo. Algunos defectos de
software pueden dar lugar a fallos, pero no todos los defectos lo hacen.”
 2+2=5
Error: está provocado por la acción humana,
por ejemplo el error lo provocará el
desarrollador que realizará una incorrecta
interpretación de un método del programa que
producirá un resultado no esperado.
Ejemplo 2+2=5 2+2=error

Defecto: es una condición que causa que un

software falle al realizar una función requerida.
Ejemplo 2+2=Error

Fallo: es la incapacidad de un software para 2+2

realizar una función requerida de acuerdo a
sus especificaciones ( son producidas por falta

defectos) Ejemplo falta (=) 2+2 4

Prioridad y Severidad del bug
La prioridad viene del negocio, en este caso uno se pregunta La severidad, además de ser un atributo técnico, está
cuán importante es para el negocio que se arregle este defecto. enfocada en la experiencia del usuario con la aplicación.
La severidad es técnica. La mayoría de las veces un defecto de Asignar la severidad de un defecto es simple, los testers lo
alta severidad se convierte en un defecto de alta prioridad , pero pueden hacer teniendo conocimiento del proyecto. Sin
no siempre, hay casos que defectos de alta severidad tienen una embargo, asignar la prioridad es más difícil.
prioridad baja y viceversa.

La severidad es uno de los factores que se toma en

SEVERIDAD consideración cuando se asigna la prioridad de un defecto.
Otros de los factores son: cuanto tiempo queda para salir a
Inhibe la continuidad del producción, cuánto tiempo lleva resolver el defecto,quien
PRIORIDAD
CRITICO desarrollo de pruebas esté disponible para arreglarlo, cuán importante es para el
negocio, arreglarlo, cual es el impacto, cuál es la
Perdida mayor de una
Debe ser resuelto lo probabilidad de ocurrencia y cual es el grado de efectos
ALTO funcionalidad , resultados
extremadamente incorrectos .
antes posible colaterales que puede causar el defecto.

Se puede resolver con el

MEDIO Una parte de un componente
curso normal del
no es funcional
desarrollo y pruebas
BAJO Generalmente son problemas Se puede resolver en
de apariencia fecha posterior
 Prioridad y Severidad del bug
En muchas organizaciones, los defectos de
cierta severidad deben ser al menos de cierta
prioridad.
Por ejemplo, los defectos que llevan a cerrar el Prioridad
sistema o le hacen perder datos al usuario Urgente Bajo

tienen que ser prioridad uno (1)

Severidad
Critico
Funcionalidad muy Funcionalidad que
si se puede reproducir siempre. Si pasa el 1% importante que no rara vez es utilizada
anda bien no anda bien
de las veces, sería de última prioridad,
manteniendo en ambos casos la severidad alta.

No Critico
Una falta de ortografía en la página principal de Logotipo de la
empresa tiene el color
Una palabra tiene un
tipo de fuente
un sitio web es un defecto de severidad baja, es incorrecto incorrecta

muy fácil de arreglar, pero para el negocio su

prioridad es alta, ya que afecta la imagen de la
compañía.
Documentación y lectura de reportes, atributos
Identificador del reporte: Un identificador Único que permita Ambiente: La calidad no es responsabilidad solo de testing, por lo
trazar el defecto, ejemplos: BUG-001, ABCO-01 que un defecto no solo puede ser encontrado en un ambiente de
‘Pruebas’, también existen otras fases del ciclo de vida de desarrollo
Título o descripción : que describa el defecto de forma breve. del software donde es posible encontrar un defecto, ya sea,
Un título que permita interpretar fácilmente el defecto ambiente de desarrollo, UAT(Pruebas de aceptación de usuario),
user acceptance testing ,Produccion.
Informador o tester: En caso de que haya preguntas de como
reproducir el problema, es importante que los desarrolladores Pasos a Paso : necesitamos comunicar y detallar bien los pasos
puedan identificar a la persona que reportó el incidente. para poder reproducir el error indiferente de quien lo lea.

Estado: Según los estados definidos para el ciclo de vida, por Resultado Esperado: Lo que deberíamos obtener según la
ejemplo: Abierto , cerrado, en revisión, anulado especificación.
(ver ciclo de vida del bug).
Resultado Obtenido :El error de lo que obtuvimos en la prueba.
Versión: Especificar en qué versión del paquete, funcionalidad o
producto se encuentre el defecto. Evidencia: Al mostrar los pasos de como reproducir, 0 el resultado
obtenido, ayuda mucho poder tener capturas de pantalla que le
Severidad: La severidad se mide en función a cuánto impacta el
permitan al desarrollador ver el problema más claramente. Puede
error en el código y facilita la priorización para la resolución de
la incidencia. ser capturas de pantalla, videos, partes del codigo u otros.

Prioridad: Importancia que el tester le da al defecto.

Template de reporte
Testing: Clase 05 – Diseño de
Casos de Prueba

Ciarallo - Jaldin
Julio 2023
Casos de prueba: Definición
Digamos que el “caso de prueba” es la personalidad más famosa en el
mundo del testing.
Ésta debe incluir varios elementos en su descripción, y entre los que
queremos destacar se encuentran:

• Flujo: secuencia de pasos a ejecutar

• Datos entrada
• Estado inicial
• Valor de respuesta esperado
• Estado final esperado
Casos de prueba: Definición
• Un caso de prueba abstracto: se caracteriza por no tener
determinados los valores para las entradas y salidas esperadas. Se
utilizan variables y se describen con operadores lógicos. Describe un
escenario determinado de un requerimiento.

• Un caso de prueba específico (o concreto) es una instancia de un caso

de prueba abstracto, en la que se determinan valores específicos para
cada variable de entrada y para cada salida esperada. Pueden ser
diseñados usando diferentes herramientas.
Casos de prueba: Técnicas para el armado
• Clases de Equivalencia
• Valores Límite
• Tablas de Decisión
• Maquinas de Estado
• Combinación por Pares
 Diseño de casos de prueba

Combinar Calcular
Identificar Seleccionar
Valores Valores
Variables Valores
Esperados

No
Clases de Combinación
Valor Límite Ocultamiento
Equivalencias por pares
de errores
Identificar variables

• Entradas del usuario por pantalla.

• Parámetros del sistema (en archivos de configuración, parámetros de

invocación del programa, tablas de parámetros, etc.).

• Estado de la base de datos (existencia –o no– de registros con

determinados valores o propiedades).
Identificar variables
Clases de equivalencia
Técnicas: Clases de equivalencia

• Es una partición tal del input que se puede asumir que el test sobre un
valor de una clase es lo mismo que testear cualquier otro valor de esa
clase.

• Procedimiento:

Paso 1) Identificar las clases de equivalencia

Paso 2) Construir los casos de test
Técnicas: Clases de equivalencia
Paso 1) Identificar las clases de equivalencia

• Si el input es un conjunto de valores y hay razón para suponer que cada

uno es tratado diferente por el sistema, identificar una clase de
equivalencia para cada uno, y una clase inválida.

perDiem 1 <= perDiem <= 999 (válida)

perDiem < 1 (inválida)
perDiem > 999 (inválida)
Técnicas: Clases de equivalencia
• Si el input es un conjunto de valores y hay razón para suponer que cada
uno es tratado diferente por el sistema, identificar una clase de
equivalencia para cada uno, y una clase inválida.

Vehículo
(AVION AUTO (válida)
se procesa AVION (válida)
distinto) TAXI (inválida)
Técnicas: Clases de equivalencia
• Si el input especifica una condición 'debe ser', identificar una clase de
equivalencia válida y una inválida.

Legajo primer char es una letra (válida)

(comienza con una letra) primer char no es una letra (inválida)
Técnicas: Clases de equivalencia
• Si existen razones para suponer que los elementos de una clase de
equivalencia no son tratados de igual manera por el programa, dividir la
clase en clases más pequeñas.

perDiem 1 <= perDiem < 500 (válida)

(para valores 500 <= perDiem <= 999 (válida)
mayores a 500,
se necesita perDiem < 1 (inválida)
autorización) perDiem > 999 (inválida)
Técnicas: Clases de equivalencia
Paso 2) Construir los Casos de Test:

Legajo a. Identificar cada clase de equivalencia con un

perDiem número.
Vehículo
b. Escribir casos de test hasta que todas las
clases de equivalencia válidas sean cubiertas.

c. Escribir un caso de test para cada una de las

clases de equivalencia inválidas.
Técnicas: Clases de equivalencia
primer char es una letra (1) AUTO (7)
primer char no es una letra (2) AVION (8)
TAXI (9)
1 <= perDiem < 500 (3)
500 <= perDiem <= 999 (4)
perDiem < 1 (5)
perDiem > 999 (6)
Técnicas: Valores limite
• Es una variante del método de clases de equivalencia

• Procedimiento:

Paso 1) Identificar las clases de equivalencia.

Paso 2) Identificar los valores de borde dentro de cada clase de equivalencia.
Paso 3) Crear casos de test para cada condición de borde eligiendo el valor de
borde, un valor por debajo y un valor por encima.
Técnicas: Valores limite

perDiem
(para valores 1 <= perDiem < 500
500 <= perDiem <= 999
mayores a 500,
perDiem < 1
se necesita perDiem > 999
autorización)
Técnicas: Valores limite
Nuevos test cases con la técnica de condiciones de borde (boundary values):

primer char es una letra (1)

primer char no es una letra (2)
0.999 (3)
1 (4)
1.001 (5)
499.999 (6)
500 (7)
500.001 (8)
998.999 (9)
999 (10)
999.001 (11)
AUTO (12)
AVION (13)
TAXI (14)
 Combinación por pares
Supongamos que la función de envío de mensajes de texto tiene los siguientes
parámetros:

● Destinatario: Permite elegir entre una lista de contactos (A, B ,C).

● Tipo de mensaje: Puede ser "texto" o "imagen".
● Prioridad: Puede ser "alta", "media" o "baja".
● Notificación: Puede ser "activada" o "desactivada".

En lugar de probar todas las combinaciones posibles de estos parámetros, lo

cual sería tedioso y consumiría mucho tiempo, se puede utilizar la técnica de
combinación por pares para identificar las combinaciones críticas y realizar
pruebas más efectivas.
 Combinación por pares
Por ejemplo, podríamos seleccionar las siguientes combinaciones para probar:

● Destinatario: Contacto A, Tipo de mensaje: Texto, Prioridad: Alta,

Notificación: Activada.
● Destinatario: Contacto B, Tipo de mensaje: Imagen, Prioridad: Baja,
Notificación: Desactivada.
● Destinatario: Contacto C, Tipo de mensaje: Texto, Prioridad: Media,
Notificación: Activada.

Al utilizar la técnica de combinación por pares, puedes cubrir todas las

combinaciones posibles de manera eficiente con un número mínimo de
pruebas.
Testing: Clase 06 – Pruebas de
Caja Negra

Ciarallo - Jaldin
Julio 2023
Pruebas de Caja Negra
● Son pruebas funcionales o inducidas por datos

● Prueba lo que el software debería hacer.

● Se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin
preocuparse de lo que ocurre en el interior.

● Por lo anterior, se suelen llamar también “pruebas de entrada / salida”.

CAJA NEGRA

ENTRADA SALIDA
Pruebas de Caja Negra

1 Clases de equivalencia

2 Condiciones de borde
Técnica de
derivación de casos
de prueba 3 Ingreso de valores de otro
tipo

4 Conjetura de errores
Clases de equivalencia (CE)
• Consiste en dividir los valores de entrada en clases de datos para derivar casos de prueba.

• Se asume que el resultado de una prueba con un valor representativo de cada CE equivale a
realizar la misma prueba con cualquier otro valor de la CE.

• Pasos para diseñar casos de prueba:

Identificar clases de equivalencia.
Identificar los casos de prueba.
Minimizando no casos de prueba, considerar tantas condiciones como sea posible.

• Pasos:
• Asignar a cada CE un representante único.
• Definir casos de prueba que cubran tantas CE válidas como sea posible.
• Repetir hasta que todas las CE estén cubiertas.
• Definir un caso de prueba para cubrir una única CE no válida.
• Repetir hasta que todas estén cubiertas.
1 Identificación de clases de equivalencia
Se divide cada condición de entrada en dos grupos:
• Clases Válidas

• Clases Inválidas

Clases validas Clases invalidas

01 < edad < 100 Edad < 01

Edad >100
1 Identificación de clases de equivalencia
Por ejemplo, si tenemos las siguientes opciones de entradas de datos:
• Rango de valores. Si una condición de entrada especifica un rango de
• valores (Ej edad entre 1 y 100).
• Si una condición de entrada especifica un “debe ser”
(Ej.: El primer carácter debe ser un dígito)

Clases validas Clases invalidas

Primer carácter distinto de digito

Primer carácter un digito
(Ejemplo : una legra)
2 Identificación Condición de Borde
• Es una variación de la técnica de partición de equivalencias, focalizada en
los bordes de cada clase de equivalencia, por arriba y por debajo.

• Los casos de prueba que exploran las condiciones de borde producen

mejor resultado que aquellas que no lo hacen.

Clases validas Clases invalidas

Edad=1 Edad =0

Edad =100 Edad =101

3 Valores de otro tipo
Ingreso de valores de otro tipo: La combinación de los datos de entrada es
las que produce una clase válida o inválida:
• Alfabéticos en vez de numéricos.
• Ingreso de valores de otro tipo
• Combinaciones de ambos.

Edad
4 Conjetura de errores
Prueba de Sospechas (“Sospechamos” que algo puede andar mal)
• Enumeramos una lista de errores posibles o de situaciones propensas
tener errores
• Creamos casos de prueba basados en esas situaciones

Edad
Clases de equivalencia (CE) en Test de Caja Negra

Ejemplo : Un programa requiere números dentro[ 1 hasta el máximo 100 ]

Claves validos Clases invalidas

1< números <100

Ingresar tu edad Números < 1
Números > 100

Posible clases de equivalencia : Definir clases de datos válidos y datos no válidos

La clase de equivalencia es válida si la edad si es

1 Caso de prueba : Validar extremos
mayor o igual a uno y menor o igual a 100

2 Caso de prueba : No es válido dato mayor a 100 La edad es mayor a 100

3 Caso de prueba : No es válido dato menor a 1 La edad es menor a 1

4 Caso de prueba : No es válido dato que sea decimal La edad posee decimales

5 Caso de prueba : No es válido un dato que posea

La edad posee caracteres alfanuméricos
carácter no numérico
Testing: Clase 07 – Testing en
Agilidad

Ciarallo - Jaldin
Julio 2023
Agilismo: Definición
• El agilismo, también conocido como Agile, es una filosofía y conjunto de
prácticas que se enfocan en la entrega rápida, flexible y colaborativa de
proyectos y productos en entornos empresariales. Se originó en el
campo del desarrollo de software como respuesta a los enfoques
tradicionales y rígidos de gestión de proyectos, que a menudo
resultaban lentos, burocráticos y poco adaptativos.
 Agilismo: Definición
Se basa en el Manifiesto Ágil, un documento redactado en 2001 por un
grupo de expertos en desarrollo de software, que establece los valores y
principios fundamentales de esta metodología. Los valores del Manifiesto
Ágil son:

1. Individuos e interacciones sobre procesos y herramientas.

2. Software funcionando sobre documentación extensiva.
3. Colaboración con el cliente sobre negociación contractual.
4. Respuesta ante el cambio sobre seguir un plan.
Agilismo: Definición

• Las metodologías ágiles más conocidas son Scrum y Kanban, pero

existen otras como Extreme Programming (XP) y Lean, cada una con
sus propias características y enfoques. Sin embargo, todas comparten el
objetivo común de fomentar la flexibilidad, la colaboración y la entrega
de valor de manera iterativa e incremental.
Scrum: Definición

• Scrum es una metodología ágil ampliamente utilizada en la gestión de

proyectos, especialmente en el desarrollo de software. Se basa en la
entrega incremental y en la colaboración constante entre los miembros
del equipo para lograr resultados óptimos.
 Scrum: Roles
• Product Owner: Es el responsable de definir y priorizar los elementos del
producto, así como de comunicar las necesidades y expectativas del
cliente al equipo de desarrollo.

• Scrum Master: Es el facilitador del equipo Scrum. Su función principal es

asegurarse de que se sigan los principios y prácticas de Scrum, y eliminar
cualquier obstáculo que pueda afectar la productividad del equipo.

• Equipo de Desarrollo: Está formado por los profesionales encargados de

llevar a cabo el trabajo necesario para entregar el producto. Son
autónomos y autoorganizados, y colaboran estrechamente entre sí para
alcanzar los objetivos establecidos.
Agilismo: Definición
 Scrum: Artefactos
• Product Backlog: Es una lista priorizada de todas las funcionalidades,
requisitos y mejoras pendientes del producto. El Product Owner es
responsable de mantener y actualizar el Product Backlog.

• Sprint Backlog: Es una lista de elementos seleccionados del Product

Backlog que el equipo se compromete a completar durante un sprint.

• Incremento: Es el resultado tangible y potencialmente entregable del

trabajo realizado durante un sprint. Al final de cada sprint, el equipo debe
entregar un incremento del producto.
Scrum: Artefactos
Scrum: Artefactos
Scrum: Eventos
• Sprint: Es un período de tiempo, generalmente de 1 a 4 semanas
(idealmente 15 días), durante el cual se desarrolla, prueba y entrega un
incremento del producto.

• Release: Un conjunto de funcionalidades a liberar en un periodo de

tiempo. Abarca más de un sprint.
Scrum: Ceremonias

• Sprint Planning: Se lleva a cabo al comienzo de cada sprint y tiene

como objetivo definir el objetivo del sprint y seleccionar los elementos
del Product Backlog que se incluirán en el Sprint Backlog.
• Refinement: Se lleva a cabo al comienzo del sprint, consiste en una
estimación por parte del equipo de trabajo.
• Daily: De 15 minutos en la que el equipo comparte el progreso
realizado, las tareas que se llevarán a cabo y cualquier impedimento.
• Sprint Review: Al final de cada sprint, el equipo muestra el incremento
desarrollado al Product Owner.
• Retrospective: Se lleva a cabo después de la Revisión del Sprint, en
la cual el equipo reflexiona sobre el sprint anterior y busca mejoras.
Scrum: Ceremonias
Scrum: Rol del Tester
● En términos generales debe garantizar la calidad del producto
desarrollado y contribuir activamente en el proceso de entrega del
producto.

● Colaboración en la definición de requisitos: En estrecha colaboración

con el Product Owner y otros miembros del equipo para comprender y
clarificar los requisitos del producto. Participa en las reuniones de
refinamiento del backlog y puede ayudar a identificar criterios de
aceptación y definir historias de usuario con un enfoque en la
verificabilidad.
Scrum: Rol del Tester
● Participación en la planificación del sprint: El tester contribuye en la
selección de elementos del Product Backlog que se incluirán en el
Sprint Backlog y ayuda a estimar las tareas relacionadas con las
pruebas. Proporciona información valiosa sobre la complejidad de las
pruebas y los riesgos asociados.

● Diseño de los casos de prueba: El tester es responsable de diseñar los

casos de prueba y escenarios necesarios para verificar que el producto
cumpla con los requisitos y funcionalidades definidos. Trabaja en
colaboración con el equipo para identificar las pruebas necesarias y
asegurarse de que se cubran los aspectos críticos del producto.
Scrum: Rol del Tester
● Ejecución de pruebas: El tester lleva a cabo las pruebas según el
diseño establecido. Puede incluir pruebas funcionales, pruebas de
regresión, pruebas de rendimiento, pruebas de seguridad, entre otras.
Realiza pruebas manuales y, en muchos casos, también puede utilizar
herramientas de automatización para acelerar y mejorar la eficiencia de
las pruebas.

● Reporte y seguimiento de incidencias: Si se encuentran errores durante

las pruebas, el tester registra las incidencias y las comunica al equipo
de desarrollo y al Product Owner. Participa activamente en la resolución
de problemas y en el seguimiento de las correcciones para garantizar la
calidad del producto.
Scrum: Rol del Tester
● Colaboración en las revisiones del sprint: El tester participa en la
reunión de Revisión del Sprint, mostrando los resultados de las pruebas
realizadas y proporcionando información relevante sobre la calidad del
producto. Esto contribuye a la toma de decisiones sobre el incremento y
los posibles ajustes necesarios.

● En Scrum, el enfoque de trabajo es colaborativo y el equipo es

multidisciplinario, por lo que todos los miembros, incluido el tester,
trabajan juntos para lograr los objetivos del sprint y entregar un
producto de alta calidad.
 Testing: Clase 08 -
Técnicas TDD y BDD
Ciarallo - Jaldin
Julio 2023
 Modelos de Testing
• Aunque TDD no fue creado para testing, es un sistema muy utilizado en
este ámbito. Es una metodología de desarrollo cuyo objetivo es crear
primero las pruebas y luego escribir el software y luego probar si el software
está funcionando de acuerdo a esas pruebas "pre-planeadas".

• BDD (Behavior Driven Development), también es una estrategia de

desarrollo dirigido por comportamiento, que ha evolucionado desde TDD
(Test Driven Development), y tampoco nació como una técnica de testing.

• Tanto en TDD como en BDD, las pruebas se deben definir antes del
desarrollo, aunque en BDD, las pruebas se centran en el usuario y el
comportamiento del sistema como un conjunto, a diferencia del TDD que se
centra en funcionalidades específicas del software.
 ¿Qué enfoque aplicar? ¿TDD o BDD?
• Aunque TDD o BDD parecen muy similares, la principal diferencia entre
ambas está en el alcance. TDD es una práctica de desarrollo, enfocada en
cómo revisar el sistema y cómo debería funcionar. Mientras que BDD es
un enfoque de equipo que hace hincapié en por qué debes revisar ese
código y por qué se debería comportar de una forma u otra.

• En TDD el tester escribe los tests mientras que en BDD el usuario final,
junto al resto del equipo multidisciplinario, escriben los tests.
(SDLC) Software Development Life Cycle
● Un modelo de ciclo de vida de desarrollo de software describe los tipos
de actividades que se realizan en cada etapa de un proyecto de desarrollo
de software, y cómo se relacionan entre sí de forma lógica y cronológica .
Hay diferentes modelos , cada uno requiere diferentes enfoques de pruebas.
Modelos de desarrollo secuencial

Modelos de desarrollo iterativos e incrementales.

Modelo Cascada
Fase 1

Fase 2

● El modelo en Cascada o waterfall model, es la propuesta de un enfoque

metodológico que consiste en ordenar de forma lineal las distintas
etapas que debes de seguir al momento de desarrollar tu software.
Propone dividir en fases cada etapa del desarrollo de software y
completar cada una de ellas en un orden específico, es decir, no puedes
iniciar la “fase 2" hasta que hayas concluido la “fase 1”.
Metodología Agile: Iterativo Incremental
• La metodología ágil es una práctica que
promueve la interacción continua del
desarrollo y las pruebas durante el proceso
de SDLC de cualquier proyecto. En el
método gil, todo el proyecto se divide en
pequeñas construcciones incrementales.

• Todas estas construcciones se proporcionan

en iteraciones, y cada iteración dura de una
a tres semanas.
Prueba de Velocidad
• [Link]
• Hay que medir la velocidad de internet
• Primero sube un archivo y después hace una bajada de
archivo
• Para hacer pruebas de tests

Damos inicio
Iniciar el programa Genera resultados

Descargar Subir
Resultados
Check My Links
'Check My Links' encuentra rápidamente todos los enlaces en una página web
y comprueba cada uno por usted. Destaca cuáles son válidos y cuáles están
rotos, así de simple.

Error 404
 WhatFont
• Tipo de fuente estipulados por el diseño de la marca

Nos indica el tipo de

fuente para verificar si
es la misma pedida por
las indicaciones del
cliente
ColorZilla
Nos indica el color para
verificar si es que el color
esperado
Testing: Clase 09 – Técnicas
Diseño de Casos de Prueba

Ciarallo - Jaldin
Julio 2023
Técnicas de Diseño Casos de prueba
• Existen distintas técnicas, y cada vez que estemos diseñando pruebas
veremos que hay algunas que son más apropiadas que otras según el
caso.

• Veremos cuándo son más convenientes, en qué tipo de situaciones nos

dan más valor. En cambio, las técnicas vistas anteriormente (clases de
equivalencia, valores limites, etc.) las utilizamos siempre.

• Estas las utilizaremos solo para cuando queremos lograr una mejor
cobertura, o si la técnica concreta aplica para la situación que estamos
probando.
Técnicas de Diseño Casos de prueba
• Tablas de decisión

• Grafos causa-efecto

• Máquinas de estado

• Matriz CRUD
Tablas de decisión
• Las tablas de decisión (DT) son utilizadas para modelar reglas de
negocio complejas.

• Se listan las condiciones y acciones identificadas en una matriz. Luego,

debemos identificar cuáles son los posibles valores para esas
condiciones y cómo están relacionadas.

• Estas las llenaremos en la matriz en una forma especial de forma que al

terminar de completarla ya tendremos las combinaciones que
conformarán los casos de prueba.

• Cada columna indicará una posible combinación entre condición y

acción. De esta forma las modelamos en una estructura lógica.
Tablas de decisión

Forma general de una DT:

Regla 1 Regla 2

Condición 1

Condición 2

… … …

Condición n

Acción 1

Acción 2
Tablas de decisión
Crear la tabla de decisión que modela el comportamiento
de las reglas de negocio

Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Casado? Si Si No No

Buen estudiante? Si No Si No

Acciones … …

Descuento 60% 25% 50% 0%

Tablas de decisión
Cada columna se convierte en un test case!
Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Condición 1 0-1 1-10 10-100 100-1000

Condición 2 <5 5 6o7 >7

Acciones … …

Acción 1 Hacer X Hacer Y Hacer X Hacer Z

Acción 2 Hacer A Hacer B Hacer B Hacer B

Test ID Regla 1 Regla 2 Regla 3

TC001 0 3 Hacer X/Hacer A

TC002 5 5 Hacer Y/Hacer B

TC003 50 7 Hacer X/Hacer B

TC004 500 10 Hacer Z/Hacer B

Grafos causa-efecto

• Representan la relación lógica entre distintas causas y los posibles

efectos. Para esto se listan las causas (entradas o acciones del usuario)
y los efectos (salidas o acciones del sistema esperadas), y luego se
unen indicando relaciones entre ellos.
Grafos causa-efecto

Si sucede C1 entonces E1 Si no sucede C1 entonces E1

Si sucede C1 o C2entonces E1 Si sucede C1 y C2 entonces E1

Grafos causa-efecto: Ejemplo
Dadas un conjunto de reglas considerando que estamos probando
un sistema que determina el importe a cobrarle a los clientes de una tienda según
estos criterios:

· Si pagan con efectivo tendrán un 20% de descuento.

· Si pagan con tarjeta de débito tendrán un 15% de descuento.
· Si pagan con tarjeta de crédito tendrá un 5% de recargo.
· Si pagan con tarjeta de crédito premium de algún banco, tendrán un 10% de
descuento.
· Las acciones son acumulables.
Grafos causa-efecto: Ejemplo
Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Pago en efectivo si no no no
Pago con tarjeta de débito no si no no

Pago con tarjeta de crédito no no si si

Pago con tarjeta de crédito no no no si

premium
Acción 1 20% de 15% de 5% de recargo 5% de
descuento descuento recargo

Acción 2 - - - 10% de
descuento
Grafos causa-efecto: Ejemplo
Grafos causa-efecto: Ejemplo
1) Identificar Causas y efectos
Grafos causa-efecto: Ejemplo
2) Elaboramos grafos
Grafos causa-efecto: Ejemplo
3) Elaboramos la Tabla de decisión
Grafos causa-efecto: Ejemplo
3) Elaboramos los casos de prueba
Matrix CRUD
• Cada entidad de un sistema de información tiene un ciclo de vida: todo
nace, crece (se actualiza) y muere (se elimina), y en el medio es
consultado.

• Se utiliza para representar las operaciones básicas que se pueden

realizar a diferentes entidades de un sistema en diferentes
funcionalidades.

• A esto se suele referenciar como el patrón CRUD (Create, read, update,

delete).
Matrix CRUD
Funcionalidad Cliente Factura Producto

Registrar cliente C - -

Modificar datos cliente U - -

Listar clientes R - -

Listar productos - - R

Dar alta factura R, U C R, U

Dar alta de producto - - C

Dar baja producto - - D

Listar productos - - R

Listar facturas R R -

Dar baja cliente D - -

Matrix CRUD
● Luego, se pasa a realizar una verificación de consistencia: probar
distintas funcionalidades de forma tal que se haga pasar por todo el ciclo
de vida a cada entidad.

● Para cada entidad relevante deberían cubrirse todas las acciones C, R,

U y D con la ejecución de la menor cantidad de funcionalidades
posibles.
 Testing: Clase 10 -
Clasificación de Pruebas,
Selenium
Ciarallo - Jaldin
Julio 2023
Clasificación de Pruebas
• Funcionales Se realiza la validación de las funciones del sistema,
basándose en el requerimiento de las acciones a realizar.
Se centran en los requisitos. Solo verifican el resultado de una acción y no
comprueban los estados intermedios del sistema al realizar dicha acción.

• No Funcionales Se analiza y testea el desempeño, escalabilidad,

estabilidad y todo otro requerimiento no funcional.

• Caja Blanca Se analiza fallas de seguridad, flujo de valores, código interno

y resultados informados por la base de datos. Generalmente realizado por
programadores.
Clasificación de Pruebas
• Caja Negra Se realiza desde fuera del código, solamente se realiza pruebas
de uso con valores válidos e inválidos. Se analizan los resultados que arroja
el software.

• Regresión Se verifican que los cambios hechos anteriormente, por fallas

informadas o por modificaciones del software, no hayan afectado
funcionalidades preexistentes. Incluye cambios o nuevas características y
fallas que implementen modificación de código.

• Pruebas unitarias Las pruebas unitarias son de muy bajo nivel y se

realizan cerca de la fuente de la aplicación. Consisten en probar métodos y
funciones individuales de las clases, componentes o módulos que usa tu
software. Las pruebas unitarias son bastante baratas de automatizar y se
pueden ejecutar rápidamente mediante un servidor de integración continua.
Clasificación de Pruebas
• Pruebas integrales Las pruebas integrales replican el comportamiento de
un usuario con el software en un entorno de aplicación completo. Verifican
que diversos flujos de usuario funcionen según lo previsto. Son costosas
de llevar a cabo y pueden resultar difíciles de mantener cuando están
automatizadas. Se recomienda tener algunas pruebas integrales clave y
depender más de pruebas de menor nivel (unitarias y de integración) para
poder detectar rápidamente nuevos cambios.

• Pruebas de aceptación Las pruebas de aceptación son pruebas formales

que verifican si un sistema satisface los requisitos empresariales.
Requieren que se esté ejecutando toda la aplicación durante las pruebas y
se centran en replicar las conductas de los usuarios. Sin embargo,
también pueden ir más allá y medir el rendimiento del sistema y rechazar
cambios si no se han cumplido determinados objetivos.
Clasificación de Pruebas
• Pruebas de rendimiento Las pruebas de rendimiento evalúan el
rendimiento de un sistema con una carga de trabajo determinada. Ayudan a
medir la fiabilidad, la velocidad, la escalabilidad y la capacidad de respuesta
de una aplicación. Por ejemplo, una prueba de rendimiento puede analizar
los tiempos de respuesta al ejecutar un gran número de solicitudes, o cómo
se comporta el sistema con una cantidad significativa de datos. Puede
localizar cuellos de botella, medir la estabilidad durante los picos de tráfico y
mucho más.

• Pruebas de integración Las pruebas de integración verifican que los

distintos módulos o servicios utilizados por tu aplicación funcionan bien en
conjunto. Por ejemplo, se puede probar la interacción con la base de datos o
asegurarse de que los microservicios funcionan bien en conjunto y según lo
esperado. Estos tipos de pruebas son más costosos de ejecutar, ya que
requieren que varias partes de la aplicación estén en marcha
Clasificación de Pruebas

• Pruebas de humo Las pruebas ● Pruebas de Sanidad se enfocan en

de humo son pruebas básicas verificar una nueva funcionalidad o
que sirven para comprobar el solución a un defecto.
funcionamiento básico de la El subconjunto de casos de prueba que
aplicación. Están concebidas se ejecutan están relacionados con la
para ejecutarse rápidamente, y nueva funcionalidad o defecto.
su objetivo es ofrecerte la
Podemos verlas como un subconjunto
seguridad de que las principales
funciones de tu sistema de las pruebas de regresión.
funcionan según lo previsto.
 Estandar ISO
• Consulte el estándar ISO (ISO/IEC 25010)
• Define 8 características de calidad de un producto de software
1) ADECUACION 8) PORTABILIDAD
FUNCIONAL
CALIDAD DEL PRODUCTO PRUEBAS DE
PRUEBAS
FUNCIONALES SOFTWARE PORTABILIDAD

2) EFICIENCIA DEL 7) MANTEBILIDAD

RENDIMIENTO
PRUEBAS DE
PRUEBAS DE MANTEBILIDAD
RENDIMIENTO

3) COMPATIBILIDAD 4) USABILIDAD 5) FIABILIDAD 6) SEGURIDAD

PRUEBAS DE PRUEBAS DE PRUEBAS DE PRUEBAS DE

COMPATIBILIDAD USABILIDAD FIABILIDAD SEGURIDAD
 Estandar ISO
1) ADECUACION Adecuación Funcional
FUNCIONAL Representa la capacidad del producto software para proporcionar funciones que
satisfacen las necesidades declaradas e implícitas,
PRUEBAS cuando el producto se usa en las condiciones especificadas.
FUNCIONALES
Pruebas funcionales (prueban que hace el producto )

2) EFICIENCIA DEL
RENDIMIENTO Eficiencia de Rendimiento
Esta característica representa el rendimiento relativo a la cantidad de recursos
PRUEBAS DE utilizados bajo determinadas condiciones específicas.
RENDIMIENTO Pruebas de Carga
Pruebas de Rendimiento
Pruebas de Estrés
Pruebas de capacidad

Capacidad del producto para

3) COMPATIBILIDAD Compatibilidad coexistir con otro software
independiente, en un entorno
Capacidad de dos o más sistemas o componentes para intercambiar información común

PRUEBAS DE y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno
COMPATIBILIDAD hardware o software
Capacidad de dos o más
Pruebas de coexistencia sistemas o componentes para
intercambiar información y
Pruebas de Compatibilidad Pruebas de interoperabilidad utilizar la información
intercambiada
Estandar ISO
Capacidad de la interfaz
de usuario de agradar y
4) USABILIDAD satisfacer la interacción
Usabilidad con el usuario.
Capacidad del producto software para ser entendido, aprendido, usado y resultar
PRUEBAS DE atractivo para el usuario, cuando se usa bajo determinadas condiciones.
USABILIDAD Pruebas de usabilidad Capacidad del producto
Pruebas Experiencia usuario que permite que sea
utilizado por usuarios
Pruebas Accesibilidad con determinadas
características y
discapacidades

5) FIABILIDAD Fiabilidad Capacidad del sistema o

Capacidad de un sistema o componente para desempeñar las funciones componente para operar
según lo previsto en
especificadas, cuando se usa bajo unas condiciones y periodo de tiempo presencia de fallos
hardware o software
PRUEBAS DE determinados.
FIABILIDAD
Capacidad del producto
Pruebas de fiabilidad Prueba de Tolerancia a Fallos software para recuperar
los datos directamente
Prueba Capacidad de Recuperación afectados y reestablecer
el estado deseado del
sistema en caso de
interrupción o fallo.

6) SEGURIDAD
Seguridad Capacidad de
protección contra el
Capacidad de protección de la información y los datos estas protegidos de acceso de datos e
información no
PRUEBAS DE manera que personas o sistemas no autorizados no puedan leerlos o autorizados, ya sea
SEGURIDAD modificarlos. accidental o
deliberadamente
Prueba de seguridad Prueba de Confidencialidad
Prueba de Integridad
Capacidad del sistema
o componente para
prevenir accesos o
 Capacidad de un
sistema o programa de
ordenador (compuesto

Estandar ISO
de componentes
discretos) que permite
que un cambio en un
componente tenga un
impacto mínimo en los
demás.

Capacidad de un activo
7) MANTENIBILIDAD Mantenibilidad que permite que sea
utilizado en más de un
Esta característica representa la capacidad del producto software para ser sistema software o en la
modificado efectiva y eficientemente, debido a necesidades evolutivas, construcción de otros
activos.
PRUEBAS DE correctivas o perfectivas.
MANTENIBILIDAD Pruebas Mantenibilidad Pruebas de Modularidad
Pruebas de Reusabilidad Capacidad del producto
Pruebas de capacidad de ser Modificado que permite que sea
modificado de forma
efectiva y eficiente sin
introducir defectos o
degradar el desempeño.

Capacidad del producto

que le permite ser
8) PORTABILIDAD adaptado de forma
efectiva y eficiente a
diferentes entornos
determinados de
hardware, software,
PRUEBAS DE operacionales o de uso.
PORTABILIDAD Portabilidad
Facilidad con la que el
Capacidad del producto o componente de ser transferido de forma efectiva y producto se puede
eficiente de un entorno hardware, software, operacional o de utilización a otro instalar y/o desinstalar de
forma exitosa en un
entorno. determinado entorno.

Pruebas de Portabilidad Pruebas de Adaptabilidad

Pruebas a ser Instalado Capacidad del producto
para ser utilizado en lugar
Pruebas a ser Reemplazado de otro producto software
determinado con el mismo
propósito y en el mismo
entorno
 ISTQB
• En el ISTQB ( International Software Testing Qualifications Board )
• Define unos tipos de prueba en su programa de estudio

Su función es que
ISTQB un defecto haya sido
solucionado

PRUEBAS DE
CONFIRMACION

PRUEBAS
PRUEBAS PRUEBAS NO PRUEBAS DE CAJA
ASOCIADAS A LOS
FUNCIONALES FUNCIONALES BLANCA
CAMBIOS

PRUEBAS DE
Se basan en la REGRESION
Mide que hace el Estas pruebas
estructura interna
sistema miden el como
del sistema , flujos
Consiste en ejecutar todas la pila de casos de
de trabajo
prueba para asegurarnos que con la solución
de un defecto no se haya modificado o
afectado otra funcionalidad
Niveles de pruebas
Pruebas de Aceptación

Pruebas de sistemas

Pruebas de integración

Pruebas de componentes
( Unitarias)
Niveles de pruebas
Antes de pasar a describir los niveles de pruebas
es importante saber que a un mismo nivel de prueba se puede aplicar varios tipos de prueba

Estas pruebas recaen sobre

PRUEBAS de el usuario finales o nuestro
clientes

COMPONENTE INTEGRACION SISTEMAS ACEPTACION

Las pruebas de
Se enfocan en aceptación al igual
componentes que se En la prueba de
Se centran en que las pruebas de
pueden probar por sistema nos
probar las sistema se
separado también centramos en la
iteraciones entre enfocan
llamados pruebas capacidades de
componentes y generalmente en el
unitarias o pruebas todo el sistema o
sistemas. comportamiento y
de módulos producto
capacidades del
sistema o producto

Pruebas Funcionales Pruebas Funcionales Pruebas Funcionales Pruebas Alfa

Pruebas no Funcionales Pruebas no Funcionales Pruebas no Funcionales Pruebas Beta

Pruebas de Rendimiento
Pruebas de Rendimiento Pruebas de Seguridad
Pruebas de Compatibilidad
Pruebas de Seguridad Pruebas de usabilidad
etc
Documento Standard de Pruebas Funcionales
• 16 Tips infaltables de Test para revisión
1. Inputs de texto
2. Inputs numéricos
3. Inputs de fecha
4. Inputs especiales (DNI/CUIT/CUIL)
5. Inputs de moneda (precios $, etc.)
6. Combos o matchcodes
7. Marcas y opciones (option y check)
8. Restricciones de edición
9. Etiquetas
10. Grillas de consulta o resultado
11. Grabación, modificación o eliminación
12. Botones standard
13. Filtros o búsquedas
14. Pantalla (navegabilidad, tabulación y diseño)
15. Accesos directos por teclado (shortcuts)
16. Ayuda en línea (help)
 Selenium
Ventajas Desventajas

• Amplia gama de lenguajes de programación: • Curva de aprendizaje empinada: una página puede tener
Selenium soporta distintos lenguajes de llamadas asíncronas lo que puede ocasionar que si tarda
programación como Java, Ruby, Python, C#, entre mucho en cargar la prueba falle, por lo que se deben tener
otros. amplios conocimientos de programación para poder
manejar los problemas de sincronía.
• Integrado con distintas herramientas de
desarrollo: se puede integrar fácilmente con las
siguientes plataformas: Jenkins, Maven, DevOps, • Sin capacidad de informes: no cuenta con un sistema de
entre otras. generación de informe por lo tanto se deben utilizar
herramientas de terceros.
• Gran comunidad: se estima que unas 56.000
empresas utilizan Selenium. • Configuración del entorno: esta tarea puede tomar un
tiempo considerable, ya que para cada navegador se tiene
un WebDriver distinto y en caso de querer ejecutarla en
• Amplia gama de complementos: se puede ampliar múltiples navegadores requiere mayor configuración.
más allá de su funcionalidad estándar
• Robustez de las pruebas: al desarrollar tus pruebas
puedes ejecutarlas una vez y creer que funcionan, pero
debido a problemas de sincronía pueden fallar la próxima
vez.
Selenium

[Link]
 Selenium
• Paso 1: instalar en chrome selenium IDE
• Paso 2 : entrar en la pagina [Link]
• Paso 3 : iniciar , créate a new Project
• Paso 4 : indicar donde lo guardar el proyecto
• Paso 5 : iniciar acciones
• Paso 6 : detener proyecto
Selenium
PAGINA PULSAR ICONO

CREAR PROYECTO
 Selenium

NOMBRE TEST

GUARDAR

Cargar pagina REG

Selenium

NOS INDICA
QUE YA ESTA
GRABANDO
Selenium
STOP DETENER
pagina GRABACION
 RUN EJECUTAMOS LAS
Selenium PUEBAS GRABADAS
Selenium Resultados del test ejecutado
Testing: Clase 11 – Otros Tipos
de Pruebas

Ciarallo - Jaldin
Julio 2023
Otros Tipos de Pruebas
• Pruebas de regresión

• Pruebas automatizadas

• Pruebas de performance
Pruebas de Regresion
• Para hablar de testing automatizado hablemos primero de pruebas de
regresión.

• Si bien no es para lo único que se utiliza la automatización de pruebas,

tal vez sea la opción más popular y la más usada.

• Las pruebas de regresión son un subconjunto de las pruebas

planificadas que se seleccionan para ejecutar periódicamente, por
ejemplo ante cada nueva liberación del producto. Tienen el objetivo de
verificar que el producto no haya sufrido regresiones.
Pruebas de Regresion
• ¿Por qué se llaman pruebas de regresión? Si los usuarios tienen la
versión N instalada, y le instalamos la N+1, y esta tiene fallos, nos
veremos atormentados al tener que volver a la versión previa, hacer una
regresión a la versión N.

• ¡Queremos evitar esas regresiones!

• Cuando se diseñan las pruebas para determinadas funcionalidades, ya

se definen cuáles son las pruebas que serán consideradas dentro del set
de pruebas de regresión.
Pruebas automatizadas
• El testing automatizado consiste en que una máquina logre ejecutar los
casos de prueba en forma automática, leyendo la especificación.

• Para las pruebas, aunque sean “automáticas” y “ejecutadas por una

máquina”, vamos a necesitar gente capacitada.

• Una herramienta no enseña a tus testers cómo testear, si el testing es

confuso las herramientas refuerzan esa confusión.
Pruebas automatizadas
• Mejora la calidad, pues hay menos errores humanos.

• Mejora la performance de producción, pues con las mismas personas se

puede lograr mucho más trabajo, a mayor velocidad y escala, y en ese
sentido mejoran el rendimiento de las personas.

• Acumulatividad nula: Las features crecen cada vez más a lo largo del
tiempo (de una versión a otra), pero el test no. La empresa a medida que
desarrolla más funcionalidades no contrata más testers.
Pruebas automatizadas
● La automatización es acumulativa. Es la única forma de hacer
que el testing se haga constante (sin que se requieran más
esfuerzos a medida pasa el tiempo y crece el software a probar).

● El desafío es hacer testing en forma eficiente, de forma que nos

rinda, que veamos los resultados, que nos aporte valor, y que
vaya acompañando la acumulatividad del desarrollo.

● Las features crecen cada vez más a lo largo del tiempo (de una
versión a otra), pero el test no (no conozco de ninguna empresa
que a medida que desarrolle más funcionalidades contrate más
testers).
Pruebas automatizadas
Pruebas automatizadas
● El que crea que una herramienta soluciona todos los problemas, tiene un
nuevo problema.

● Las aplicaciones en las que más conviene usar testing automatizado son
en las que será necesario ejecutar muchas veces las pruebas (ya sea
porque es un producto que tendrá muchas versiones, que se continúe con
el mantenimiento haciendo fixes y parches, o porque se debe probar en
distintas plataformas).
Pruebas automatizadas
Paradigmas automatización: Scripting
● Las herramientas brindan un lenguaje en el que se pueden
especificar los casos de prueba como una secuencia de comandos,
que logran ejecutar acciones sobre el sistema bajo pruebas.

● Estos lenguajes pueden ser específicos de las herramientas, como

es el caso del lenguaje Selense de la herramienta Selenium, o
pueden ser una biblioteca o API para un lenguaje de propósito
general como lo es JUnit para Java.
Paradigmas automatización: Scripting
Ejemplo Selenium:
Paradigmas automatización: Scripting
Ejemplo JUnit:
Paradigmas automatización: Record
and playback
[Link]ón: Durante esta fase, un tester interactúa manualmente con la
aplicación o sistema bajo prueba utilizando una herramienta de
grabación. La herramienta registra las acciones realizadas, como hacer
clic en botones, completar formularios o navegar por diferentes páginas.

[Link]ón de scripts: Después de la grabación, la herramienta genera

automáticamente un script de prueba, que es un conjunto de
instrucciones que representan las acciones grabadas. Estos scripts
generalmente están escritos en un lenguaje específico de la herramienta
de automatización utilizada.
Paradigmas automatización: Record
and playback
3. Reproducción: Durante esta fase, el script de prueba generado se
ejecuta automáticamente en la aplicación o sistema bajo prueba sin
la intervención manual del tester. El script reproduce las mismas
acciones que se grabaron durante la fase de grabación.

4. Verificación de resultados: Una vez finalizada la reproducción, se

verifican los resultados obtenidos. Esto implica comparar los
resultados esperados con los resultados reales de la ejecución
automatizada. Cualquier discrepancia o error en la aplicación puede
indicar problemas en el sistema o en la automatización misma.
Paradigmas automatización: TDD
• Test-Driven Development se basa en el ciclo de escribir pruebas
automatizadas antes de escribir el código de producción. Es una técnica
ágil que se enfoca en la calidad del código y en la entrega de software
funcional y confiable.

• Consta de tres pasos repetitivos.

 Paradigmas automatización: TDD
1. Escribir una prueba: Una prueba automatizada que describa la
funcionalidad que se desea agregar al software.
2. Escribir el código mínimo para pasar la prueba: Se escribe la cantidad
mínima de código que sea necesario para que la prueba pase
satisfactoriamente, sin preocuparse por la calidad del código o su diseño.
3. Refactorizar el código: Se mejora el diseño del código y se realizan
cambios para garantizar la legibilidad, la eficiencia y el mantenimiento a
largo plazo.

Luego de completar estos pasos, se vuelve al principio y se repite el ciclo

con nuevas pruebas y nuevas funcionalidades.
TDD: Ventajas
• Mejora de la calidad del código: Al escribir pruebas antes del código de
producción, se asegura que el software funcione correctamente y cumpla
con los requisitos definidos. Además, las pruebas automatizadas permiten
identificar rápidamente cualquier regresión o error en el código.

• Diseño simple y modular: La práctica de escribir pruebas antes de

implementar el código ayuda a enfocarse en la funcionalidad y en el
diseño modular del software. Esto conduce a un código más limpio, más
estructurado y más fácil de mantener.
TDD: Ventajas
• Mayor confianza y seguridad: Las pruebas automatizadas brindan una
capa adicional de confianza al desarrollador y al equipo, ya que permiten
validar continuamente el funcionamiento del software. Esto reduce el
riesgo de introducir errores y facilita la detección temprana de problemas.

• Facilita la colaboración: Al escribir pruebas claras y específicas, se

establece una comunicación efectiva entre los miembros del equipo.
Además, las pruebas sirven como una documentación ejecutable del
comportamiento esperado del software.
 TDD: Ejemplo
1. Escribir una prueba: Se escribe una prueba automatizada que describe el
comportamiento esperado de la función de suma.
 TDD: Ejemplo
2. Ejecutar la prueba y verificar que falle: Al ejecutar la prueba, esperamos
que falle porque aún no hemos implementado la función sum_numbers().

3. Escribir el código mínimo para pasar la prueba: Ahora, escribimos la función

sum_numbers() de manera simple para que la prueba pase:
 TDD: Ejemplo
4. Ejecutar la prueba nuevamente: Al ejecutar la prueba después de escribir
el código de producción, esperamos que pase satisfactoriamente.
5. Refactorizar el código (opcional): Si es necesario, podemos realizar
cambios en el código para mejorarlo, como agregar comentarios, optimizar
el rendimiento o mejorar la legibilidad.
6. El ciclo de TDD se repite para cada nueva funcionalidad o caso de prueba
adicional. Por ejemplo, podríamos agregar una nueva prueba para verificar
el manejo de números negativos:
 TDD: Ejemplo
4. Ejecutar la prueba nuevamente: Al ejecutar la prueba después de escribir
el código de producción, esperamos que pase satisfactoriamente.
5. Refactorizar el código (opcional): Si es necesario, podemos realizar
cambios en el código para mejorarlo, como agregar comentarios, optimizar
el rendimiento o mejorar la legibilidad.
6. El ciclo de TDD se repite para cada nueva funcionalidad o caso de prueba
adicional. Por ejemplo, podríamos agregar una nueva prueba para verificar
el manejo de números negativos:
Pruebas automatizadas: Suites
Conjunto o colección de pruebas automatizadas que se agrupan y se ejecutan
como un conjunto coherente. La organización la podemos definir por distintos
criterios:

• Módulo o Funcionalidad: agrupando todos los casos de prueba que actúan

sobre una misma funcionalidad.

• Criticidad: podríamos definir un grupo de pruebas que se debe ejecutar

siempre (en cada build), ya que son las más críticas, otro de nivel medio,
que lo ejecutamos con menos frecuencia (o tal vez que se seleccionan solo
si hay cambios en determinadas funcionalidades), y uno de poca criticidad,
que ejecutaremos opcionalmente si contamos con tiempo para hacerlo.
Pruebas de performance

• Se ejecutan para medir cómo se comporta una aplicación o sistema en

términos de rendimiento, estabilidad y capacidad de respuesta bajo
diferentes condiciones y cargas de trabajo.

• El objetivo es identificar posibles cuellos de botella, problemas de

rendimiento y debilidades en el sistema, permitiendo a los equipos de
desarrollo y operaciones realizar ajustes y mejoras para optimizar el
rendimiento antes de que el sistema sea puesto en producción o utilizado
por un gran número de usuarios.
Pruebas de performance
Incluyen:

1. Carga de usuarios simulada: Se generan cargas de trabajo simuladas para

simular la actividad de múltiples usuarios concurrentes que interactúan con
la aplicación o sistema.

2. Métricas y objetivos de rendimiento: Se establecen métricas y objetivos

claros para evaluar el rendimiento del sistema. Esto puede incluir tiempos
de respuesta esperados, capacidad de manejo de transacciones, utilización
de recursos (CPU, memoria, ancho de banda).
Pruebas de performance
3. Pruebas de carga: Se aplican cargas de trabajo cada vez mayores al
sistema para evaluar su rendimiento bajo diferentes niveles de estrés y
carga.

4. Pruebas de estrés: Se somete el sistema a condiciones extremas y de

sobrecarga para evaluar su comportamiento y estabilidad bajo presión
máxima.

5. Monitoreo y análisis: Durante las pruebas, se monitorea y se registra el

rendimiento del sistema, incluyendo tiempos de respuesta, recursos
utilizados, errores, entre otros.
 Ejercicio
• Intenta encontrar errores en esta página: [Link]
 Testing: Clase 12 -
Automatización de Pruebas

Ciarallo - Jaldin
Julio 2023
 Pruebas manuales vs Automatizadas
Las pruebas manuales son ejecutadas Las pruebas automatizadas son
directamente por uno o más testers, pruebas que son programadas por
simulando las acciones del usuario desarrolladores o testers por medio de
final,apoyándose de las herramientas scripts y programas, simulando lo que
el usuario hace en el sistema pero
necesarias.
ejecutado automáticamente en un
laptop o un servidor de pruebas.
Pruebas Manuales
Ventajas Desventajas
• Para proyectos cortos son más rápidas. • Se pueden volver una actividad repetitiva y
• Son más flexibles tediosa cuando se trata de proyectos grandes.
• Al ser ejecutadas por un humano pueden
• Cuando el proyecto tiene muchos bugs, las
detectar problemas o bugs no funcionales
repruebas y pruebas de regresión se
que no son detectados por un programa
vuelven muy costosas de ejecutar.
como lo es la usabilidad o la
• En proyectos grandes, la repetición de
navegabilidad o experiencia de usuario.
pruebas manuales puede hacer que el QA
• No requieren de conocimiento técnicos
omita defectos debido al cansancio.
profundos o programación aunque sería
• Poca de usabilidad, cada que se hace un
ideal.
cambio se debe volver a probar todo desde cero.
• Permiten probar escenarios complejos con
secuencias largas de pasos en sistemas
antiguos difíciles de automatizar.
Pruebas Automatizadas
Ventajas Desventajas
• La ejecución de casos es rápido y eficiente. • Automatizar las pruebas requiere una
• Brindan un mayor grado de confiabilidad y inversión de tiempo.
precisión. • Automatizar pruebas requiere de un
• Tienen un mayor ROI, en proyectos conocimiento técnico que algunos QAs
grandes ayudan a reducir costos en principiantes aún no tienen.
pruebas y detección de bugs. • Algunas herramientas de automatización
• Son reusables, se pueden correr una y otra son costosas.
vez en minutos con alto grado de cobertura. • Las pruebas automáticas no proveen un
• Las pruebas se pueden programar para feedback de aspectos del sistema como la
que corran a cualquier momento sin usabilidad.
intervención humana. CI/CD
Como saber cual tipo prueba usar?
Pruebas manuales: Pruebas Automatizadas
• Siempre para cada proyecto hay que hacer • Todas las pruebas de regresión son
pruebas exploratorias manuales para conocer candidatas a automatización.
el sistema y poder empezar a diseñar casos • Toda prueba que se corre constantemente
de prueba. en alguna aplicación y que tome mucho
• Cuando se tienen escenarios complejos en tiempo.
sistemas que requieren pre-condiciones y un • Las pruebas de rendimiento o carga.
grado de análisis complejo. • Pruebas con flujos largos de muchos
• Se recomiendan correr cuando se prueban pasos en sitios web o móvil.
sistemas que no tienen un resultado • Pruebas de APIs
• Pruebas de varios navegadores (Cross
específico o es muy dinámico o variable
Browser Testing)
Automatización de pruebas con Cypress y JavaScript
[Link]
Que es Cypress ?
• Es un framework de testing moderno y todo en uno.
• Es rápido, fácil de usar y permite ejecutar pruebas sobre
cualquier aplicación web.

Cypress te permite crear pruebas automatizadas.

• End to End (E2E)
• Pruebas de Integración
• Pruebas Unitarias
Que vamos a necesitar Instalar
1. Instalar el editor Visual studio code.
[Link]
2. Instalar Node JS [Link]
3. Luego instalamos el manejador de
paquetes NPM
4. Instalar Cypress como dependencia
en el proyecto a probar
[Link]
¿Qué son las pruebas E2E?
Las pruebas End-to-End es una
Mas lentas Mas costosas
metodología de aseguramiento de
calidad de software para probar el
flujo de la aplicación desde el inicio
hasta el final. El objetivo es simular al
máximo el comportamiento de un
usuario real y validar la integridad y
fiabilidad del sistema.
En la pirámide de pruebas, las de Mas rapidas Menos costosas
E2E se sitúan arriba del todo porque
son mucho más costosas que el resto
como unitarias o de integración en
términos de tiempo y el esfuerzo.
 Instalar y ejecutar pruebas en Cypress
Paso 1: Instala Cypress en tu proyecto NPM o en proyecto desde 0
Para completar la instalación tan solo tenemos que agregar una dependencia
a nuestro proyecto NPM (Node Package Manager) o crear uno nuevo.
Si quieres crear un proyecto desde cero, ejecuta los siguientes comandos:
npm init -y
npm install cypress –D

Paso 2 : Arranca Cypress ejecutando

Una vez hecho esto, estamos listos para arrancar Cypress y verlo en acción
npx cypress open

Paso 3: Arranca Cypress con grabación ejecutando

npx cypress run
 Instalar y ejecutar pruebas en Cypress

Paso 4: ejecuta tu primer test

Para ejecutar un test, pulsa sobre cualquier fichero que nos ha creado
Cypress en la carpeta 2-advanced-examples.
Esto hará que se abra navegador y se ejecuten las pruebas.
Cypress
Cypress
Cypress
Cypress
Cypress
Cypress
La primera parte de la prueba “describe” define el banco de pruebas,
puede ser el nombre de la pantalla o el caso de uso que engloba las pruebas.
Luego tenemos los “it” que serían cada una de las pruebas que se quieren
desarrollar.

describe( "nombre de pruebas ", function() {

/*--------prueba 1------------ */
it (" Descripción de prueba 1 " , function () {
[Link](" [Link] " )
[Link]( "selector " ) .should ( "tipo de validación " )
//comandos a ejecutar
});
/*--------prueba 2------------ */
it ( 'Descripción de prueba 2‘ , function () {
//comandos a ejecutar
});
})
Herramientas de pruebas de carga y
rendimiento

El objetivo de estas herramientas es simular situaciones límite en

los sistemas y estudiar la respuesta de los mismos.

Muchos sistemas que trabajan en tiempo real requieren este tipo de

pruebas, donde se probará hasta dónde es capaz de llegar el
sistema antes de sobrecargarse.

Estos sistemas en tiempo real como pueden ser, sistemas

cliente/servidor o aplicaciones web, tienen que cumplir un tiempo
de respuesta
JMeter

Jmeter (libre): es una herramienta de pruebas de carga para

analizar y medir el desempeño de una variedad de servicios,
con énfasis en aplicaciones web. Es una de las herramientas
más utilizadas para las pruebas de rendimiento.

[Link]

[Link]
 JMeter
Uno de los requisitos previos para instalar Apache JMeter es Java.
¿Cómo verificar la instalación de Java en su sistema?
1. Ejecute cmd desde el símbolo del sistema e ingrese "java -version". Si tiene
Java instalado, le mostrará la versión más reciente.
2. Descarcar Jmeter [Link]
 3 Crear carpeta en escritorio

JMeter
Hacer una carpeta en escritorio
Ir a descargas y copiar [Link] y descomprimir

5 entrar a carpeta bin 6 Doble click para ejecutar

4 Entrar a carpeta
JMeter
 JMeter
• Plan de prueba : cuantos usuarios soporta un sitio web
• Ejemplo : [Link]
Recordar protocolo

Seleccionamos
Valores por defecto
para indicar en que
sitio web vamos a
trabajar
JMeter
Configuro con que página web vamos a trabajar

[Link]
Se creo espacio https
de trabajo
JMeter
Seguimos configurando

Creamos un grupo de Hilos

Se creo grupo de hilos

Caso base : comenzamos 1
Y vamos incrementando su
valor
 JMeter: Ejemplo
Probamos con un elemento de [Link]

Luego overview

Nos redirige a otro sitio web 🡪 [Link]

JMeter: Ejemplo

Le voy a decir que vamos a

hacer peticiones a esta pagina
[Link]
JMeter: Ejemplo

Se creo petición cargamos a la ruta /foundation/

JMeter: Ejemplo
• Incorporamos informe donde pueda ver cuál es el resultado del test

Creo árbol de
resultados
JMeter: Ejemplo

Creo reporte
resumen

Verifico que se crearon

Árbol de resultado
Reporte resumen
JMeter: Ejemplo
Run corremos el
programa

Obs : Nos va a pedir que

guardemos antes el [Link]
JMeter: Ejemplo
JMeter: Ejemplo Limpiar todo

Escala en mili segundos

JMeter: Ejemplo
Hay que tener en cuenta los requerimientos que nos están pidiendo testear.

Hay páginas que nos van a bloquear ya que no estamos autorizados a

testear y tienen su nivel de seguridad.

Las pruebas van a depender del flujo de entradas estándar en que el

negocio se manejen el cliente.