Capacitacion - Academia Hitts QA PDF

Academia Hitts
Plan de Nivelación QA
11/03/2019
Profesor
Cristian Adrian Barrientos:

He trabajado en el área de IT desde 1995.
Me especialice en arquitecturas.
Performance Testing.
Gestión de proyectos.
Siempre con la cultura de trabajo en equipo , cooperativo, comunicativo y proactivo.
Agenda
1. Introducción al Curso 9:30 - 11:30

2. Break 11.30 - 11:45
3. Curso 11:45 - 13:00
4. Almuerzo 13.00 - 14:00
5. Curso 14:00 - 17:30
Introducción
En este plan de nivelación de QA , vamos a introducirnos en el proceso de Testing , su concepto, sus objetivos, su
importancia dentro del ciclo de vida en el desarrollo de software.
Conoceremos los distintos tipos de testing, manual , automatizado, funcional y técnico.
Aprenderemos que es un error , como informarlo y clasificarlo según su nivel de impacto.
Transitaremos el proceso del testing , desde la planificación de las pruebas hasta su ejecución y posterior reporte.
Casos de prueba , que son? , para que sirven?, como definirlos ?, como ejecutarlos ?, aplicarlos al estado funcional del
desarrollo software.
Desarrollar testing automatizado, cuando? , por qué? , costo de su diseño vs implementación.
Testing Performance, conceptos alcances , objetivos , planificacion y ejecucion, análisis y resultados.

Software Testing
Definition:
● De acuerdo con la norma ANSI / IEEE 1059: es un proceso de análisis de un elemento de software para detectar las
diferencias entre las condiciones existentes y las requeridas (es decir, defectos) y para evaluar las características
del elemento de software.
● La prueba de software es un proceso, para evaluar la funcionalidad de una aplicación de software con la intención
de determinar si el software desarrollado cumplió con los requisitos especificados o no e identificar los defectos
para garantizar que el producto esté libre de defectos para producir un producto de calidad.
Value of Testing:
● deriva de la calidad, el precio y el tiempo que se ahorran al lanzar productos superiores a clientes satisfechos.
Technical Skills:
● habilidades y conocimientos necesarios para realizar tareas específicas. Se relacionan con tareas mecánicas, de
tecnología de la información, matemáticas o científicas. Incluyen el conocimiento de lenguajes de programación.
Software Testing
Non-Technical Skills:
● La capacidad de comunicación clara y precisa, trabajo en equipo, creativo, flexible, empatía, son algunos de los
requisitos para las tareas testing.
Fundamental Principles of Testing:
● Pruebas exhaustivas: no son posibles, por tal motivo necesitamos ejecutar pruebas que optimicen la evaluacion de
riesgos de la aplicacion:
● Defect Clustering: indica que un pequeño número de módulos contiene la mayoría de los defectos detectados.
Esta es la aplicación del principio de Pareto a las pruebas de software: aproximadamente el 80% de los problemas
se encuentran en el 20% de los módulos.
● Pesticide Paradox: hace referencia al uso de pesticidas y su posterior resistencia si se aplica siempre el mismo
componente. En testing seria ir modificando o agregando nuevos casos de prueba para encontrar errores.
● Testing shows a presence of defects:las pruebas hablan de la presencia de defectos y no hablan de la ausencia de
defectos. es decir, las pruebas de software reducen la probabilidad de que queden defectos no descubiertos en el
software, pero incluso si no se encuentran defectos, no es una prueba de corrección.
Software Testing
● Absence of Error - fallacy:Es posible que el software que está libre de errores en un 99% sea aún inutilizable. Este
puede ser el caso si el sistema se prueba a fondo por un requisito incorrecto. La prueba de software no es solo
encontrar defectos, sino también verificar que el software cubra las necesidades comerciales. La ausencia de error
es una falacia, es decir, encontrar y corregir defectos no ayuda si la compilación del sistema es inutilizable y no
cumple con los requisitos y necesidades del usuario.
● Early Testing:las pruebas deben comenzar lo antes posible en el ciclo de vida del desarrollo de software. Para que
cualquier defecto en los requisitos o en la fase de diseño se capture en las primeras etapas. Es mucho más barato
reparar un defecto en las primeras etapas de las pruebas. ¿Pero qué tan temprano uno debería comenzar a probar?
Se recomienda que comience a encontrar el error en el momento en que se definan los requisitos.
● Testing is context dependent:significa que la forma en que prueba un sitio de comercio electrónico será diferente
de la forma en que prueba un anuncio comercial de la aplicación. Todos los programas desarrollados no son
idénticos. Puede utilizar un enfoque, metodologías, técnicas y tipos de pruebas diferentes según el tipo de
aplicación. Por ejemplo, las pruebas, cualquier sistema de punto de venta en una tienda minorista será diferente a
la prueba de un cajero automático.
Software Testing
Software Testing Life Cycle
● Es el proceso de prueba que se ejecuta de manera sistemática y planificada.

Software Testing
● Requeriments Analisys:En este paso, el equipo de control de calidad (QA) entiende el requisito en términos de lo
que probaremos y resolveremos los requisitos verificables. Si hay algún conflicto, falta o no se comprende algún
requisito, entonces el equipo de control de calidad hace un seguimiento con los diferentes interesados como
Business Analyst, System Architecture, Client, Technical Manager / Lead, etc., Los requisitos pueden ser
funcionales o no funcionales, como rendimiento, pruebas de seguridad. También el requisito y la viabilidad de
automatización del proyecto se pueden hacer en esta etapa (si corresponde)
● Test Planning:En esta fase, generalmente, es el Lider o Gerente de Pruebas los que participan para determinar el
esfuerzo y las estimaciones de costos para todo el proyecto. Esta fase se iniciará una vez que se complete la fase
de recopilación de requisitos y, en función del análisis de requisitos, comience a preparar el plan de prueba. El
resultado de la fase de planificación de la prueba será el plan de prueba o la estrategia de prueba y los
documentos de estimación del esfuerzo de prueba. Una vez que se completa la fase de planificación de pruebas, el
equipo de control de calidad puede comenzar con la actividad de desarrollo de casos de prueba.
● Test Environment Setup:La configuración del entorno de prueba es una parte vital del STLC. Básicamente, el
entorno de prueba decide en qué condiciones se prueba el software. Esta es una actividad independiente y se
puede iniciar en paralelo con el desarrollo de casos de prueba.
Software Testing
● Test Execution:En esta fase, el equipo de pruebas comienza a ejecutar los casos de prueba según la planificación
de prueba preparada y los casos de prueba preparados en el paso anterior, luego de ejecutarse se puede marcar
como aprobado. Si algún caso de prueba falla, el defecto correspondiente puede informarse al equipo de
desarrolladores a través del sistema de seguimiento de errores y el error puede vincularse para el caso de prueba
correspondiente para su posterior análisis.Una vez que el equipo de desarrollo corrige el error, se puede ejecutar
el mismo caso de prueba según la planificación de la prueba.podemos obtener el informe según la cantidad de
casos de prueba aprobados, fallidos, bloqueados o no ejecutados, etc. Una vez que se solucionen los defectos, Los
mismos casos de prueba Fallidos o Bloqueados pueden ejecutarse nuevamente para volver a probar la
funcionalidad.
● Test Cycle Closure: el equipo de QA evaluara los criterios de finalización del ciclo según la cobertura de la Prueba,
la Calidad, el Costo, el Tiempo, los Objetivos de Negocios Críticos y el Software. Discuta qué fue lo que salió bien,
qué área necesita mejorar y tomando las lecciones del STLC actual como información para los próximos ciclos de
prueba, lo que ayudará a mejorar el cuello de botella en el proceso de STLC. Una vez completado el ciclo de
prueba, se prepararán el informe de cierre de prueba y las métricas de prueba. Análisis de resultados de prueba
para averiguar la distribución de defectos por tipo y gravedad.
Software Testing
SDLC VS STLC
● Objetivo El objetivo principal del ciclo de vida de SDLC es completar el desarrollo exitoso del software, incluidas
las pruebas y otras fases. El único objetivo de la fase STLC es la prueba.
● Recopilación de requisitos En SDLC, el analista de negocios recopila los requisitos y crea un plan de desarrollo. En
STLC, el equipo de control de calidad analiza los documentos de requisitos, como los documentos funcionales y no
funcionales, y crea un plan de prueba del sistema.
● Diseño de alto y bajo nivel En SDLC, el equipo de desarrollo crea los planes de diseño de alto y bajo nivel En STLC,
el analista de pruebas crea el Plan de prueba de integración
● Codificación El código real se desarrolla y el trabajo real se lleva a cabo según los documentos de diseño. El equipo
de pruebas prepara el entorno de prueba y los ejecuta.
● La fase de mantenimiento de SDLC también incluye actualizaciones y soportes posteriores a la implementación.
Los evaluadores ejecutan tareas de regresión, generalmente scripts de automatización para verificar el código de
mantenimiento implementado.
Software Testing
Waterfall Model
● El modelo de cascada fue el primer modelo de proceso que se introdujo. Es muy simple de
entender y usar. En un modelo de cascada, cada fase debe completarse antes de que la
siguiente fase pueda comenzar y no haya superposición en las fases. El modelo de cascada es
el primer enfoque SDLC que se utilizó para el desarrollo de software.
Software Testing
V-Model
● El modelo V es una extensión del modelo de cascada. A diferencia del modelo de cascada, en
el modelo V, hay una fase de prueba correspondiente para cada fase de desarrollo de software.
La prueba en el modelo V se realiza en paralelo a la etapa SDLC.La prueba se realiza como un
subproyecto de SDLC.
Test Cases Design Techniques
Test Scenario
● Se define como cualquier funcionalidad que se pueda probar. Como evaluador, puede ponerse
en el lugar del usuario final y descubrir los escenarios reales y los casos de uso de la Aplicación
bajo prueba.
● Los Escenarios de prueba pueden ser aprobados por varias partes interesadas como Business
Analyst, Desarrolladores, Clientes para garantizar que la Aplicación bajo prueba se haya probado
exhaustivamente. Asegura que el software funciona para los casos de uso más comunes.
● Pasos a tener en cuenta al crear Test Scenario:
1. Lea los documentos de requisitos del sistema bajo prueba (SUT). También puede consultar
casos de uso, libros, manuales, etc. de la aplicación que se va a probar.
2. Para cada requisito, determine las posibles acciones y objetivos de los usuarios. Determinar los
aspectos técnicos del requerimiento. Determine posibles escenarios de abuso del sistema.
3. Después de leer el Documento de requisitos y hacer el análisis correspondiente, haga una lista
de los diferentes escenarios de prueba que verifican cada característica del software.
Test Scenario
4.Una vez que haya enumerado todos los escenarios de prueba posibles, se crea una Matriz de Trazabilidad
para verificar que cada requisito tenga un Escenario de prueba correspondiente.
5.supervisor revisa los escenarios creados. Más tarde, también son revisados por otras partes interesadas en
el proyecto.
Por ejemplo en un formulario de Login podriamos identificar los siguientes escenarios de prueba:
1-Verifique el comportamiento del sistema cuando se ingrese una identificación de correo electrónico y una
contraseña válidas.
2-Verifique el comportamiento del sistema cuando se ingrese una identificación de correo electrónico no
válida y una contraseña válida.
Test Case Specifications
● la especificación de caso de prueba es un documento que entrega un resumen detallado de los

escenarios que se probarán en un software durante el ciclo de vida de prueba del software (STLC). Este
documento especifica el objetivo principal de una prueba específica e identifica las entradas requeridas,
así como los resultados / salidas esperados. Además, actúa como una guía para ejecutar el
procedimiento de prueba y describe los criterios de aprobación y rechazo para determinar la
aceptación.
Test Basis Documents/System Requirement Specification (SRS)
● Es el proceso de examinar los artefactos de prueba para basar sus condiciones de prueba / casos de
prueba. Por lo tanto, también se llama Base de prueba.La fuente de la que deriva la información de la
prueba podría ser:
○ SRS (Especificación de requisitos de software)
○ BRS (especificación de requisitos empresariales)
○ Documentos de Diseño Funcional
● Los Testers pueden crear condiciones de prueba al examinar la aplicación bajo prueba o usar su
experiencia. Pero en su mayoría, los casos de prueba se derivan de artefactos de prueba.
Hight Level Document
El diseño de alto nivel (HLD) explica la arquitectura que se usara para desarrollar un producto de
software. El diagrama de arquitectura proporciona una visión general de todo un sistema, identificando
los componentes principales que se desarrollarían para el producto y sus interfaces. El HLD utiliza
posiblemente términos no técnicos o ligeramente técnicos que deberían ser comprensibles para el
tester.
Test Basis Documents/Detail Design Document
● Un documento de diseño de alto nivel (HLDD) describe la arquitectura utilizada en el desarrollo de un

