Software Testing
Avanzado
Eleva tus habilidades en pruebas a otro nivel
MÓDULOS
01 Introducción al curso
02 Explicación del proyecto y planeación
de sprints en JIRA
03 Early Testing y shift-left
04 Define la estrategia de pruebas como
un Lider de pruebas
05 Diseño con tecnicas avanzadas y
ejecución de pruebas ágiles
06 Pruebas de Performance con Jmeter y
Blazemeter
Sección 2 - Explicación del proyecto,
organización equipos y planeación en JIRA
Explicación del proyecto a MÓDULO
desarrollar - GeekStore
La empresa Geek Enterprise solicita desarrollar una tienda de comercio
electrónico llamado GeeKStore donde los visitantes puedan buscar y
comprar artículos de tecnología.
Requerimientos generales
✓ Geek Enterprise quiere tener una primera versión funcional de
la aplicación web en 15 días y luego se van adicionando
nuevas funcionalidades de manera incremental en las
siguientes semanas.
✓ Reporte diario de las novedades del proyecto.
✓ Prueba de aceptación antes de hacer el reléase a producción.
✓ Entrega un producto de calidad donde los usuarios tengan
una gran experiencia online
✓ El sitio sea usable, accesible, seguro
✓ El sitio se pueda visualizar perfectamente en
dispositivos móviles.
Requierimientos especificos- MÓDULO
GeekStore
Que model de trabajo debemos usar
para desarrollar este Proyecto?
Modelo Desarrollo “Scrum”
Ventajas de Scrum
•Flexibilidad y adaptación a un
mercado cambiante.
•Resultados anticipados
•Obtención de un producto mínimo
viable (MVP) ...
•Feedbacks rápidos y precisos. ...
•Fecha de entrega de proyecto
realista. ...
•Rápido aprendizaje del equipo. ...
•Autonomía y responsabilidad.
Fuente: [Link]
Organización de equipos ágiles MÓDULO
– Astro Tech (alternativa 1)
Desarrollo web Mobile apps
Team Beta (back end)
Team Alpha (Front)
Team Omega Team Sigma
Gerente Técnico
3 Devs 4 Devs
1 QA 1 QA
1 BA 1 Senior QA (Lead) 2 Devs 2 Devs
1 UX 1 BA 2 QA 2 QA
1 BA 1 BA
1 Scrum Master
1 Scrum Master
1 Producto Owner
1 Producto Owner
Organización de equipos ágiles – MÓDULO
Astro Tech (alternativa 2)
Desarrollo web Mobile apps
Team Beta Team Gamma
Team Alpha
Team Omega Team Sigma
3 Devs 2 Devs
1 QA 3 Devs
1 Senior QA 1 QA
1 BA 2 Devs 2 Devs
1 BA 1 BA
1 UX 2 QA 2 QA
1 BA 1 BA
1 Scrum Master
1 Scrum Master
1 Producto Owner
1 Producto Owner
Organización de equipos ágiles – MÓDULO
Astro Tech (alternativa 3)
Desarrollo web Mobile apps
Team Alpha
Team Omega Team Sigma
6 Devs
3 QA (2 QAs + 1 Lead)
1 BA 2 Devs 2 Devs
1 UX 2 QA 2 QA
1 BA 1 BA
1 Scrum Master
1 Scrum Master
1 Producto Owner
1 Producto Owner
Responsabilidades del MÓDULO 1
LECCIÓN # 2
Test Lead en equipos Agiles
Apoya el “triaging” de los bugs
encontrados dentro del sprint
Coordina con los usuarios finales las
Hace “pair reviews” de casos de 6 pruebas de UTA
prueba de otros testers 5 7
Es mentor de otros testers dentro Ejecuta pruebas, reporta bugs y
del equipo 4 trabaja de cerca con devs y todos los
8 testers
Provee asistencia técnica a los
testers que trabajan en el mismo Test lead Revisa código de pruebas y aprueba
producto
3 9 los “pull requests”
Guía al equipo a construir
Ayuda con las entrevistas
calidad en todas las fases de 2 10 técnicas de otros Testers
SDLC
Diseña el plan de pruebas y lidera 1 11 Monitorea el proceso de pruebas y las
estrategia de automatización.
métricas de calidad
Errores comunes en organización y MÓDULO
planeación del sprint
Tu como líder de pruebas, debes ayuda a tu equipo ágil a evitar estos errores:
▪ Testing se deja para el final del sprint.
▪ Las pruebas son solo para los Testers del equipo
▪ Se tiene un equipo de pruebas separado de los desarrolladores
▪ Desarrollemos en el primer sprint y probamos en el segundo
▪ Testers que son compartidos en varios equipos trabajando en paralelo
▪ Testers esperando a que los programadores terminen de desarrollar la historia
▪ Testers que se creen dueños de la calidad y no dejan que nadie ayude.
▪ Testers que rotan de equipo durante el sprint.
Sección3- Técnicas
de prevención
mediante Early
Testing y shift-left
MÓDULO 1
Pruebas estáticas vs Pruebas dinámicas
Pruebas Estaticas Pruebas Dinamicas
No requiren ejecución de Se realizan mientras el codigo
software para ser realizadas. esta en ejecución. Su objetivo es
Su objetivo es la prevencion asegurar que el software se
y deteccion temprana de comporte de acuerdo a los
defectos requerimientos
Revision de historias, criterios
de aceptación, planes de Revision de aspectos
prueba, código no compilado funcionales y no funcionales de
etc la aplicación.
Pruebas estáticas de historias MÓDULO 1
Usando técnica INVEST
[Link]
Pruebas estáticas de historias MÓDULO 1
Usando técnica INVEST
Ejemplo historia no VALIOSA
No valiosa Valiosa
Como cliente Como cliente
Quiero poder descargar los comentarios hechos de quiero leer revisiones o criticas de un articulo
los productos para decidir si lo compro o no
Para verlos cuando este offline
Pruebas estáticas de historias MÓDULO 1
Usando técnica INVEST
Ejemplo historia no ESTIMABLE
No ESTIMABLE Estimable
Como cliente Como cliente
Quiero generar informes de mis productos Quiero generar informes de ordenes de mis
Para poder controlar mi gasto productos con fecha y valor
Para poder controlar mi gasto en la tienda
Pruebas estáticas de historias MÓDULO 1
Usando técnica INVEST
Ejemplo historia no Testeable (Comprobable)
No Testeable Testeable
Como cliente Como cliente
Quiero que el pago sea rápido Quiero que el pago de artículos en el checkout
Para poder obtener el numero de mi orden al instante se demore menos de 5 segundos
Para no perder el interés en la compra.
Definición de listo. - DoR
Definicion de Listo (Definition of Ready)
La historia cumple con la técnica INVEST. SI
La historia tiene definidos todos los criterios de aceptación SI
La historia esta estimada por el equipo SI
Todos los prototipos están detallados SI
La historia es alcanzable dentro de un sprint SI
La historia no tiene dependancias SI
[Link]
El gran problema en el desarrollo de
software hoy en día….
Ejemplo del culumpio en el arbol…
BDD : Resuelve el problema de falta de comunicación entre el usuario, Producto
Owners,Bas, programadores , testers y el equipo en general.
Como la metodología BDD ayuda en
la calidad del software?
BDD (Behavior Driven Development), es una estrategia de desarrollo dirigido por comportamiento que
el usuario espera cuando usa el sistema.
La principal ventaja es que todas las
definiciones BDD se escriben en un idioma
común.
El principal objetivo es que el equipo
describa los detalles de cómo se debe
comportar la aplicación a desarrollar, y de
esta forma será comprensible por todos.
Escenarios BDD en lenguaje Gherkin
aplicado a criterios de aceptación
Gherkin: es un lenguaje no técnico que puede ser leído por cualquier persona (como lenguaje natural) y que
nos permite expresar comportamientos
Escribamos los criterios de aceptación usando BDD en formato
Gherkin
Given ‘dado’: Se especifica el escenario, las precondiciones.
•When ‘cuando’: Las condiciones de las acciones que se van a ejecutar.
•Then ‘entonces’: El resultado esperado, las validaciones a realizar.
Un ejemplo práctico de un criterio de aceptación en BDD sería:
•Given: Dado que el usuario no ha introducido ningún dato en el
formulario.
•When: Cuando hace clic en el botón Enviar.
•Then: Se deben mostrar los mensajes de validación apropiados.
Que preguntarse cuando vamos a MÓDULO
crear un plan de pruebas agil?
Tu como líder de pruebas, debes ayuda a tu equipo ágil a definir
▪ Cuales es la ruta critica del Sistema que debe funcionar si o si. Analisis de riesgos
▪ Que tests deberian ser automatizados y en que herramienta (Piramide de pruebas)
▪ Que pruebas deberian hacerse manualmente debido a complejidad y tiempo
▪ Donde se cree que se van a encontrar mas errores
▪ Que pruebas se pueden hacer con pruebas de exploración?
▪ Que esta en el alcance de la prueba y que no
▪ Dependencias.
Sección3- Define la
estrategia de
pruebas como un
Lider de pruebas
Desarrollo y pruebas en paralelo MÓDULO
en el sprint
Team Alpha (Front) Team Beta (back end)
3 Devs 4 Devs
1 QA 1 QA
1 BA 1 Senior QA (Lead)
1 UX 1 BA
Despliegue de la primera versión en ambiente: TESTING
[Link]
Pruebas exploratorias en entorno MÓDULO 2
ágil
Las pruebas exploratorias son una estrategia de pruebas de software que suelen describirse como
aprendizaje simultáneo, diseño de prueba y ejecución. Se centran en la detección y dependen de que el
tester descubra defectos que no es fácil cubrir con otras pruebas.
Caracteristicas
✓ Se explora la aplicación basada en conocimientos previos de aplicaciones
similares.
✓ Preferiblemente ejecutadas por Senior Tester o Test Lead.
✓ Son pruebas aleatorias y libres sin una secuencia determinada
✓ Se realizan casos de prueba durante la ejecución.
✓ Se aprende de la aplicación mientras se va ejecutando casos.
✓ El tester puede convertir sesiones de pruebas exploratorias en scripts de
pruebas funcionales.
✓ Se realiza mediante el uso de sesiones de prueba con diferentes herramientas
✓ El control lo tiene la imaginación del Tester.
✓ Todos el quipo puede apoyar con las pruebas exploratorias
✓ Permite a los equipos a reaccionar y adaptarse a los cambios rápidamente
Estrategia de pruebas moderna
en el sprint
Desplieque Despliegue
cambios al a pre-produccion
ambiente
pruebas
Inicio Sprint Fin sprint
• Smoke tests
• Desarrollo
• Pruebas exploratorias • • Pruebas Post
• Early Testing • Pruebas unitarias Pruebas de
• Pruebas basadas en requisitos
• Refinamiento de • Peer reviews • Pruebas de integración
performance go live
historias, (3 • Analisis estatico código • API Testing • Pruebas de • Monitoreo
Amigos) • Code scanning • Test automation UI seguridad
• Pruebas estáticas CodeQL/SonnarQ • Pruebas continuas en pipelines • Sprint review
• Pruebas de cross-browser • Pruebas de
HU • Aprobación Pull
• Todo el equipo prueba
• BDD requests aceptación UAT
• Bug fixes y retesting
• DoR checklist • Diseño de casos • Pruebas de regression
• Creacion de test data • DoD checklist
• Preparacion ambiente
--- Enfoque Shift-left
MÓDULO 2
Shift Left
MÓDULO 2
Piramide de automatizacion
Unit Testing
WHY: To ensure code is developed correctly
WHO: Developers / Technical Architects
WHAT: All new code + re-factoring of legacy code as well as Javascript
unit Testing
WHEN: As soon as new code is written
WHERE: Local Dev + CI (part of the build)
HOW: Automated, Junit, TestNG, PHPUnit
API / Service Testing
WHY: To ensure communication between components are working
WHO: Developers / Technical Architects
WHAT: New web services, components, controllers, etc
WHEN: As soon as new API is developed and ready
WHERE: Local Dev + CI (part of the build)
HOW: Automated, Soap UI, Rest Client
UI tests
WHY: To ensure customer’s expectations are met
WHO: Developer / SDET / Manual QA
WHAT: Verifying acceptance tests on the stories, verification of features
WHEN: When the feature is ready and unit tested
WHERE: CI / Test Environment
HOW: Automated (Cucumber)Specflow Webdriver
Sección 5 Diseño
con tecnicas
avanzadas y
ejecución de
pruebas ágiles
Tecnica Partición de Equivalencia
Tecnicas avanzadas de caja Negra: MÓDULO
Tablas de desición
Criterio aceptación 1,2,3
Entradas Caso 1 Caso2 Caso3 Caso 4
Procesador Intel AMD Intel AMD
OS Linux Linux Win Win
Salida: 5% 10% No No
Descuento a
aplicar
Tecnicas avanzadas de caja Negra: MÓDULO
Partición de quivalencias
Criterio aceptación 6
[4 - 16]
Memoria RAM Resultado Casos de
(GB) esperado prueba
Partición valida 4-16 No mostrar error 7
Partición invalida • Menores que 4 Mostrar mensaje de 1
• Mayores que 16 error
35
Criterio aceptación: 4,5
[4 -8 , 9 -16]
Memoria RAM Resultado Casos de
(GB) esperado prueba
Partición valida 4-8 + $50 USD 6
9-16 +$150 USD 11
Partición invalida • Menor que 4 • Mensaje de error • 2
• Mayores que 16 • Mensaje de error • 23
Tecnicas avanzadas de caja Negra: MÓDULO
Valores frontera
3 [4 - 16] 17
Memoria Resultado Casos
RAM (GB) esperado de
prueba
Valores 4-16 Adicionar 3,4
frontera extra costo
(partición
valida)
Valores 3,17 Mostrar 16,17
frontera mensaje
(partición de error
invalida)
Administración de pruebas en JIRA
Como hacer efectivamente pruebas MÓDULO 2
exploratorias (Basada en Sesiones )
1. Durante la sesión de pruebas
✓ Después de la sesión:
2. Tener claro cual es la misión de nuestra prueba de
1. Consultar con el PO o BAs los
exploración. (Una historia de usuario, una funcionalidad hallazgos.
E2E, un aspecto especifico de nuestra aplicación etc.) 2. Definir cuales son bugs que deben
ser reportados y crear el reporte
3. Empezar una sesión de exploración y ponerle un limite correspondiente en JIRA (triage)
por ejemplo 30 minutos. Probar sin interrupciones y 3. Adjuntar los resultados a la historia
enfocado en encontrar bugs. de usuario
4. Tomar notas de lo probado y los resultados. 4. Revisar las sesiones de prueba para
5. Describir claramente los bugs con foto de la pantalla
futuras pruebas de regresión o
con los pasos y datos de prueba dentro de la
herramienta.
diseño de futuros casos de prueba.
6. Si algo no esta claro, documentar las preguntas y
adjuntar las fotos de la pantalla.
Cuando usar esta estrategia y MÓDULO 2
beneficios
Se recomienda usarla :
✓ Cuando hay muy poca documentación o es ✓ Beneficios:
nula 1. Entrega feedback rápidamente
✓ Cuando el equipo tiene muy poco tiempo 2. Tomar decisiones en tiempo real
dentro del sprint 3. Se puede llegar donde la automatización
✓ Cuando hay historias de usuario incompletas no puede llegar
✓ Cuando se quiere aprender rápidamente del 4. Entrega resultados en un menor tiempo
producto
✓ Cuando se desea aumentar la cobertura del
producto.
✓ Cuando hay requerimientos cambiantes
frecuentemente (contextos agiles)
Sección6:
Performance Testing
Introducción a las pruebas de MÓDULO 2
Performance
Las pruebas de performance permiten estudiar el desempeño de un sistema, cuando el
mismo se enfrenta a escenarios de carga y estrés similares a los que pueden suceder en
producción. El objetivo de las pruebas de performance es evaluar:
• Velocidad: determina si la aplicación responde rapidamente
• Escalabilidad: determina la carga máxima de usuarios que la aplicación puede gestionar
• Estabilidad: determina si la aplicación es estable bajo cargas variables
Por que hacer pruebas de
performance?
Algunas preguntas que podemos hacernos relacionadas con: Cuándo y
Por qué hacer pruebas de performance?
● La aplicación podrá responder adecuadamente a la carga?
● ¿Cuántos usuarios podrá soportar el sistema antes de dejar de
responder?
● ¿Qué tan rápido se recupera la aplicación luego de un pico de carga?
● ¿Cómo afecta a los usuarios la ejecución de determinado proceso?
● ¿Cuáles son los cuellos de botella del sistema?
● ¿Cómo cambia la performance del sistema al tener un gran volumen de
datos?
● ¿Qué configuración es óptima para la operativa diaria?
● ¿Será la aplicación capaz de responder adecuadamente ese día en que
tendrá
mucha mayor carga que lo habitual?
MÓDULO 2
Tipos de pruebas de performance
Pruebas de carga Pruebas de Estrés Pruebas de picos
Se centran en la capacidad de Se centran en la capacidad de Son similares a las pruebas de
un sistema un sistema estrés, pero se realizan en
para manejar niveles crecientes o componente para manejar periodos cortos de tiempo
de cargas resultantes de las cargas máximas que están en simulando importantes cambios de
solicitudes de o más allá de los carga en un momento dado.
transacciones generadas por un límites de sus cargas de Permite conocer el
número controlado de usuarios o trabajo previstas o comportamiento del sistema
procesos especificadas. cuando existe un pico de uso del
Simultáneos mismo y evaluar si luego de este,
el sistema es capaz de retornar a
un estado estable.
.
Recomendaciones iniciales MÓDULO 6
1. Sugiero realiza el curso en el orden establecido
2. Completa los quices y actividades de cada sección.
3. Puedes acelerar la velocidad de las clases y dejar notas.
4. Si la clase se ve borrosa , puedes cambiar la resolución.
5. Puedes desactivar los subtitulos.
6. No olvides descargar todo el material de cada sección,
scripts, PDFs y los bonos extras que están al final.
7. Sugiero dejar la calificación cuando hayas visto la
mayoría de las clases.
Happy Testing
Tu calificación es muy importante! MÓDULO 6