producto de software en particular. Por lo general, incluye un diagrama que representa la estructura
prevista del sistema de software. Como se trata de un documento de alto nivel, a menudo se utiliza un
lenguaje no técnico.
Defects
Definition
● Un error/defect es la consecuencia / resultado de una falla de codificación.
Defects Lifes Cycle
● Discovery
○ En la fase de descubrimiento, los testers del proyecto tienen que descubrir tantos defectos
como sea posible, antes de que el cliente final pueda descubrirlo. Se dice que se descubrió
un defecto y que se informara en la herramienta elegida para ser informados.
● Categorization
○ La categorización de defectos ayuda a los desarrolladores de software a priorizar sus
tareas. Eso significa que este tipo de prioridad ayuda a los desarrolladores a corregir
aquellos defectos que son sumamente cruciales.
○ Critical-High-Medium-Low
Defects
Defects Lifes Cycle
● Resolution
○ Una vez que los defectos son aceptados y categorizados, puede seguir los siguientes pasos
para corregir el defecto:
○ Asignación: se asigna a un desarrollador u otro técnico para corregir, y se cambia el estado a
Respondiendo.
○ Solucion programada: el lado del desarrollador se hace cargo en esta fase. Ellos crearán un
horario para corregir estos defectos, dependiendo de la prioridad del defecto.
○ Seguimiento defecto: mientras el equipo de desarrollo está arreglando los defectos, el
Lider-Manager de Testing-QA rastrea el proceso de reparar el defecto en la fecha asignada
por el equipo de Desarrollo.
○ resolución: obtenga un informe de la resolución de los desarrolladores cuando se solucionen
los defectos.
Defects
Defects Lifes Cycle
● Verification
○ Después de que el equipo de desarrollo reparó e informó el defecto, el equipo de pruebas
verifica que los defectos se hayan resuelto realmente.
● Closure
○ Una vez que se ha resuelto y verificado un defecto, el defecto cambia de estado como
cerrado. Si no es así, ha enviado un aviso al desarrollo para verificar el defecto nuevamente.
● Reporting
○ El Lider Proyecto tiene derecho a conocer el estado del defecto. Deben comprender el
proceso de gestión de defectos para ayudarle en este proyecto. Por lo tanto, debe informarles
la situación de defecto actual para obtener retroalimentación de ellos.
Defects
Defects Trucking Tools
● Es un sistema de seguimiento de errores o un sistema de seguimiento de defectos, es una aplicación que

realiza un seguimiento de los errores encontrados en la ejecucion de pruebas de software.
○ Jira
○ Mantis
○ RedMine
Testing Design Approach
Statics Test
● Las pruebas estáticas se refieren a las pruebas de software manualmente o con la ayuda de
herramientas. Las pruebas estáticas generalmente se llevan a cabo durante la fase temprana del ciclo de
vida del desarrollo del software. Las pruebas estáticas son útiles para probar múltiples aspectos de un
software, incluido el código fuente, las especificaciones funcionales y de requisitos, y los documentos y
modelos de diseño. Las pruebas estáticas se pueden dividir en dos categorías en función de si se
realizan manualmente o con la ayuda de herramientas.
Informal Review
● Una revisión informal tiene como objetivo mejorar la calidad del producto probado a través de
discusiones y generalmente no está documentado. La etapa preliminar de la revisión puede incluir la
evaluación de un equipo de dos miembros, mientras que en las etapas posteriores, el tamaño del equipo
de revisión puede aumentar y puede requerir más reuniones.
Statics Test/Walkthroughs
● se utiliza para revisar documentos con colegas, gerentes y compañeros de equipo que se guían por el
autor del documento para recopilar comentarios y alcanzar un consenso. Un Walkthroughs puede ser
planificado u organizado según las necesidades. En general, las personas que trabajan en el mismo
producto de trabajo están involucradas en el proceso.
● Esta revisión se vuelve más beneficiosa para aquellas personas que no tienen conocimientos del
software y, a través de esta reunión, obtienen una buena visión del producto que se va a desarrollar. El
contenido está siendo explicado por el autor paso a paso para alcanzar un objetivo común.
● El resultado de un Walkthroughs es el siguiente:
○ Lista de elementos no comprendidos.
○ Lista de elementos que se piensa son incorrectos.
Statics Test/Technical Reviews
● Una revisión técnica es realizada por un moderador capacitado o un experto técnico. Es menos formal en
comparación con una inspección. Por lo general, se lleva a cabo como una revisión por pares sin ninguna
participación de la gerencia.
Statics Test/Inspections
● Es el tipo de revisión más formal, está liderado por moderadores capacitados, durante la inspección, los
revisores preparan y verifican minuciosamente los documentos antes de la reunión.Se trata de pares para
examinar el producto.Se lleva a cabo una preparación separada durante la cual se examina el producto y
se encuentran los defectos.Los defectos encontrados están documentados en una lista de registro o
registro de problemas .El moderador lleva a cabo un seguimiento formal que aplica los criterios de salida.
● Los objetivos de la inspección son:
○ Ayuda al autor a mejorar la calidad del documento bajo inspección.
○ Elimina los defectos de manera eficiente y lo más temprano posible.
○ Mejora la calidad del producto.
○ Crea un entendimiento común al intercambiar información.
○ Aprende de los defectos encontrados y previene la aparición de defectos similares.
Dinamic Test
● es un proceso de validación de aplicaciones de software como usuario final en diferentes entornos para
construir el software correcto. La prueba dinámica se define como un tipo de prueba de software, que
verifica el comportamiento dinámico del código que se analiza.
Dinamic Test/Structure Base (White Box)
● La prueba de caja blanca se define como la prueba de la estructura interna, el diseño y la codificación de
una solución de software. En este tipo de pruebas, el código es visible para el Tester. Se enfoca
principalmente en verificar el flujo de entradas y salidas a través de la aplicación, mejorar el diseño y la
facilidad de uso, fortalecer la seguridad.
Dinamic Test/Structure Base (White Box) Statement
● Este método implica el cálculo del porcentaje de sentencias ejecutables que están siendo ejercidas por el
conjunto de pruebas.
Dinamic Test/Structure Base (White Box) Decisions
● En el método de cobertura de decisión, los casos de prueba se diseñan de manera que los resultados de
la decisión se ejecutan automáticamente. Asegura que cada posible rama desde un punto de decisión se
implementa al menos una vez.
Dinamic Test/Structure Base (White Box) Condition
● La mayoría de los resultados de los casos de prueba diseñados según la técnica de diseño de prueba de
caja blanca se obtienen siguiendo el método de cobertura de condición. Al seguir este método, los casos
de prueba se diseñan de manera que los resultados de la condición (la evaluación de una condición como
"verdadera" o "falsa") se ejecuten automáticamente.
Dinamic Test/Structure Base (White Box) Multiple Condition
● Toda combinación de "verdadero" o "falso" para las condiciones relacionadas con una decisión debe
probarse con esta técnica.
Dinamic Test/Experiences Bases
● Como su nombre lo indica, la técnica basada en la experiencia no implica una estructura interna ni
externa, sino que se basa en la experiencia. Algunos de los métodos seguidos son:
○ Exploratory Testing: Este método, generalmente realizado por analistas de negocios y
expertos, se sigue para probar las aplicaciones sin ningún tipo de documentación.
○ Error Guessing: Uno de los métodos ampliamente utilizados de la técnica de diseño de
prueba basada en la experiencia, el ataque de fallas involucra a los Testers que anticipan los
errores, la disponibilidad de datos de defectos, etc., según su experiencia
Dinamic Test/Specification Base (Black Box)
● También conocida como técnica de diseño de prueba basada en especificaciones, la técnica de diseño de
prueba de caja negra utiliza las descripciones externas del software, como las especificaciones técnicas,
el diseño, los requisitos del cliente, etc. Esto implica que un Tester que no tenga ningún conocimiento
sobre el código o la información interna. La estructura también puede realizar la prueba.
Equivalence Particioning
● El propósito de este tipo de método de diseño de prueba es reducir el número de pruebas dividiendo los
diferentes tipos de prueba. Una vez que se hayan dividido las pruebas, el sistema se comportará de
manera similar para las diferentes pruebas con partición de equivalencia.
Boundary Value Analysis
● El mejor método de la técnica de diseño de caja negra, el análisis de valor de límite comprende probar los
valores de entrada en los límites. Generalmente, los valores de entrada se ponen a prueba en las etapas
iniciales para reducir las posibilidades de causar errores
Decision Tables
● La identificación de las condiciones de prueba según las tablas de decisión que están asociadas con
diferentes condiciones se conoce como prueba de tabla de decisión. Cada decisión mantiene una
correspondencia con predicados, relaciones o variables. Se sabe que las tablas de decisión que tienen un
símbolo de "guión" tienen poca influencia en las acciones que se están realizando.
State Transition
● La identificación de las condiciones de prueba de una tabla de estado es una prueba de transición de
estado.
Testing Level
Testing Level
● Un nivel de prueba de software es un proceso donde se prueba cada unidad o componente de un

software / sistema. El objetivo principal de las pruebas del sistema es evaluar el cumplimiento del
sistema con las necesidades especificadas.
● Hay muchos niveles de prueba diferentes que ayudan a verificar el comportamiento y el rendimiento de
las pruebas de software. Estos niveles de prueba están diseñados para reconocer las áreas faltantes y la
conciliación entre los estados del ciclo de vida del desarrollo. En los modelos SDLC hay fases
caracterizadas, como la recopilación de requisitos, el análisis, el diseño, la codificación o la ejecución, las
pruebas y la implementación.
Testing Level
Components Test
● La prueba de componentes es un método donde la prueba de cada componente en una aplicación se

realiza por separado.
Integration Test
● Integración significa combinar. Por ejemplo, en esta fase de prueba, diferentes módulos de software se
combinan y se prueban en grupo para asegurarse de que el sistema integrado esté listo para la prueba del
sistema.Las pruebas de integración comprueban el flujo de datos de un módulo a otros módulos.
Testing Level
System Test
● Las pruebas del sistema se realizan en un sistema completo e integrado. Permite verificar el
cumplimiento del sistema según los requisitos. Prueba la interacción general de los componentes. Se
trata de pruebas de carga, rendimiento, fiabilidad y seguridad.El sistema prueba con mayor frecuencia la
prueba final para verificar que el sistema cumple con las especificaciones. Evalúa la necesidad funcional
y no funcional de las pruebas.
Acceptances Test
● La prueba de aceptación es una prueba que se realiza para determinar si se cumplen los requisitos de
una especificación o contrato según su entrega. La prueba de aceptación es básicamente realizada por el
usuario o cliente.
Manual Testing
● La prueba manual es un tipo de prueba de software donde los Tester ejecutan manualmente los casos de
prueba sin usar herramientas de automatización. La prueba manual es el más primitivo de todos los tipos
de prueba y ayuda a encontrar errores en el sistema de software. Cualquier aplicación nueva debe ser
probada manualmente antes de que su prueba pueda ser automatizada.
Automation Testing
● La prueba de automatización es una técnica automática en la que el probador escribe scripts por su
cuenta y utiliza un software adecuado para probar el software. Es básicamente un proceso de
automatización de un proceso manual. Al igual que las pruebas de regresión, las pruebas de
automatización también se utilizan para probar la aplicación desde el punto de vista de carga,
rendimiento y estrés.
Automated Testing Vs. Manual Testing
● Pruebas manuales vs. automatizadas: los pros y los contras.Las pruebas manuales y las pruebas
automatizadas cubren dos vastas áreas. Dentro de cada categoría, hay métodos de prueba específicos
disponibles, como pruebas de caja negra, pruebas de caja blanca, pruebas de integración, pruebas de
sistema, pruebas de rendimiento y pruebas de carga. Algunos de estos métodos se adaptan mejor a las
pruebas manuales, y algunos se realizan mejor a través de la automatización. Aquí hay una breve
comparación de cada tipo, junto con algunas ventajas y desventajas:
Prueba manual
● La prueba manual no es precisa en todo momento debido a un error humano, por lo que es menos
confiable.
● Las pruebas manuales llevan mucho tiempo, ocupando recursos humanos.
● La inversión es necesaria para los recursos humanos.
● La prueba manual solo es práctica cuando los casos de prueba se ejecutan una o dos veces, y no se
requieren repeticiones frecuentes.
● Las pruebas manuales permiten a los humanos
● observación, que puede ser más útil si
● El objetivo es la facilidad de uso o la mejora de la experiencia del cliente.
Prueba automatizada
● Las pruebas automatizadas son más confiables, ya que se realizan mediante herramientas y / o scripts.
● Las pruebas automatizadas se ejecutan mediante herramientas de software, por lo que es
significativamente más rápido que un enfoque manual.
● Se requiere inversión para probar herramientas.
● La prueba automatizada es una opción práctica cuando los casos de prueba se ejecutan repetidamente
durante un largo período de tiempo.
● Las pruebas automatizadas no implican la observación humana y no pueden garantizar la facilidad de
uso o la experiencia positiva del cliente.
Testing Types according the Approach
White Box
● es un método de prueba de software en el que el Tester conoce la estructura interna / diseño /

implementación del elemento que se está probando. El Tester elige entradas para realizar recorridos a
través del código y determina las salidas apropiadas. El conocimiento de programación y el conocimiento
de implementación son esenciales. Las pruebas de caja blanca están probando más allá de la interfaz del
usuario y en el meollo de la cuestión de un sistema.Este método se llama así porque el programa de
software, a los ojos del Tester, es como una caja blanca / transparente; Dentro de lo que uno ve
claramente.
Unit Testing
● es un nivel de prueba de software donde se prueban unidades / componentes individuales de un

software. El propósito es validar que cada unidad del software funciona según lo diseñado. Una
unidad es la parte comprobable más pequeña de cualquier software. Por lo general, tiene una o
unas pocas entradas y por lo general una sola salida. En la programación de procedimientos, una
unidad puede ser un programa, función, procedimiento, etc. individual. En la programación
orientada a objetos, la unidad más pequeña es un método, que puede pertenecer a una base /
superclase, clase abstracta o derivada / clase secundaria.
Black Box
● También conocido como Pruebas de comportamiento, es un método de prueba de software en el

que el Tester no conoce la estructura interna / diseño / implementación del elemento que se está
probando. Estas pruebas pueden ser funcionales o no funcionales, aunque generalmente son
funcionales.
Functional Test
● es un tipo de prueba de software por el cual el sistema se prueba contra los requisitos /
especificaciones funcionales.Las funciones (o características) se prueban al proporcionarles
entrada y examinar la salida. Las pruebas funcionales aseguran que los requisitos sean cumplidos
adecuadamente por la aplicación. Este tipo de prueba no se refiere a cómo se produce el
procesamiento, sino a los resultados del procesamiento. Simula el uso real del sistema, pero no
hace suposiciones de la estructura del sistema.Durante las pruebas funcionales, se utiliza la
técnica de prueba de caja negra en la que el Tester desconoce la lógica interna del sistema que se
está probando.Las pruebas funcionales se realizan normalmente durante los niveles de Pruebas
del sistema y Pruebas de aceptación.
● Normalmente, las pruebas funcionales implican los siguientes pasos:
○ Identifique las funciones que se espera que el software realice.
○ Crear datos de entrada basados en las especificaciones de la función.
○ Determine la salida en base a las especificaciones de la función.
○ Ejecutar el caso de prueba.
○ Compare las salidas reales y esperadas.
Regression Test
● es un tipo de prueba de software que pretende garantizar que los cambios (mejoras o
correcciones de defectos) en el software no lo hayan afectado negativamente.La posibilidad de
que algún cambio en el código afecte a las funcionalidades que no están directamente asociadas
con el código siempre está ahí y es esencial que se realicen pruebas de regresión para asegurarse
de que arreglar una cosa no haya roto otra.Durante la prueba de regresión, los nuevos casos de
prueba no se crean, pero los casos de prueba creados previamente se vuelven a ejecutar.
Las pruebas de regresión se pueden realizar durante cualquier nivel de prueba (Unidad, Integración,
Sistema o Aceptación), pero es más relevante durante la Prueba del sistema.
Smoke and Sanity Test
● También conocido como "Pruebas de verificación de construcción", es un tipo de prueba de

software que se compone de un conjunto no exhaustivo de pruebas que tienen como objetivo
garantizar que las funciones más importantes funcionen. El resultado de esta prueba se utiliza
para decidir si una compilación es lo suficientemente estable como para continuar con las
pruebas adicionales.El término "prueba de humo", se dice, llegó a las pruebas de software de un
tipo similar de prueba de hardware, en el que el dispositivo pasó la prueba si no se prendió fuego
(o fumó) la primera vez que se encendió.
● Las pruebas de humo cubren la mayoría de las funciones principales del software, pero ninguna
de ellas en profundidad. El resultado de esta prueba se utiliza para decidir si continuar con las
pruebas adicionales. Si la prueba de humo pasa, siga adelante con más pruebas. Si falla, detenga
más pruebas y solicite una nueva compilación con las correcciones necesarias. Si una aplicación
está muy dañada, las pruebas detalladas pueden ser una pérdida de tiempo y esfuerzo.
● Las pruebas de humo se usan normalmente en los niveles de Pruebas de integración, Pruebas del
sistema y Pruebas de aceptación.
Risk Based Testing
● Las pruebas basadas en riesgos están priorizando las características, los módulos y las funciones
de la aplicación bajo prueba en función del impacto y la probabilidad de fallas. Implica evaluar el
riesgo en función de la complejidad, la criticidad del negocio, la frecuencia de uso, las áreas
visibles, las áreas propensas a defectos, etc.El riesgo es la ocurrencia de un evento incierto con un
efecto positivo o negativo en los criterios de éxito mensurables de un proyecto. Podrían ser
eventos que ocurrieron en el pasado o eventos actuales o algo que podría suceder en el futuro.
Estos eventos inciertos pueden tener un impacto en los objetivos de costos, negocios, técnicos y
de calidad de un proyecto.
Risk Based Testing
● Proceso de prueba basado en el riesgo:

● Identificación del riesgo: el equipo de pruebas debe identificar los módulos funcionales que son
aplicables a la aplicación. Se puede hacer a través de talleres, listas de verificación, aprendizajes
de proyectos anteriores, RCA, entrevistas, etc.
● Impacto en los módulos funcionales: el siguiente paso es analizar el riesgo y filtrarlos según la
importancia. Esto incluye tanto el análisis de riesgo cualitativo como el cuantitativo.
● Planificación de la respuesta al riesgo: Sobre la base del análisis, se puede decidir si la respuesta
es necesaria o no. Es responsabilidad del propietario verificar las opciones para reducir el impacto
de los riesgos.
● Monitoreo de riesgos: el proceso de monitoreo y control de riesgos se utiliza para identificar
riesgos, rastrear riesgos identificados, actualizar riesgos y monitorear desencadenantes de
riesgos. Esto se puede hacer por reunión retrospectiva, auditoría de riesgos, medición del
desempeño.
Risk Based Testing
● Riesgo y su impacto:
● ¿Qué es el impacto y el impacto en los negocios? Esto debe ser comprendido por todos en el
equipo. Hay múltiples factores considerados al calcular los riesgos. Así que básicamente,
●
● Riesgo = Impacto * Probabilidad de falla
●
● El impacto debe categorizarse porque si falla alguna funcionalidad, ayuda a comprender el
impacto en el negocio. El equipo de negocios debe realizar una categorización adecuada de los
requisitos. Por ejemplo: si los scripts de prueba que se clasifican como altos fallan, el impacto
será mayor y si el script de prueba categorizado como bajos falla, el impacto será menor, por eso
la categorización es muy importante. Así que definir el impacto tiene los siguientes beneficios:
Risk Based Testing
● Las áreas de alto riesgo se pueden identificar en la aplicación.

● Enfoque controlado de toma de riesgos.
● Reducir el alcance de volver a probar los scripts de prueba.
● Se puede identificar la severidad de los defectos.
● Los guiones de prueba de regresión son fáciles de preparar
● Si se encontró un defecto relacionado con el cambio, lo siguiente es una estimación de la escala
general de impacto:
● Impacto crítico - 5: Cuando todas las funciones principales y críticas fallan. Esto resulta en la
pérdida de ingresos / datos.
● Alto impacto - 4: en esto, los clientes no se ven afectados, pero el problema está en el sistema
backend
● Impacto medio - 3: para resolver este tiempo y se necesita investigación, nuevamente los clientes
no se ven afectados por esto, pero el cambio ha afectado al otro código. Aquí el progreso se
interrumpe con una gran extensión al costo del proyecto.
Risk Based Testing
● Impacto moderado - 2: los clientes no se ven afectados y los cambios realizados son a corto
plazo y manejables.
● Impacto marginal - 1: Esto puede ser errores de ortografía o problemas menores de IU.
● Además, la probabilidad de fallo tiene diferentes categorías:
● Crítico -5: la probabilidad de falla es demasiado alta y el impacto en el sistema periférico es

posible.
● Alto-4: la probabilidad de falla es alta y el impacto en el sistema periférico también es alto.
● Medio-3: la probabilidad de fallo es media y el impacto en el sistema periférico también es medio.
● Moderado-2: la probabilidad de falla es moderada y el impacto en el sistema periférico también es
moderado.
● Marginal-1: La probabilidad de falla es baja y el impacto en el sistema periférico también es bajo.
Risk Based Testing
● Enfoque de prueba basado en el riesgo:

● Comprensión y análisis de requerimientos.
● Revisión de documentos.
● Acceder al riesgo mediante el cálculo del impacto de cada requisito en el proyecto.
● Identificación de áreas de alto riesgo mediante matriz de evaluación de riesgos.
● Lista de riesgos identificados.
● Priorización de requisitos.
● Los riesgos críticos pueden ser considerados para la implementación
● Definir prueba según la calificación.
● Diseñe los scripts de prueba de forma que los artículos de alto riesgo vuelvan a probarse primero.
● Para los elementos de prueba de bajo riesgo, se pueden utilizar diferentes técnicas de diseño de
prueba como la partición de equivalencia.
● Revisar el plan de prueba y los escenarios de prueba creados por el equipo de prueba.
● Revisión por pares para la identificación de defectos.
● Ejecución de casos de prueba según la prioridad de riesgo.
Risk Based Testing
● Evaluando criterios de salida

● Análisis de defectos y prevención de defectos para eliminar los defectos.
● Regresión y reevaluación para validar las correcciones de defectos.
● Control de riesgos y seguimiento.
● Reevaluación de riesgos y retroalimentación de los clientes.
● Ventajas de las pruebas basadas en el riesgo:
● Las áreas de mayor prioridad se prueban primero, lo que conduce a una mejor calidad del
producto final. Así que con las pruebas de pruebas basadas en el riesgo se pueden priorizar
contra plazos.
● La prueba se vuelve más organizada.
● Mejora la satisfacción del cliente.
● Las áreas de riesgo se pueden descubrir temprano para que se puedan tomar medidas
preventivas cuando sea necesario.
● Este es un método de reducción de costos.
Risk Based Testing
● Desventajas de las pruebas basadas en riesgo:

● Si se evalúan algunos riesgos demasiado bajos o si existen riesgos no reconocidos, esto puede
causar un problema si se convierte en realidad.
● Proceso de prueba basado en el riesgo:
Identificar riesgos: consultar a los equipos técnicos y de negocios y preparar una lista de riesgos.
● Analizando el riesgo: discutiendo los riesgos y asignándoles una probabilidad.
● Respuesta al riesgo: documentar dependencias y asignar puntaje de efectividad de prueba
● Prueba de alcance: esta es la revisión del alcance de los riesgos que deben abordarse mediante
la prueba
● Definición del proceso de prueba: Redacción del proceso de prueba.

Risk Based Testing
● Resumen:
● Los scripts de prueba se ejecutan de acuerdo con el orden de prioridad de riesgo.
● Se evalúan los esfuerzos de prueba organizados y el nivel de prioridad de cada elemento de
riesgo.
● Esta prueba es la forma más eficiente de proyectos basados en riesgos.
● Ayuda a identificar el impacto positivo o negativo.
● Ayuda a prevenir los problemas que puedan ocurrir en el futuro.
Non Functional Test
● Es el tipo de prueba realizada contra los requisitos no funcionales. La mayoría de los criterios no
se consideran en las pruebas funcionales, por lo que se utilizan para verificar la preparación de un
sistema. Los requisitos no funcionales tienden a ser aquellos que reflejan la calidad del producto,
particularmente en el contexto de la perspectiva de idoneidad de sus usuarios. Se puede iniciar
después de la finalización de las pruebas funcionales. Las pruebas no funcionales pueden ser
efectivas usando herramientas de prueba.
● La prueba de atributos de software que no están relacionados con ninguna función específica o
acción del usuario como el rendimiento, la escalabilidad, la seguridad o el comportamiento de la
aplicación bajo ciertas restricciones.
● Las pruebas no funcionales tienen una gran influencia en la satisfacción del cliente y del usuario
con el producto. Las pruebas no funcionales deben expresarse de forma comprobable, no como
"el sistema debe ser rápido" o "el sistema debe ser fácil de operar", lo que no es comprobable.
● Básicamente, en la prueba no funcional se usa para los atributos no funcionales principales de los
sistemas de software. Tomemos ejemplos de requisitos no funcionales; ¿En cuánto tiempo
tardará el software en completar una tarea? o qué tan rápido es la respuesta.
Non Functional Test/Performances Test
● es el tipo de prueba que se realiza para determinar el rendimiento del sistema para medir la
medida, validar o verificar los atributos de calidad del sistema como la capacidad de respuesta, la
velocidad, la escalabilidad y la estabilidad en diversas condiciones de carga. El sistema se prueba
bajo una mezcla de condiciones de carga y verifica el tiempo requerido para que el sistema
responda bajo diferentes cargas de trabajo. Las pruebas de rendimiento del software implican la
prueba de la aplicación bajo prueba para garantizar que la aplicación funciona como se espera en
diversas condiciones de carga. El objetivo de las pruebas de rendimiento no es solo encontrar los
errores en el sistema, sino también eliminar los cuellos de botella del sistema.
Non Functional Test/Load Test
● La prueba de carga es un tipo de prueba de rendimiento para verificar que el sistema aumenta
constantemente la carga en el sistema hasta que la carga de tiempo alcanza su valor umbral.
Aquí Aumentar la carga significa aumentar el número de usuarios concurrentes, transacciones y
verificar el comportamiento de la aplicación bajo prueba. Normalmente se lleva a cabo debajo de
un ambiente controlado para distinguir dos sistemas diferentes. También se le llama "Pruebas de
resistencia" y "Pruebas de volumen". El propósito principal de las pruebas de carga es monitorear
el tiempo de respuesta y el poder de permanencia de la aplicación cuando el sistema se está
desempeñando bien bajo una carga pesada. La prueba de carga está incluida en la Prueba no
funcional y está diseñada para probar los requisitos no funcionales de una aplicación de software.
● La prueba de carga se realiza para asegurarse de que la cantidad de carga puede soportar la
aplicación bajo prueba. La prueba de carga ejecutada con éxito es solo si los casos de prueba
especificados se ejecutan sin ningún error en el tiempo asignado.
Non Functional Test/Load Test
● Ejemplos simples de pruebas de carga:

● Prueba de impresora enviando trabajo grande.
● Edición de un documento muy grande para prueba de procesador de textos.
● Continuamente leyendo y escribiendo datos en el disco duro.
● Ejecutando múltiples aplicaciones simultáneamente en el servidor.
● Pruebas de servidor de correo accediendo a miles de buzones.
Non Functional Test/Volume Test
● La prueba de volumen es una prueba no funcional que se refiere a probar una aplicación de
software con una gran cantidad de datos a procesar para verificar la eficiencia de la aplicación. El
objetivo principal de esta prueba es monitorear el rendimiento de la aplicación en diferentes
volúmenes de base de datos.
Non Functional Test/Stress Test
● Stress Testing es un tipo de prueba de rendimiento para verificar la estabilidad del software
cuando los recursos de hardware no son suficientes como CPU, memoria, espacio en disco, etc.
● Las pruebas de estrés son pruebas negativas en las que cargamos el software con una gran
cantidad de usuarios / procesos concurrentes que no pueden ser manejados por los recursos de
hardware del sistema. Esta prueba también se conoce como Prueba de fatiga, esta prueba debe
capturar la estabilidad de la aplicación al probarla más allá de su capacidad de ancho de banda.
● La idea principal detrás de las pruebas de estrés es determinar la falla del sistema y vigilar cómo
el sistema recupera la recuperación con gracia, esta calidad se conoce como recuperabilidad. Las
pruebas de estrés se incluyen en las Pruebas no funcionales y están diseñadas para probar los
requisitos no funcionales de una aplicación de software. Estas pruebas deben llevarse a cabo en
un entorno controlado antes del lanzamiento, para que podamos capturar con precisión el
comportamiento del sistema en la mayoría de los escenarios erráticos.
Non Functional Test/Scalability Test
● La prueba de escalabilidad es un tipo de pruebas no funcionales y es la prueba de una aplicación

de software para determinar su capacidad de escalar en términos de cualquiera de sus
capacidades no funcionales, como la carga de usuarios admitida, la cantidad de transacciones, el
volumen de datos, etc. El objetivo principal de esta prueba es comprender en qué punto máximo el
sistema evita una mayor escala.
Non Functional Test/Efficiency/Spike Test
● La prueba de picos es un subconjunto de pruebas de estrés. Se realiza una prueba de puntas para
validar las características de rendimiento cuando el sistema sometido a prueba está sujeto a
modelos de carga de trabajo y volúmenes de carga que aumentan repetidamente más allá de las
operaciones de producción previstas durante cortos períodos de tiempo.
Non Functional Test/Portability
● Se refiere al proceso de probar la facilidad con la que un componente o aplicación de software de

computadora puede moverse de un entorno a otro, por ejemplo. movimiento de cualquier
aplicación de Windows 2000 a Windows 10. Esto generalmente se mide en términos de la
cantidad máxima de esfuerzo permitido. Los resultados se miden en términos del tiempo
requerido para mover el software y completar las actualizaciones de la documentación.
Non Functional Test/Usability
● La prueba de usabilidad se define como un tipo de prueba de software en la cual, un pequeño

grupo de usuarios finales objetivo de un sistema de software, "lo utiliza" para exponer defectos de
usabilidad. Estas pruebas se centran principalmente en la facilidad de uso de la aplicación por
parte del usuario, la flexibilidad en el manejo de los controles y la capacidad del sistema para
cumplir sus objetivos. También se denomina prueba de experiencia de usuario (UX).
Non Functional Test/Reliability
● se define como un tipo de prueba de software, que verifica si el software puede realizar una
operación sin fallas durante un período de tiempo específico en un entorno
específico.Confiabilidad significa "producir lo mismo", en otros términos, la palabra "confiable"
significa que algo es confiable y que dará el mismo resultado en todo momento.Lo mismo es
cierto para las pruebas de fiabilidad. Las pruebas de confiabilidad en el software aseguran que el
producto está libre de fallas y es confiable para el propósito previsto.
Non Functional Test/Recoverability
● La prueba de recuperación se define como un tipo de prueba de software, que se realiza para
determinar si las operaciones pueden continuar después de un desastre o después de que se
haya perdido la integridad del sistema.Implica volver a un punto donde se conocía la integridad
del sistema y luego volver a procesar las transacciones hasta el punto de falla.El propósito de las
pruebas de recuperación es verificar la capacidad del sistema para recuperarse de diversos
puntos de falla.
● Ejemplo de prueba de recuperación:
○ Cuando una aplicación recibe datos de la red, desenchufe el cable de conexión.
○ Después de un tiempo, vuelva a enchufar el cable y analice la capacidad de la
aplicación para continuar recibiendo datos desde el punto en que se interrumpió la
conexión de red.
Non Functional Test/Performance Testing vs. Load Testing vs. Stress Testing
● Diferencias entre Performance, Load y Stress Testing. Las pruebas de carga y las pruebas de
rendimiento se suelen denominar pruebas positivas, mientras que las pruebas de estrés se
consideran pruebas negativas. Pruebas de rendimiento: Esto mide el tiempo de respuesta de una
aplicación con un número esperado de usuarios.
BDD
Definition
● BDD (Behavior Driven Development) es una metodología para desarrollar software a través de la
comunicación continua basada en ejemplos entre desarrolladores, QA y BA. Más que nada, el
propósito principal de la metodología BDD es fomentar la comunicación entre los interesados del
proyecto para que todos los miembros del equipo entiendan correctamente el contexto de cada
característica (es decir, entendimiento compartido), antes de que comience el trabajo de
desarrollo. Esto ayuda a identificar escenarios clave para cada historia y también erradica las
ambigüedades de los requisitos.
● En BDD, los ejemplos se denominan escenarios. Los escenarios se estructuran en torno al patrón
Contexto-Acción-Resultado y se escriben en un formato especial llamado Gherkin.
● Los escenarios son una forma de explicar (en inglés simple) cómo debe comportarse una
característica determinada en diferentes situaciones o con diferentes parámetros de entrada.
● Debido a que Gherkin es estructural, sirve como especificación y entrada en pruebas
automatizadas, de ahí el nombre "Especificaciones ejecutables".
BDD
BDD Ejemplos
● ¿Qué es un archivo de características(historias) y qué contiene?

● Los archivos de características (historias)son archivos de texto con la extensión .feature, que
pueden abrirse con cualquier editor de texto y que se pueden leer con cualquier herramienta
compatible con BDD, como Cucumber, JBehave o Behat.
● Los archivos de características (historias)deben comenzar con el contexto de la característica
(que es esencialmente la historia), seguido de al menos un escenario en el siguiente formato
○ Feature(caracteristica-historia)= cliente retira dinero cajero automatico.

○ Como cliente,
○ yo quiero retirar dinero del Cajero Automático,
○ y evitar ir al banco a hacer una cola para obtener dinero
BDD
BDD Ejemplos
● Scenario: Cuenta tiene credito.
● Given :cuenta tiene credito.

● And:la tarjeta es valida.
● And:cajero tiene dinero disponible.
● When:cliente solicita dinero.
● Then: la cuenta es debitada.
● And:el dinero es entregado al cliente.
● And:el cliente retira su tarjeta.
● Los escenarios en los archivos de características (historias)deben centrarse en el "qué" en lugar

del "cómo". Los escenarios deben ser concisos y precisos, de modo que el lector pueda
comprender rápidamente la intención de la prueba sin tener que leer muchos pasos irrelevantes.
BDD
BDD Ejemplos
● Scenario: Cuenta excede limite extraccion.
● Given :cuenta excede limite extraccion..

● And:la tarjeta es valida..
● When:cliente solicita dinero.
● Then: cajero informa mensaje ,la imposibilidad-causa de entregar dinero.
● And:el dinero no es entregado al cliente.
● And:el cliente retira su tarjeta.
● Por supuesto que se deberia incorporar todos los posibles escenarios dependiendo de la
caracteristica dada.
BDD
Benefits
● Una colaboración sólida con todas las partes involucradas tiene una sólida comprensión del proyecto y todas
pueden tener un rol en la comunicación y, de hecho, tener discusiones constructivas. BDD aumenta y mejora la
colaboración. Permite que todos los involucrados en el proyecto se involucren fácilmente en el ciclo de
desarrollo del producto. Y al usar un lenguaje sencillo, todos pueden escribir escenarios de comportamiento.
● Alta visibilidad. Al utilizar un lenguaje comprendido por todos, todos obtienen una gran visibilidad de la
progresión del proyecto.
● El diseño del software sigue el valor del negocio. De hecho, BDD le da gran importancia al valor y las
necesidades del negocio. Al establecer prioridades con el cliente, en función del valor que proporciona, los
desarrolladores pueden proporcionar un mejor resultado porque tienen una sólida comprensión de cómo
piensa el cliente. Al centrarse en el valor, no se construyen características inútiles.
● El lenguaje ubicuo. Como se mencionó anteriormente, el lenguaje ubicuo es comprensible para todos los
miembros del equipo, lo que reduce los conceptos erróneos y los malentendidos y facilita que los nuevos
miembros se unan al proceso de trabajo.
● El desarrollo de software satisface las necesidades del usuario. Al centrarse en las necesidades de la
empresa, obtiene usuarios satisfechos, y eso implica un negocio feliz, por supuesto. Con BDD, como su
nombre lo indica, usted se enfoca en el comportamiento, que tiene un impacto más fuerte que la
implementación en sí misma.
BDD
Benefits
● Más confianza por parte de los desarrolladores. En general, los equipos que utilizan BDD tienen mucha
más confianza en no romper el código y tienen una mejor capacidad de predicción cuando se trata de
su trabajo.
● Costos mas bajos. Al mejorar la calidad del código, básicamente está reduciendo los costos de
mantenimiento y minimizando los riesgos del proyecto.
TDD
Definition
● es un proceso de desarrollo de software que se basa en la repetición de un ciclo de desarrollo muy

corto. Primero, el desarrollador escribe un caso de prueba automatizado (que falla inicialmente)
que define una mejora deseada o una nueva función, luego produce la cantidad mínima de código
para pasar esa prueba y, finalmente, refactor al nuevo código a estándares aceptables. Las
pruebas unitarias automatizadas se escriben antes de que el código se escriba realmente. La
ejecución de estas pruebas le brinda una confirmación rápida de si su código se comporta como
debería o no.
TDD
Benefits
● Retroalimentación rápida
● Reduce el tiempo dedicado a retrabajo.
● Menos tiempo empleado en el depurador
● Identifique el error / problema rápidamente
● Le informa si su último cambio (o refactorización) ha roto códigos que funcionaban anteriormente
● Permite que el diseño evolucione y se adapte a su comprensión cambiante del problema
● Te obliga a escribir clases pequeñas enfocadas en una cosa
● Mantenido, flexible y fácilmente extensible
● Las pruebas unitarias resultantes son simples y actúan como documentación para el código. Dado que los
casos de uso de Test Driven Development se escriben como pruebas, otros programadores pueden ver las
pruebas como ejemplos de uso de cómo se pretende que funcione el código
● Acorta el desarrollo Time to Market
● Aumenta la productividad del programador.
● Test Driven Development le da a los programadores la confianza de cambiar la arquitectura más grande de una
aplicación al agregar una nueva funcionalidad. Sin la flexibilidad de TDD, los desarrolladores frecuentemente
agregan nuevas funcionalidades al atornillarlas virtualmente a la aplicación existente sin una verdadera
integración.
Unit Testing Vs. BDD Vs. TDD
differences
● Comportamiento vs. Prueba

● “¿Para qué estás probando?” Es una gran pregunta. ¿Estás probando para averiguar el comportamiento de la
aplicación? ¿O estás probando la implementación real? Este es el mayor punto de discusión cuando se habla
de BDD y TDD. En BDD, está buscando el comportamiento, por ejemplo, qué pasará con este sistema bajo una
determinada condición. Pero en TDD usted tiene una prueba para un método que establecerá algunas
condiciones, pero a medida que el sistema evolucione, estas pruebas pueden dar resultados falsos.
● Para simplificar esto aún más, se puede escribir:
● En TDD, no me importa mucho la salida. Lo único que se necesita es llevar a cabo la prueba de una manera
particular.
● Pero en BDD, no me importa cómo se obtiene la salida, solo que la salida tiene que ser correcta en la condición
GIVEN.
● Comunicación y feedback.
differences
● BDD tiene la ventaja sobre TDD en esta área. Dado que el comportamiento en BDD está escrito en inglés
simple y descriptivo, sus clientes podrán comprender las pruebas y enviar sus comentarios más rápidamente.
Estas líneas de comunicación más abiertas le permiten incorporar mejor sus comentarios para mejorar aún
más las pruebas y el diseño del software. En TDD, solo los programadores hábiles pueden comprender la
prueba, lo que, por supuesto, limita la comunicación con la audiencia más amplia, pero este método
proporcionará un código de mayor calidad.
● De nuevo, pero en palabras más simples:
● En BDD, encontrará una mejor especificación, ya que la comunicación entre el desarrollador del software y el
propietario del producto es rápida y fácil.
● Es posible que TDD no tenga la capacidad de especificar el comportamiento exacto, pero usted logra una
mayor calidad con el código de software.
differences
● Escritura de pruebas de TDD frente a escritura de pruebas de BDD de falla:
● Como se discutió, ambos enfoques comienzan con escribir una prueba fallida y luego retomarla desde
allí. En BDD, se escribe una prueba que puede satisfacer tanto al desarrollador como al cliente, pero en
TDD se escribe una prueba que solo satisfará a un desarrollador y el código que escriben.
Agile Methodology
Test in Agile
● A diferencia del método WaterFall, las pruebas ágiles pueden comenzar al inicio del proyecto con una
integración continua entre el desarrollo y las pruebas. La prueba Agile no es secuencial (en el sentido
de que se ejecuta solo después de la fase de codificación), sino continua.
● Un equipo ágil trabaja como un solo equipo hacia un objetivo común de lograr la Calidad. La prueba
Agile tiene marcos de tiempo más cortos llamados iteraciones (por ejemplo, de 1 a 4 semanas). Esta
metodología también se denomina lanzamiento o enfoque impulsado por la entrega, ya que
proporciona una mejor predicción sobre los productos viables en un corto período de tiempo.
Agile Methodology
Test in Agile
● Durante la primera etapa o iteración 0, realiza tareas de configuración inicial. Incluye la identificación
de personas para las pruebas, la instalación de herramientas de pruebas, la programación de recursos
(laboratorio de pruebas de usabilidad), etc.
● Por ejemplo:
○ Establecimiento de un caso de negocio para el proyecto.
○ Establecer las condiciones de contexto-negocio y el alcance del proyecto.
○ Resuma los requisitos clave y los casos de uso que impulsarán las concesiones de diseño
○ Esquema de una o más arquitecturas candidatas
○ Identificar el riesgo.
○ Estimación de costos y preparación de un proyecto preliminar.
Agile Methodology
Test in Agile/Etapas
● 1. Pruebas unitarias
● 2. Pruebas component
● 3. Prueba de ejemplos de posibles escenarios y flujos de trabajo.
● 4. Pruebas de experiencia de usuario como prototipos.
● 5. Prueba de par
● 6. Pruebas de usabilidad
● 7. Pruebas exploratorias
● 8. Pruebas de pares con clientes
● 9. Pruebas colaborativas.
● 10. Pruebas de aceptación del usuario.
● 11. Pruebas no funcionales como pruebas de estrés y rendimiento.
● 12. Pruebas de seguridad con respecto a la autenticación y piratería.
● 13. Pruebas de infraestructura
● 14. Pruebas de migración de datos.
● 15. Pruebas de escalabilidad
● 16. Pruebas de carga
Agile Methodology
Test in Agile
● Las pruebas ágiles implican realizar pruebas lo antes posible en el ciclo de vida del desarrollo del
software. Exige una alta participación del cliente y un código de prueba tan pronto como esté
disponible. El código debe ser lo suficientemente estable como para llevarlo a las pruebas del
sistema. Se pueden realizar extensas pruebas de regresión para asegurarse de que los errores se
corrigen y se prueban. Principalmente, ¡la comunicación entre los equipos hace que las pruebas sean
ágiles!
Agile Methodology
Scrum Testing
● Scrum tiene un calendario corto y fijo de ciclos de lanzamiento con alcance ajustable conocido como
sprints para abordar las cambiantes necesidades de desarrollo. Cada lanzamiento podría tener
múltiples sprints. Cada Proyecto Scrum podría tener múltiples Ciclos de Lanzamiento.
● Una secuencia repetitiva de reuniones, eventos e hitos.
● Una práctica de probar e implementar nuevos requisitos, conocidos como historias, para asegurarse
de que el trabajo se libere listo después de cada Sprint.
● Roles en Scrum
● Existen tres funciones principales en Scrum Testing: propietario del producto, Scrum Master y el
equipo de desarrollo. Vamos a estudiarlos en detalle.
Agile Methodology
Scrum Testing
● Dueño del producto:
○ Define las características del producto.

○ Decide la fecha de lanzamiento y las características correspondientes
○ Priorizan las características según el valor de mercado y la rentabilidad del producto.
○ Es responsable de la rentabilidad del producto.
○ Puede aceptar o rechazar el resultado del elemento de trabajo.
Agile Methodology
Scrum Testing
● Scrum Master
○ Dirige el equipo y cuida la productividad del equipo.
○ Mantiene la lista de bloqueo y elimina barreras en el desarrollo.
○ Coordina con todos los roles y funciones.
○ Protege al equipo de interferencias externas.
○ Invita al scrum diario, revisión de sprint y reuniones de planificación.
Agile Methodology
Scrum Testing
● El equipo
○ El equipo suele ser de unos 5-9 miembros.
○ Incluye desarrolladores, diseñadores y, a veces, probadores, etc.
○ El equipo organiza y programa su trabajo por su cuenta.
○ Tiene derecho a hacer todo dentro de los límites del proyecto para cumplir con el
objetivo del sprint
○ Participar activamente en las ceremonias diarias.
Agile Methodology
Scrum Testing
● Artefactos Scrum
○ Historias de usuario: son una breve explicación de las funcionalidades del sistema bajo prueba.
El ejemplo para el proveedor de seguros es: "La prima se puede pagar utilizando el sistema en
línea".
○ Product Backlog: es una colección de historias de usuario capturadas para un producto scrum.
El propietario del producto prepara y mantiene la cartera de productos. El propietario del
producto lo prioriza y cualquiera puede agregarlo con la aprobación del propietario del
producto.
○ Publicación de trabajos pendientes: Un lanzamiento es un período de tiempo en el que se
completa el número de iteraciones. El propietario del producto coordina con el scrum master
para decidir qué historias deben ser seleccionadas para un lanzamiento. Las historias en la
acumulación de lanzamientos están destinadas a completarse en un lanzamiento.
○ Sprints: es un período de tiempo establecido para completar las historias de usuario, decididas
por el propietario del producto y el equipo de desarrolladores, generalmente de 2 a 4 semanas
de tiempo.
Agile Methodology
Scrum Testing
● Artefactos Scrum
○ Sprint Backlog: es un conjunto de historias de usuario que se completan en un sprint. Durante el
backlog, el trabajo nunca se asigna y el equipo se registra para trabajar por su cuenta. Es
propiedad del equipo y lo administra, mientras que el trabajo estimado restante se actualiza
diariamente. Es la lista de tareas que se debe realizar en Sprint.
○ Lista de bloqueos: es una lista de bloques y decisiones no tomadas propiedad de scrum master
y que se actualiza diariamente.
○ Gráfico de reducción: el gráfico de reducción representa el progreso general del trabajo en
progreso y el trabajo completado a lo largo del proceso. Representa en formato gráfico las
historias y características no completadas.
Agile Methodology
Scrum Testing
● Ceremonias (Procesos) en Scrum

○ Planificación de Sprint: un sprint comienza con el equipo que importa historias desde el registro
de la versión al backlog de sprint; es alojado por scrum master. Los evaluadores estiman el
esfuerzo para probar las diversas historias en el Registro de Sprint.
○ Daily Scrum: está alojado por scrum master, dura unos 15 minutos. Durante el Daily Scrum, los
miembros discutirán el trabajo completado el día anterior, el trabajo planificado para el día
siguiente y los problemas que se enfrentaron durante un sprint. Durante la reunión diaria se
realiza un seguimiento del progreso del equipo.
○ Revisión de Sprint / Retrospectiva: también está organizada por scrum master, dura
aproximadamente de 2 a 4 horas y discute lo que el equipo ha logrado en el último sprint y las
lecciones aprendidas.
Agile Methodology
Scrum Testing
● Papel del Tester en Scrum

○ Prueba de historia de usuario cuando se completa. La ejecución de la prueba se realiza en un
laboratorio donde el probador y el desarrollador trabajan mano a mano. Los defectos se
registran en la herramienta de gestión de defectos, que se realiza un seguimiento diario. Los
defectos pueden ser conferidos y analizados durante la reunión de scrum. Los defectos se
vuelven a probar tan pronto como se resuelven y se implementan para la prueba
○ Como Tester, él / ella asiste a todas las reuniones diarias para hablar.
○ Como Tester, él / ella puede traer cualquier elemento de la reserva que no pueda completarse
en el sprint actual y pasar al siguiente sprint
○ Tester es responsable del desarrollo de scripts de automatización. Él programa las pruebas de
automatización con el sistema de integración continua (CI). La automatización cobra
importancia debido a los cortos plazos de entrega. La automatización de pruebas se puede
lograr utilizando varias herramientas de código abierto o de pago disponibles en el mercado.
Esto resulta efectivo para garantizar que todo lo que necesita ser probado esté cubierto. Se
puede lograr una cobertura de prueba suficiente con una comunicación cercana con el equipo.
○ Revisar los resultados de automatización de CI y enviar informes a las partes interesadas.
Agile Methodology
Scrum Testing
● Papel del Tester en Scrum

○ Ejecución de pruebas no funcionales para historias de usuario aprobadas
○ Coordinar con el cliente y el propietario del producto para definir los criterios de aceptación para
las Pruebas de aceptación
○ Al final del sprint, el Tester también realiza pruebas de aceptación (UAT) en algunos casos y
confirma que el sprint actual está completo.
● Sprint Retrospectiva
○ Como Tester, descubrirá qué salió mal y qué salió bien en el sprint actual
○ Como Tester, identifica las lecciones aprendidas y las mejores prácticas.
Agile Methodology
Scrum Testing
● Informe de prueba
○ Los informes de métricas de Scrum Test proporcionan transparencia y visibilidad a los
interesados acerca del proyecto. Las métricas que se informan permiten que un equipo analice
su progreso y planifique su estrategia futura para mejorar el producto. Hay dos métricas que se
utilizan con frecuencia para informar.
○ Gráfico burndown : cada día, Scrum Master registra el trabajo restante estimado para el sprint.
Esto no es más que el gráfico de Burn Down. Se actualiza diariamente.
○ Un cuadro de quema proporciona una visión general rápida del progreso del proyecto, este
cuadro contiene información como la cantidad total de trabajo en el proyecto que se debe
completar, la cantidad de trabajo completado durante cada sprint y así sucesivamente.
○ Gráfico Velocity history: el gráfico de historial de velocidad predice la velocidad del equipo
alcanzado en cada sprint. Es un gráfico de barras y representa cómo la producción de los
equipos ha cambiado con el tiempo.
Agile Methodology
Automation Testing for Agile Methodology
● Cómo automatizar en metodología ágil:

● Ahora, por su propia definición, la metodología ágil se refiere a eliminar la documentación laboriosa y
tediosa para que se puedan implementar ideas nuevas e innovadoras y que las personas puedan
interactuar libremente entre sí para poder implementar más de estas ideas innovadoras y
exploradoras.
● Por lo tanto, debemos considerar ciertos puntos fundamentales aquí cuando se trata de evaluar el uso
de metodologías ágiles con respecto a los métodos y técnicas de pruebas de automatización. Por lo
tanto, debemos tener en cuenta algunos puntos fundamentales como el tiempo de diseño y
codificación, la validación de los scripts diseñados con los datos de prueba existentes y la adopción
de los mismos para la prueba (si las pruebas son de fines funcionales o de regresión). todos estos
eventos son para poder realizar todo lo necesario, necesitamos asegurarnos de que se requiera una
cantidad de tiempo considerable para estas tareas y en un entorno ágil donde un sprint promedio
toma un promedio de 1-2 semanas para completar y, por lo tanto, obviamente, es demasiado difícil de
contemplar el proporcionar tanto tiempo para automatizar los scripts de tal manera.
Agile Methodology
● Otro factor importante sigue siendo el tipo de cambios en los requisitos que entran en escena cuando
la metodología ágil está en juego. La metodología ágil por su propia definición es un tipo de técnica
que es muy útil para responder a los requisitos de cambio rápido inducido por el cliente y que, por lo
tanto, se presta a cambios frecuentes durante el desarrollo general de la aplicación.
● En contraste, las pruebas de automatización son muy útiles cuando se trata de tipos de requisitos
más estables y menos frecuentes. Por lo tanto, por definición, las pruebas de automatización no se
prestan bien a varios tipos de cambios frecuentes en los requisitos que se presentan junto con la
adopción de metodologías ágiles.
Agile Methodology
● Herramientas de automatización:
● La selección de la herramienta de automatización relevante también es un factor potencialmente muy

importante cuando se trata de la adopción de pruebas de automatización dentro del alcance de una
metodología ágil en general. Las herramientas de automatización con licencia, por ejemplo, imponen
un estricto criterio de acceso de seguridad a diferentes tipos y niveles de usuarios cuando se trata de
acceder a varios recursos importantes que pertenecen a ese marco de automatización de pruebas en
particular.
● En contraste, la metodología ágil se enfoca principalmente en la colaboración abierta y la interacción
abierta entre los miembros del equipo y, por lo tanto, las políticas restrictivas que afectan
directamente la forma en que los usuarios tendrían un impacto negativo en la cohesión general dentro
del equipo y, por lo tanto, pueden conducir a resultados que no son muy buenos. Útil ni muy propicio
para el éxito general del proyecto.
Agile Methodology
Scaled Agile Framework (SAFe)
● SAFe es el framework líder mundial para escalar Agile en toda la empresa. Usado por cientos de las
organizaciones más grandes del mundo, SAFe sostiene y conduce más rápido al mercado, aumentos
dramáticos en la productividad y calidad, y mejora en el compromiso de los empleados.
● SAFe está diseñado para ayudar a las empresas a entregar valor de manera continua y más eficiente
en un horario regular y predecible. Proporciona una base de conocimientos de principios y prácticas
probadas e integradas para respaldar la agilidad empresarial.
● Una clave importante para el éxito en el apoyo a una transformación Lean-Agile es el compromiso del
liderazgo combinado con la educación y la capacitación. El currículo basado en roles de Scaled Agile
ayuda a las empresas a desbloquear resultados de negocios con SAFe. La Suscripción a Aprendices
de SAFe® está diseñada para ayudar a las empresas a vincular la estrategia con la ejecución
mediante la capacitación de líderes empresariales y técnicos, arquitectos y desarrolladores en
prácticas Lean-Agile.
Tool Types Support for Testing
Test Tool Classification
● Clasificación de los diferentes tipos de herramientas de prueba según las actividades del proceso de
prueba.
● Las herramientas se agrupan por actividades de prueba o áreas que son compatibles con un conjunto
de herramientas, por ejemplo, herramientas que admiten actividades de administración, herramientas
para soportar pruebas estáticas, etc.
● Herramienta de soporte para la gestión de pruebas :

○ Herramientas de manejo de prueba
○ Herramientas de gestión de requisitos.
○ Herramientas de gestión de incidencias
○ Herramientas de gestión de configuración
● Soporte de herramientas para pruebas estáticas:

○ Revisar herramientas de soporte de procesos.
○ Herramientas de análisis estático.
○ Herramientas de modelado.
● Soporte de herramientas para especificación de prueba:

○ Herramientas de diseño de prueba
○ Herramientas de preparación de datos de prueba.
● Soporte de herramientas para ejecución de prueba y registro:

○ Herramientas de ejecución de prueba.
○ Arnés de prueba / Herramientas de armazón de prueba unitaria.
○ Comparadores de prueba.
○ Herramientas de medición de cobertura.
○ Herramientas de seguridad.
● Soporte de herramientas para el desempeño y monitoreo:

○ Herramientas de análisis dinámico.
○ Pruebas de rendimiento, pruebas de carga y herramientas de pruebas de estrés.
○ Herramientas de monitoreo.
Testing Tools
Selenium
● Selenium es una popular herramienta de automatización de pruebas de software basada en web de

código abierto.
● Principalmente, es para automatizar aplicaciones web con fines de prueba, pero ciertamente no se
limita a eso. Las tareas de administración aburridas basadas en la Web pueden (y deberían) ser
automatizadas también.
● Selenium tiene el soporte de algunos de los proveedores más grandes de navegadores que han
tomado (o están tomando) pasos para hacer de Selenium una parte nativa de su navegador. También
es la tecnología principal en muchas otras herramientas de automatización del navegador, API y
frameworks..
Testing Tools
Cucumber
● Cucumber es una herramienta que admite el desarrollo guiado por el comportamiento (BDD).
● Cucumber lee especificaciones ejecutables escritas en texto plano y valida que el software haga lo
que dichas especificaciones dicen. Las especificaciones consisten en múltiples ejemplos, o
escenarios. Por ejemplo:
○ Feature: Buscar Epidata en google
As a human
I want to search Epidata en Google
So I can find GenvetaDev website
Scenario: Search for Epidata
Given I have visited Google
When I search for "Epidata"
Then I see "Epidata"
○
Testing Tools
Py Robot Framework
● Es un Framework genérico de automatización de código abierto para pruebas de aceptación, desarrollo

dirigido por pruebas de aceptación (ATDD) y automatización de procesos robóticos (RPA). Tiene una simple
sintaxis de texto sin formato y se puede ampliar fácilmente con bibliotecas implementadas con Python o Java.
● Es un sistema operativo y aplicación independiente. El marco central se implementa utilizando Python, es
compatible con Python 2 y Python 3, y también se ejecuta en Jython (JVM), IronPython (.NET) y PyPy. El marco
tiene un rico ecosistema a su alrededor que consta de varias bibliotecas genéricas y herramientas que se
desarrollan como proyectos separados. Para obtener más información sobre Robot Framework y el
ecosistema, consulte http://robotframework.org.
Testing Tools
Postman
● Postman es actualmente una de las herramientas más populares utilizadas en las pruebas de API. Comenzó
en 2012 como un proyecto paralelo de Abhinav Asthana para simplificar el flujo de trabajo de API en las
pruebas y el desarrollo. API significa Interfaz de programación de aplicaciones, que permite que las
aplicaciones de software se comuniquen entre sí mediante llamadas API.
● ¿Qué es una API?

● API es un acrónimo de Application Programming Interface.
●
● Permite la comunicación y el intercambio de datos entre dos sistemas de software separados. Un sistema de
software que implementa una API contiene funciones / subrutinas que pueden ser ejecutadas por otro sistema
de software.
Testing Tools
Soap UI
● SoapUI es el líder del mercado en API Testing Tool. Puede realizar pruebas funcionales, de carga, de seguridad
y de cumplimiento en su API utilizando SoapUI.
Testing Tools
Jmeter
● Es un software de código abierto puro de Java, que fue desarrollado por primera vez por Stefano Mazzocchi de
Apache Software Foundation, diseñado para cargar el comportamiento funcional de la prueba y medir el
rendimiento. Puede utilizar JMeter para analizar y medir el rendimiento de una aplicación web o una variedad
de servicios. Las pruebas de rendimiento implican probar una aplicación web contra el tráfico de usuarios con
cargas pesadas, múltiples y concurrentes. JMeter originalmente se usa para probar aplicaciones web o
aplicaciones FTP. Hoy en día, se utiliza para una prueba funcional, prueba de servidor de base de datos, etc.
Testing Tools
BlazeMeter
● BlazeMeter ofrece un Framework de automatización de pruebas entre empresas para todo el equipo técnico a
lo largo del ciclo de vida del desarrollo del producto. Los desarrolladores, DevOps, Ops y los ingenieros de
control de calidad pueden ejecutar pruebas continuas o "bajo demanda" para API, aplicaciones móviles y sitios
web. BlazeMeter se puede utilizar en la nube, en las instalaciones o como una solución híbrida. Es compatible
con Apache JMeter y Selenium y se integra con herramientas de CI, CD.
Continuous Integration
Definition
● La prueba continua se define como un tipo de prueba de software que involucra un proceso de prueba
temprana, prueba frecuente, prueba en todas partes y automatizadas. Es una estrategia de evaluación de la
calidad en cada paso del proceso de entrega continua. El objetivo de la prueba continua es realizar una prueba
temprana y una prueba frecuente. El proceso involucra a partes interesadas como desarrollador, DevOps,
control de calidad y sistema operativo.
● Continuo significa pruebas ininterrumpidas realizadas de forma continua. En un proceso continuo de DevOps,
un cambio de software (versión candidata) se mueve continuamente de Desarrollo a Pruebas a
Implementación.
● El código es continuamente desarrollado, entregado, probado y desplegado.
Definition
● Por ejemplo, cada vez que un desarrollador verifica el código en el servidor de código fuente como Jenkins, las
pruebas unitarias automatizadas se ejecutan en el proceso continuo. Si las pruebas fallan, la compilación se rechaza
y se notifica al desarrollador. Si la compilación pasa la prueba, se implementa en servidores de control de calidad y
rendimiento para pruebas funcionales y de carga exhaustivas. Las pruebas se ejecutan en paralelo. Si las pruebas
pasan, el software se implementa en producción.
Benefits
● La prueba continua mejora la calidad del código

● Ayuda a evaluar la cobertura exacta de riesgo de negocio.
● Se integra perfectamente en DevOps Process.
● Ayuda a crear un proceso ágil y confiable en tan solo horas en lugar de meses.
● Acelera el tiempo de comercialización con un mecanismo de retroalimentación continua.
● Fusiona los equipos tradicionalmente en silos para satisfacer las necesidades empresariales modernas.
Disuelve la desconexión entre los equipos de desarrollo, pruebas y operaciones.
● Automatización de pruebas ayuda a lograr consistencia al mantener la misma configuración para todas las
pruebas relevantes.
● Enfatiza las expectativas del negocio para mitigar los riesgos del mismo.
Tools
● Jenkins :es una herramienta de integración continua que se escribe usando el lenguaje Java. Esta herramienta
se puede configurar a través de la interfaz GUI o los comandos de la consola.
● Bamboo :es un servidor de integración continua (CI) que se puede utilizar para automatizar la administración
de la versión de una aplicación de software, creando un flujo de entrega continua.
● Docker :admite la implementación de CI / CD al permitir a los desarrolladores crear código en colaboración a
través del intercambio de imágenes y simplificar la implementación en diferentes infraestructuras. Con Docker
Enterprise, puede desarrollar una práctica de DevOps que se integra con las herramientas de CI que elija,
cualquier pila de aplicaciones que se ejecute en Linux o Windows, en cualquier infraestructura, local, en la nube
o ambas.
● Pipelines: Como su nombre indica, un flujo de entrega continua es una implementación del paradigma
continuo, donde las compilaciones, pruebas y despliegues automatizados se organizan como un flujo de
trabajo de una versión. Dicho de manera más clara, una tubería de CD es un conjunto de pasos por los que
pasará su código de cambios para llegar a la producción.
● Un paquete de CD entrega, según las necesidades del negocio, productos de calidad con frecuencia y de
manera predecible desde la prueba hasta la puesta en escena y la producción de manera automatizada.
● Los tres conceptos: calidad, frecuencia y predeciblemente.
GIT
Definition
● Git es un sistema de control de versiones distribuido, gratuito y de código abierto, diseñado para manejar todo,
desde proyectos pequeños hasta proyectos muy grandes con rapidez y eficiencia.
● Git es fácil de aprender y tiene un rendimiento increíblemente rápido. Supera las herramientas de SCM como
Subversion, CVS, Perforce y ClearCase con características como bifurcaciones locales baratas, áreas de
preparación convenientes y múltiples flujos de trabajo.
GIT
Version Control
● ¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que
registra los cambios en un archivo o conjunto de archivos a lo largo del tiempo para que pueda recuperar
versiones específicas más adelante. Aunque los ejemplos en este libro muestran el código fuente del software
como los archivos bajo control de versión, en realidad cualquier tipo de archivo en una computadora puede
colocarse bajo control de versión.
● Es muy conveniente utilizar un Sistema de control de versiones (VCS). Un VCS le permite: revertir archivos a un
estado anterior, revertir todo el proyecto a un estado anterior, revisar los cambios realizados con el tiempo, ver
quién modificó por última vez algo que podría estar causando un problema, quién presentó un problema y
cuándo, y Más. Usar un VCS también significa que si arruinas o pierdes archivos, generalmente puedes
recuperarte fácilmente.
● El método preferido de control de versiones de muchas personas es copiar archivos en otro directorio (tal vez
un directorio con marca de tiempo, si son inteligentes). Este enfoque es muy común porque es muy simple,
pero también es increíblemente propenso a errores. Es fácil olvidar en qué directorio se encuentra y escribir
accidentalmente en el archivo incorrecto o copiar sobre los archivos que no quiere.
● Para lidiar con este problema, los programadores hace mucho tiempo desarrollaron VCS locales que tenían
una base de datos simple que mantenía todos los cambios a los archivos bajo el control de revisión
GIT
Version Control
● Aquí es donde intervienen los Sistemas de control de versiones distribuidas (DVCS). En un DVCS (como Git,
Mercurial, Bazaar o Darcs), los clientes no solo verifican la última instantánea de los archivos: reflejan
completamente el repositorio. Por lo tanto, si algún servidor muere y estos sistemas colaboran a través de él,
cualquiera de los repositorios de clientes se puede copiar de nuevo en el servidor para restaurarlo. Cada salida
es realmente una copia de seguridad completa de todos los datos.
● Además, muchos de estos sistemas se ocupan bastante bien de tener varios repositorios remotos con los que
pueden trabajar, por lo que puede colaborar con diferentes grupos de personas de diferentes maneras
simultáneamente dentro del mismo proyecto. Esto le permite configurar varios tipos de flujos de trabajo que
no son posibles en los sistemas centralizados.
GIT
Branch
● Es una característica disponible en la mayoría de los sistemas modernos de control de versiones. La

ramificación en otros VCS puede ser una operación costosa tanto en tiempo como en espacio en disco. En Git,
las ramificaciones/branchs son parte de su proceso de desarrollo diario. Las ramas de Git son efectivamente
un puntero a una instantánea de sus cambios. Cuando desea agregar una nueva característica o corregir un
error, sin importar qué tan grande o pequeño sea, genera una nueva rama para encapsular sus cambios. Esto
hace que sea más difícil que el código inestable se fusione con la base del código principal, y le da la
oportunidad de limpiar el historial de su futuro antes de fusionarlo con la rama principal.
GIT
Branch
● El diagrama de arriba muestra un repositorio con dos líneas de desarrollo aisladas, una para una pequeña
característica y una para una característica de ejecución más larga. Al desarrollarlos en las ramas, no solo es posible
trabajar en ambos en paralelo, sino que también mantiene la rama principal libre de código cuestionable.
GIT
Branch
● Una rama representa una línea de desarrollo independiente. Las ramas sirven como una abstracción para el proceso
de edición / etapa / confirmación. Puede pensar en ellos como una forma de solicitar un nuevo directorio de trabajo,
área de preparación e historial de proyectos. Los nuevos compromisos se registran en el historial de la rama actual, lo
que resulta en una bifurcación en el historial del proyecto.
● El comando git branch le permite crear, listar, renombrar y eliminar ramas. No le permite cambiar entre ramas o volver
a unir el historial bifurcado. Por esta razón, git branch está estrechamente integrado con los comandos git checkout y
git merge.
GIT
Basics/git init
● Inicializando un nuevo repositorio: git init

● Para crear un nuevo repositorio, usarás el comando git init. git init es un comando de una sola vez que se usa durante
la configuración inicial de un nuevo repositorio. La ejecución de este comando creará un nuevo subdirectorio .git en
su directorio de trabajo actual. Esto también creará una nueva rama maestra.
○ cd /path/to/your/existing/code
○ git init
● Si señala git init a un directorio de proyecto existente, se ejecutará la misma configuración de inicialización que se
mencionó anteriormente, pero dentro del alcance de ese directorio de proyecto.
○ git init <project directory>
GIT
Basics/git clone
● Clonando un repositorio existente: git clone

● Si un proyecto ya se ha configurado en un repositorio central, el comando de clonación es la forma más común para
que los usuarios obtengan un clon de desarrollo local. Como git init, la clonación es generalmente una operación de
una sola vez. Una vez que un desarrollador ha obtenido una copia de trabajo, todas las operaciones de control de
versión se administran a través de su repositorio local.
○ git clone <repo url>
● Si usariamos el protocolo Git SSH. Las URL de Git SSH siguen una plantilla de: git @ HOSTNAME: USERNAME /
REPONAME.git
● Cuando se ejecute, la última versión de los archivos de repositorio remotos en la rama maestra se bajará y se
agregará a una nueva carpeta. La nueva carpeta llevará el nombre de REPONAME. La carpeta contendrá el historial
completo del repositorio remoto y una rama maestra recién creada.
GIT
Basics/git add , git commit
● cd /path/to/project
echo "test content for git tutorial" >> CommitTest.txt
git add CommitTest.txt
git commit -m "added CommitTest.txt to the repo"
● Después de ejecutar este ejemplo, su repositorio ahora tendrá CommitTest.txt agregado al historial y hará un
seguimiento de las actualizaciones futuras del archivo.
GIT
Best Practices
● Mejores Prácticas de Control de Versiones

○ Commit cambios relacionados
○ Un commit debe ser un contenedor para los commit relacionados. Por ejemplo, corregir dos errores diferentes
debería producir dos commit separadas. Los pequeños commit facilitan que otros miembros del equipo
entiendan los cambios y los restituyan si algo sale mal. Con herramientas como el área de preparación y la
capacidad de organizar solo partes de un archivo, Git facilita la creación de commit muy granulares.
○ Commit frecuente
○ A menudo, comprometase a mantener sus commit pequeños ,le ayuda a confirmar solo los cambios
relacionados. Además, le permite compartir su código con más frecuencia con otros. De esa manera, es más
fácil para todos integrar los cambios regularmente y evitar tener conflictos de fusión. Tener pocos commit
grandes y compartirlos raramente, en contraste, hace que sea difícil tanto resolver los conflictos como
comprender lo que sucedió.
○ No subas/commit un trabajo a medio hacer
GIT
Best Practices

○ No subas/commit un trabajo a medio hacer:
○ Solo debes hacer commit del código cuando se complete. Esto no significa que tenga que completar una
característica grande y completa antes de hacer commit. Muy por el contrario: divida la implementación de la
característica en partes lógicas y recuerde que debe hacer commit pronto y con frecuencia. Pero no se
comprometa a tener algo en el repositorio antes de salir de la oficina al final del día. Si está tentado a hacer
commit solo porque necesita una copia de trabajo limpia (para revisar una rama, introducir cambios, etc.)
considere utilizar la función "Stash" de Git.
○ Prueba antes de hacer commit:
○ Resista la tentación de hacer commit a algo que usted "piensa" se completa. Pruébelo a fondo para asegurarse
de que realmente esté completo y no tenga efectos secundarios (por lo que se puede decir). Aunque hacer
commit a cosas a medias en tu repositorio local solo requiere que te perdones a ti mismo, tener tu código
probado es aún más importante cuando se trata de enviar / compartir tu código con otros.
GIT
Best Practices

○ Escribir buenos mensajes en el commit::
○ Comience su mensaje con un breve resumen de sus cambios (hasta 50 caracteres como guía). Sepáralo del
siguiente cuerpo incluyendo una línea en blanco. El cuerpo de su mensaje debe proporcionar respuestas
detalladas a las siguientes preguntas: ¿Cuál fue la motivación para el cambio? ¿En qué se diferencia de la
implementación anterior? Use el imperativo, el tiempo presente ("cambio", no "cambiado" o "cambios") para ser
coherente con los mensajes generados desde comandos como git merge.
○ El control de versiones no es un sistema de respaldo:
○ Utilizar ramas/branchs:
○ La ramificación es una de las características más poderosas de Git, y esto no es por accidente: la ramificación
rápida y fácil fue un requisito central desde el primer día. Las ramas son la herramienta perfecta para ayudarlo
a evitar mezclar diferentes líneas de desarrollo. Debe usar ramas ampliamente en sus flujos de trabajo de
desarrollo: para nuevas funciones, correcciones de errores, experimentos, ideas ...
GIT
Best Practices

○ Acordar un flujo de trabajo:
○ Git le permite elegir entre una gran cantidad de flujos de trabajo diferentes: ramas de larga ejecución, ramas
temáticas, fusionar o reajustar, git-flow.El que elija depende de un par de factores: su proyecto, sus flujos de
trabajo de desarrollo e implementación generales y (tal vez lo más importante) en tus preferencias personales
y las de tus compañeros. Independientemente de cómo elija trabajar, solo asegúrese de acordar un flujo de
trabajo común que todos sigan.
SQL
Data Bases
● Una base de datos (DB), en el sentido más general, es una colección organizada de datos. Más específicamente, una
base de datos es un sistema electrónico que permite acceder, manipular y actualizar fácilmente los datos.
● En otras palabras, una base de datos es utilizada por una organización como un método para almacenar, administrar
y recuperar información. Las bases de datos modernas se administran mediante un sistema de gestión de bases de
datos (DBMS).
SQL
Data Bases Managment System (DBMS)
● Significa "Sistema de gestión de base de datos". En resumen, un DBMS es un programa de base de datos.
Técnicamente hablando, es un sistema de software que utiliza un método estándar de catalogación, recuperación y
ejecución de consultas en datos. El DBMS administra los datos entrantes, los organiza y proporciona formas para que
los usuarios u otros programas modifiquen o extraigan los datos.
● Algunos ejemplos de DBMS incluyen MySQL, PostgreSQL, Microsoft Access, SQL Server, Oracle, RDBMS, dBASE.
Dado que hay tantos sistemas de gestión de bases de datos disponibles, es importante que haya una forma de
comunicarse entre ellos. Por esta razón, la mayoría del software de base de datos viene con un controlador de
Conectividad abierta de base de datos (ODBC) que permite que la base de datos se integre con otras bases de datos.
Por ejemplo, las sentencias de SQL comunes como SELECT e INSERT se convierten de la sintaxis propietaria de un
programa a una sintaxis que otras bases de datos pueden comprender.
SQL
Clasification - Models
● Los sistemas de gestión de bases de datos se pueden clasificar según varios criterios, como el modelo de datos, los
números de usuarios y la distribución de bases de datos, todo ello descrito a continuación.
● Clasificación basada en el modelo de datos:
○ El modelo de datos más popular en uso hoy en día es el modelo de datos relacionales. Los DBMS conocidos
como Oracle, MS SQL Server, DB2 y MySQL son compatibles con este modelo. Otros modelos tradicionales,
como los modelos de datos jerárquicos y los modelos de datos de red, todavía se utilizan en la industria,
principalmente en plataformas mainframe. Sin embargo, no se utilizan comúnmente debido a su complejidad.
Todos estos se conocen como modelos tradicionales porque precedieron al modelo relacional.
● En los últimos años, se introdujeron los nuevos modelos de datos orientados a objetos. Este modelo es un sistema
de gestión de bases de datos en el que la información se representa en forma de objetos tal como se utiliza en la
programación orientada a objetos. Las bases de datos orientadas a objetos son diferentes de las bases de datos
relacionales, que están orientadas a tablas. Los sistemas de gestión de bases de datos orientados a objetos
(OODBMS) combinan capacidades de base de datos con capacidades de lenguaje de programación orientado a
objetos.
SQL
● Clasificación basada en números de usuario:

○ Un DBMS puede ser una clasificación basada en la cantidad de usuarios que admite. Puede ser un sistema de
base de datos de un solo usuario, que admite un usuario a la vez, o un sistema de base de datos multiusuario,
que admite múltiples usuarios al mismo tiempo.
● Clasificación basada en la distribución de la base de datos:

○ Hay cuatro sistemas de distribución principales para sistemas de bases de datos y estos, a su vez, se pueden
usar para clasificar el DBMS.
SQL
● Sistemas centralizados:
○ Con un sistema de base de datos centralizado, el DBMS y la base de datos se almacenan en

un solo sitio que también utilizan otros sistemas.
SQL
● Sistema de base de datos distribuida:
○ En un sistema de base de datos distribuida, la base de datos real y el software DBMS se
distribuyen desde varios sitios que están conectados por una red informática.
SQL
● Sistemas de bases de datos distribuidas homogéneas:

○ Los sistemas de bases de datos distribuidas homogéneas utilizan el mismo software DBMS desde
múltiples sitios. El intercambio de datos entre estos diversos sitios se puede manejar fácilmente.
Por ejemplo, los sistemas de información de bibliotecas del mismo proveedor, como Geac
Computer Corporation, utilizan el mismo software DBMS que permite un intercambio de datos
sencillo entre los distintos sitios de bibliotecas de Geac.
● Sistemas de bases de datos distribuidas heterogéneas:
○ En un sistema de base de datos distribuido heterogéneo, diferentes sitios pueden usar un
software DBMS diferente, pero hay un software común adicional para respaldar el
intercambio de datos entre estos sitios. Por ejemplo, los diversos sistemas de bases de
datos de bibliotecas utilizan el mismo formato de catalogación legible por máquina (MARC)
para admitir el intercambio de datos de registros de la biblioteca.
SQL
Tables, Records & Fields
● Una tabla es la construcción de organización básica de cualquier base de datos SQL. Una tabla es
lógicamente un conjunto de columnas que están "relacionadas" en el sentido de que pertenecen a la
misma tabla. Físicamente, los datos reales en una tabla consisten en Filas, que tienen valores
específicos, o NULL, para cada columna en la tabla.
● En la mayoría de los usos, una columna y un campo son cosas estrechamente relacionadas, ya que un
campo suele ser un valor único en una pantalla de entrada / visualización de datos o en un archivo de
entrada, y generalmente se asigna 1: 1 a un valor de columna en una base de datos
● Una fila es una entrada específica en una tabla. Una fila tendrá valores o estados nulos para cada
columna en una tabla dada..
SQL
Keys
● Una clave DBMS es un atributo o conjunto de un atributo que le ayuda a identificar una fila (tupla) en una
relación (tabla). Te permiten encontrar la relación entre dos tablas. Las claves le ayudan a identificar de
forma única una fila en una tabla mediante una combinación de una o más columnas en esa tabla.
Employee ID FirstName LastName
11 Andrew Johnson
22 Tom Wood
● En el ejemplo anterior, la ID del empleado es una clave principal porque identifica de forma única un
registro de empleado. En esta tabla, ningún otro empleado puede tener la misma ID de empleado.
SQL
Keys
● Las keys le ayudan a identificar cualquier fila de datos en una tabla. En una aplicación del mundo real, una
tabla podría contener miles de registros. Además, los registros podrían estar duplicados. Las keys
garantizan que pueda identificar de forma única un registro de tabla a pesar de estos desafíos.
● Le permite establecer una relación entre e identificar la relación entre tablas
● Ayudarte a hacer cumplir la identidad e integridad en la relación.
● DBMS tiene siete tipos de claves siguientes, cada una con su funcionalidad diferente:
○ Super clave,Clave primaria,Llave candidata,Clave alternativa,Clave externa,Llave compuesta,Clave
compuesta,Clave sustituta
● Una superclave es un grupo de teclas simples o múltiples que identifica filas en una tabla. Una Super
clave puede tener atributos adicionales que no son necesarios para una identificación única.
● EmpSSN EmpNum Empname
● 9812345098 AB05 Shown
●
● En el ejemplo anterior, EmpSSN y el nombre de EmpNum son superclaves.
SQL
Keys
● clave primaria:
○ Una columna o grupo de columnas en una tabla que nos ayuda a identificar de manera única
cada fila en esa tabla se llama clave principal. Este DBMS no puede ser un duplicado. El
mismo valor no puede aparecer más de una vez en la tabla.
● Dos filas no pueden tener el mismo valor de clave principal
● Debe para cada fila tener un valor de clave principal.
● El campo de clave principal no puede ser nulo.
● El valor en una columna de clave principal nunca se puede modificar o actualizar si alguna clave
externa se refiere a esa clave principal.
SQL
Keys
● En el siguiente ejemplo, StudID es una clave principal.
StudID Roll No First Name LastName Email
1 11 Tom Price abc@gmail.com

SQL
Keys
● Todas las claves que no son primarias se llaman claves alternativas. Es una clave candidata que
actualmente no es la clave principal. Sin embargo, una tabla puede tener opciones únicas o
múltiples para la clave principal.
● Ejemplo: En esta tabla:
○ StudID, Roll No, Email están calificados para convertirse en una clave principal. Pero como
StudID es la clave principal, Roll No, el correo electrónico se convierte en la clave alternativa.
StudID Roll No First Name LastName Email
1 11 Tom Price abc@gmail.com

SQL
Keys
● Una clave sin atributo repetido se llama clave candidata :

○ La clave principal debe seleccionarse de las claves candidatas. Cada tabla debe tener al
menos una clave candidata única.
● Propiedades de la clave del candidato:
○ Debe contener valores únicos.
○ La clave del candidato puede tener múltiples atributos
○ No debe contener valores nulos.
○ Debe contener campos mínimos para asegurar la singularidad.
○ Identificar de forma única cada registro en una tabla.
SQL
Keys
● En la tabla dada, Stud ID, Roll No y el correo electrónico son claves candidatas que nos ayudan a
identificar de forma única el registro del estudiante en la tabla.
SQL
Keys
● Una clave externa es una columna que se agrega para crear una relación con otra tabla. Las
claves externas nos ayudan a mantener la integridad de los datos y también permiten la
navegación entre dos instancias diferentes de una entidad. Todas las relaciones en el modelo
deben estar respaldadas por una clave externa.
DeptCode DeptName
001 Science
002 English
Teacher ID Fname Lname
B002 David Warner
B017 Sara Joseph

SQL
Keys
● En este ejemplo, tenemos dos tablas, enseñar y departamento en una escuela. Sin embargo, no
hay manera de ver qué búsqueda funciona en qué departamento.
● En esta tabla, al agregar la clave externa en Deptcode al nombre del Profesor, podemos crear una
relación entre las dos tablas.
Teacher ID DeptCode Fname Lname
B002 002 David Warner
B017 002 Sara Joseph

SQL
Keys
● La clave compuesta tiene muchos campos que le permiten reconocer de forma única un registro
específico. Es posible que cada columna no sea única por sí misma dentro de la base de datos. Sin
embargo, cuando se combina con la otra columna o columnas, la combinación de claves compuestas se
vuelve única.
OrderNo PorductID Product Name Quantity
B005 JAP102459 Mouse 5
B005 DKT321573USB 10
B005 OMG446789 LCD Monitor 20
● En este ejemplo, OrderNo y ProductID no pueden ser una clave principal, ya que no identifica de
forma única un registro. Sin embargo, se podría utilizar una clave compuesta de ID de pedido e ID
de producto, ya que identificaba de forma única cada registro.
SQL
Keys
● Una clave artificial que tiene como objetivo identificar de forma única cada registro se denomina
clave sustituta. Este tipo de clave es única porque se crea cuando no tiene ninguna clave principal
natural. No le dan ningún significado a los datos en la tabla. La clave sustituta suele ser un
número entero.}
Fname Lastname Start Time End Time
Anne Smith 09:00 18:00
Jack Francis 08:00 17:00
● Arriba, dado el ejemplo, se muestran los tiempos de turno de los diferentes empleados. En este ejemplo,
se necesita una clave sustituta para identificar de manera única a cada empleado.Se permiten llaves
sustitutas cuando ninguna propiedad tiene el parámetro de la clave primaria.En la tabla cuando la clave
principal es demasiado grande o complicada.
SQL
Relationship & Constraints
● El modelo relacional representa la base de datos como una colección de relaciones. Una relación no es
más que una tabla de valores. Cada fila en la tabla representa una colección de valores de datos
relacionados. Estas filas en la tabla denotan una entidad o relación del mundo real.
● El nombre de la tabla y los nombres de las columnas son útiles para interpretar el significado de los
valores en cada fila. Los datos se representan como un conjunto de relaciones. En el modelo relacional,
los datos se almacenan como tablas. Sin embargo, el almacenamiento físico de los datos es
independiente de la forma en que los datos están organizados lógicamente.
SQL
● Las restricciones de integridad relacional se refieren a condiciones que deben estar presentes para una
relación válida. Estas restricciones de integridad se derivan de las reglas en el mini-mundo que representa
la base de datos.
● Hay muchos tipos de restricciones de integridad. Las restricciones en el sistema de gestión de la base de
datos relacional se dividen principalmente en tres categorías principales:
○ Restricciones de dominio
○ Limitaciones clave
○ Restricciones de integridad referencial
SQL
● Las restricciones de dominio pueden violarse si el valor de un atributo no aparece en el dominio

correspondiente o no es del tipo de datos apropiado.Las restricciones de dominio especifican que dentro
de cada tupla, y el valor de cada atributo debe ser único. Esto se especifica como tipos de datos que
incluyen tipos de datos estándar, enteros, números reales, caracteres, booleanos, cadenas de longitud
variable, etc.
● Crear DOMINIO CustomerName.
● Check (valor no NULL)
● El ejemplo se muestra la creacion de una restriccion de dominio tal que CustomerName no es NULL.
SQL
DDL – DML – DCL – DTL
● DDL es el nombre corto de Data Definition Language, que trata de esquemas y descripciones de la base
de datos, de cómo deben residir los datos en la base de datos.CREAR: para crear una base de datos y sus
objetos como (tabla, índice, vistas, procedimiento de almacenamiento, función y activadores)
● ALTER - altera la estructura de la base de datos existente
● DROP - eliminar objetos de la base de datos
● TRUNCATE: elimina todos los registros de una tabla, incluidos todos los espacios asignados para
los registros que se eliminan
● COMENTARIO - añadir comentarios al diccionario de datos
● RENOMBRAR - renombrar un objeto
SQL
● DML es el nombre corto de Data Manipulation Language que se ocupa de la manipulación de datos
e incluye las sentencias de SQL más comunes, como SELECT, INSERT, UPDATE, DELETE, etc., y se
utiliza para almacenar, modificar, recuperar, eliminar y actualizar datos en una base de datos:
● SELECCIONAR - recuperar datos de una base de datos
● INSERTAR - insertar datos en una tabla
● ACTUALIZACIÓN - actualiza los datos existentes dentro de una tabla
● ELIMINAR - Eliminar todos los registros de una tabla de base de datos
● MERGE - Operación UPSERT (insertar o actualizar)
● LLAMADA - llamar a un subprograma PL / SQL o Java
● PLAN DE EXPLICACIÓN - interpretación de la ruta de acceso a los datos
● TABLA DE BLOQUEO - Control de concurrencia
SQL
● DCL es el nombre corto de Data Control Language, que incluye comandos como GRANT y está
relacionado principalmente con los derechos, permisos y otros controles del sistema de base de datos.
● GRANT - permite a los usuarios acceder a los privilegios de la base de datos
● REVOKE: retire los privilegios de acceso de los usuarios mediante el uso del comando GRANT.
● TCL es el nombre corto de Transaction Control Language que trata con una transacción dentro de una
base de datos.
● COMPROMISO - comete una transacción.ROLLBACK - deshacer una transacción en caso de que ocurra
algún error.
● SAVEPOINT - para deshacer la transacción haciendo puntos dentro de grupos.
● SET TRANSACTION - Especifique las características de la transacción.
SQL
Logical & Comparison operators
● Operadores aritméticos de SQL:

○ + Añadir
○ - Restar
○ * Multiplica
○ / Dividir
○ % Modulo
● Operadores de bitwise SQL
○ & Bitwise Y
○ | Bitwise o
○ ^ Exclusivo bitwise OR
SQL
● Operadores de comparación de SQL:

○ = Igual a
○ > Mayor que
○ <Menos que
○ > = Mayor o igual que
○ <= Menor o igual que
○ <> No es igual a
● Operadores de compuestos SQL
○ + = Añadir iguales
○ - = restar es igual a
○ * = Multiplicar es igual a
○ / = Divide es igual a
○ % = Modulo es igual a
○ & = Bitwise Y es igual
○ ^ - = Bitwise exclusivo es igual a
○ | * = Bitwise O es igual a
SQL
● Operadores lógicos SQL:

○ ALL TRUE si todos los valores de subconsulta cumplen la condición
○ AND TRUE si todas las condiciones separadas por AND son TRUE
○ ANY TRUE si alguno de los valores de la subconsulta cumple la condición
○ BETWEEN TRUE si el operando está dentro del rango de comparaciones
○ EXISTS TRUE si la subconsulta devuelve uno o más registros
○ IN TRUE si el operando es igual a uno de una lista de expresiones
○ LIKE TRUE si el operando coincide con un patrón
○ NOT Muestra un registro si la (s) condición (es) NO ES VERDADERA
○ OR TRUE si alguna de las condiciones separadas por OR es VERDADERA
○ SOME TRUE si alguno de los valores de la subconsulta cumple la condición
Certifications Carrers
ISTQB Foundation Level
● The Certified Tester Foundation Level en Pruebas de SoftwareLa calificación de Nivel de Fundación está
dirigida a cualquier persona involucrada en las pruebas de software. Esto incluye personas en roles como
evaluadores, analistas de pruebas, ingenieros de pruebas, consultores de pruebas, gerentes de pruebas,
evaluadores de aceptación de usuarios y desarrolladores de software.Esta calificación de Nivel de
Fundación también es adecuada para cualquier persona que desee una comprensión básica de las
pruebas de software, como los gerentes de proyectos, gerentes de calidad, gerentes de desarrollo de
software, analistas de negocios, directores de TI y consultores de administración. Los titulares del
Certificado de Fundación podrán pasar a una calificación de prueba de software de nivel superior.
IISTQB Expert Level
● El Nivel de Experto amplía el conocimiento y la experiencia obtenida en el Nivel Avanzado al proporcionar

certificaciones exhaustivas y orientadas a la práctica en una variedad de diferentes temas de prueba. Con
el nivel experto, ISTQB® ofrece trayectorias profesionales para los evaluadores con resultados
empresariales claramente definidos.
ITIL Foundation Level
● es un conjunto de mejores prácticas para crear y mejorar un proceso de ITSM. Está diseñado para ayudar
a las empresas a gestionar los riesgos, fortalecer las relaciones con los clientes, establecer prácticas
rentables y crear entornos de TI estables para el crecimiento, la escala y el cambio. En resumen, un
profesional de ITIL es un experto en la configuración continua de los procesos de desarrollo de servicios
de TI.La principal fortaleza de ITIL es su versatilidad. Las prácticas son escalables y flexibles, lo que
permite a las organizaciones asumir tanto o tan poco como deseen. ITIL puede incluso adaptarse para
trabajar en conjunto con otras prácticas, como COBIT, Six Sigma y TOGAF.Una cosa importante a tener en
cuenta es que ITIL no se basa en un modelo de negocio específico. Más bien, se basa en la experiencia
colectiva de los profesionales de TI. Se ha aplicado en múltiples industrias, ayudado principalmente por el
hecho de que prácticamente todas las industrias del mundo dependen ahora de TI de una forma u
otra.Entonces, ¿qué es ITIL? Es una serie de procesos para refinar y mejorar el ciclo de vida de un servicio
de TI. Ayuda a aumentar las capacidades de las organizaciones, los procesos y las personas, asegurando
que cuando los cambios en la tecnología o las prácticas comerciales los dejan vulnerables, pueden
adaptarse rápidamente y mantenerse al tanto de la competencia.
●
¡Muchas gracias!

Capacitacion - Academia Hitts QA PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Capacitacion - Academia Hitts QA PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Academia Hitts

Cristian Adrian Barrientos:

1. Introducción al Curso 9:30 - 11:30

Conoceremos los distintos tipos de testing, manual , automatizado, funcional y técnico.

Aprenderemos que es un error , como informarlo y clasiﬁcarlo según su nivel de impacto.

Desarrollar testing automatizado, cuando? , por qué? , costo de su diseño vs implementación.

Testing Performance, conceptos alcances , objetivos , planiﬁcacion y ejecucion, análisis y resultados.

Fundamental Principles of Testing:

Software Testing Life Cycle

● Es el proceso de prueba que se ejecuta de manera sistemática y planiﬁcada.

Software Testing Life Cycle

Software Testing Life Cycle

Test Case Speciﬁcations

● la especiﬁcación de caso de prueba es un documento que entrega un resumen detallado de los

Hight Level Document

● Un documento de diseño de alto nivel (HLDD) describe la arquitectura utilizada en el desarrollo de un

● Un error/defect es la consecuencia / resultado de una falla de codiﬁcación.

Defects Lifes Cycle

● Es un sistema de seguimiento de errores o un sistema de seguimiento de defectos, es una aplicación que

Dinamic Test/Structure Base (White Box)

Dinamic Test/Structure Base (White Box) Decisions

Dinamic Test/Structure Base (White Box) Multiple Condition

Dinamic Test/Experiences Bases

Dinamic Test/Speciﬁcation Base (Black Box)

Dinamic Test/Speciﬁcation Base (Black Box)

Boundary Value Analysis

Dinamic Test/Speciﬁcation Base (Black Box)

● Un nivel de prueba de software es un proceso donde se prueba cada unidad o componente de un

● La prueba de componentes es un método donde la prueba de cada componente en una aplicación se

● es un método de prueba de software en el que el Tester conoce la estructura interna / diseño /

● es un nivel de prueba de software donde se prueban unidades / componentes individuales de un

● También conocido como Pruebas de comportamiento, es un método de prueba de software en el

● También conocido como "Pruebas de veriﬁcación de construcción", es un tipo de prueba de

● Proceso de prueba basado en el riesgo:

● Las áreas de alto riesgo se pueden identiﬁcar en la aplicación.

● Además, la probabilidad de fallo tiene diferentes categorías:

● Crítico -5: la probabilidad de falla es demasiado alta y el impacto en el sistema periférico es

● Enfoque de prueba basado en el riesgo:

● Evaluando criterios de salida

● Desventajas de las pruebas basadas en riesgo:

● Proceso de prueba basado en el riesgo:

● Analizando el riesgo: discutiendo los riesgos y asignándoles una probabilidad.

● Respuesta al riesgo: documentar dependencias y asignar puntaje de efectividad de prueba

● Deﬁnición del proceso de prueba: Redacción del proceso de prueba.

● Ejemplos simples de pruebas de carga:

● La prueba de escalabilidad es un tipo de pruebas no funcionales y es la prueba de una aplicación

Non Functional Test/Eﬃciency/Spike Test

● Se reﬁere al proceso de probar la facilidad con la que un componente o aplicación de software de

Non Functional Test/Usability

● La prueba de usabilidad se deﬁne como un tipo de prueba de software en la cual, un pequeño

● ¿Qué es un archivo de características(historias) y qué contiene?

○ Feature(caracteristica-historia)= cliente retira dinero cajero automatico.

● Scenario: Cuenta tiene credito.

● Given :cuenta tiene credito.

● Los escenarios en los archivos de características (historias)deben centrarse en el "qué" en lugar

● Scenario: Cuenta excede limite extraccion.

● Given :cuenta excede limite extraccion..

● es un proceso de desarrollo de software que se basa en la repetición de un ciclo de desarrollo muy

● Comportamiento vs. Prueba

● Escritura de pruebas de TDD frente a escritura de pruebas de BDD de falla:

● Dueño del producto:

○ Deﬁne las características del producto.

● Ceremonias (Procesos) en Scrum