Este documento presenta las mejores prácticas para el testeo de aplicaciones. Explica que el testeo de software proporciona información objetiva sobre la calidad del producto a las partes interesadas. También describe que los tipos de pruebas pueden implementarse en cualquier etapa del desarrollo y que las actividades y técnicas de prueba deben seleccionarse de manera eficiente según el contexto del proyecto. Finalmente, presenta un temario sobre los diferentes tipos de pruebas, las etapas para generar pruebas, cómo obt
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
In this quality assurance training session, you will learn Test Execution. Topics covered in this course are:
• Test Execution and its purpose
• Entry and Exit Criteria
• Test Execution and its cycles
• Testing Methodology (BBT , WBT)
• Class Assignment
TO know more, visit this link: https://www.mindsmapped.com/courses/quality-assurance/get-practical-training-on-software-testing-quality-assurance-qa/
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
In this quality assurance training session, you will learn Test Execution. Topics covered in this course are:
• Test Execution and its purpose
• Entry and Exit Criteria
• Test Execution and its cycles
• Testing Methodology (BBT , WBT)
• Class Assignment
TO know more, visit this link: https://www.mindsmapped.com/courses/quality-assurance/get-practical-training-on-software-testing-quality-assurance-qa/
Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user whereby they use most of the application's features to ensure correct behavior.
11 steps of testing process - By Harshil BarotHarshil Barot
11 Steps of The Software Testing Process.Software Testing Process is a Find out the Maximum Bugs and Errors From the Software or Product and Make the Software
Bugs or Error Free.(Bugs/Errors/Defects).
Introducing Playwright's New Test RunnerApplitools
Playwright Test is a new test runner built from scratch by the Playwright team specifically to accommodate end-to-end testing needs. Join Principal Engineer, Andrey Lushinkov as he demonstrates how to use Playwright Test to author new tests, how to migrate existing tests, how to deploy them on CI, and debug them if something goes wrong.
What are the Key drivers for automation? What are the Challenges in Agile automation and How to deal with them? How to automate? Who will automate? Which tool to select? Commercial or open source? What to automate? Which features? Here is what our experience says
This is chapter 4 of ISTQB Specialist Performance Tester certification. This presentation helps aspirants understand and prepare the content of the certification.
You may probably recognize the situation when a requirements professional is assigned to a new, challenging, agile project.
As Scrum does not know the role of a Requirements Engineer (RE) or Business Analyst (BA), the requirements professional will either become the Product Owner or be part of the Scrum Team (which consists of members with cross-functional know-how). Either way, the activities of requirements engineering will be executed in some way in an agile environment: that is handling requirements, often associated with user stories, eliciting needs from various stakeholders, documenting them accordingly, negotiating them and achieving acceptance and finally dealing with changes.
There is definitely a lot that goes on with requirements in Agile projects. Sometimes, you may not recognize that a practice used is nothing other than the basic method such as prioritisation; it becomes even more important and may be performed in a very similar way to traditional approaches (e.g. single-criterion classification or the Kano model), even if the result is represented as a sorted Product Backlog.
In this slideshare, the presenter will make some propositions about practices of the four major activities of requirements engineering (elicitation, documentation, validation, management) that may be implemented in a Scrum environment. This will be done by virtue of eliciting differences between the classic way of requirements engineering versus requirements engineering done in the Agile way published in the presenter's article at:
https://www.scrumalliance.org/community/articles/2017/august/requirements-engineering.aspx
In a device-frangmented world like ours today, it has become impossible to test all software, let alone mobile applications, manually. That's why automated testing is so important!
Find out about the top benefits of automated testing in this slideshow!
Una serie de pasos predecibles que ayude a crear un resultado de alta calidad y a tiempo.
Es un conjunto estructurado de actividades para: Especificar, diseñar, implementar y probar software.
Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user whereby they use most of the application's features to ensure correct behavior.
11 steps of testing process - By Harshil BarotHarshil Barot
11 Steps of The Software Testing Process.Software Testing Process is a Find out the Maximum Bugs and Errors From the Software or Product and Make the Software
Bugs or Error Free.(Bugs/Errors/Defects).
Introducing Playwright's New Test RunnerApplitools
Playwright Test is a new test runner built from scratch by the Playwright team specifically to accommodate end-to-end testing needs. Join Principal Engineer, Andrey Lushinkov as he demonstrates how to use Playwright Test to author new tests, how to migrate existing tests, how to deploy them on CI, and debug them if something goes wrong.
What are the Key drivers for automation? What are the Challenges in Agile automation and How to deal with them? How to automate? Who will automate? Which tool to select? Commercial or open source? What to automate? Which features? Here is what our experience says
This is chapter 4 of ISTQB Specialist Performance Tester certification. This presentation helps aspirants understand and prepare the content of the certification.
You may probably recognize the situation when a requirements professional is assigned to a new, challenging, agile project.
As Scrum does not know the role of a Requirements Engineer (RE) or Business Analyst (BA), the requirements professional will either become the Product Owner or be part of the Scrum Team (which consists of members with cross-functional know-how). Either way, the activities of requirements engineering will be executed in some way in an agile environment: that is handling requirements, often associated with user stories, eliciting needs from various stakeholders, documenting them accordingly, negotiating them and achieving acceptance and finally dealing with changes.
There is definitely a lot that goes on with requirements in Agile projects. Sometimes, you may not recognize that a practice used is nothing other than the basic method such as prioritisation; it becomes even more important and may be performed in a very similar way to traditional approaches (e.g. single-criterion classification or the Kano model), even if the result is represented as a sorted Product Backlog.
In this slideshare, the presenter will make some propositions about practices of the four major activities of requirements engineering (elicitation, documentation, validation, management) that may be implemented in a Scrum environment. This will be done by virtue of eliciting differences between the classic way of requirements engineering versus requirements engineering done in the Agile way published in the presenter's article at:
https://www.scrumalliance.org/community/articles/2017/august/requirements-engineering.aspx
In a device-frangmented world like ours today, it has become impossible to test all software, let alone mobile applications, manually. That's why automated testing is so important!
Find out about the top benefits of automated testing in this slideshow!
Una serie de pasos predecibles que ayude a crear un resultado de alta calidad y a tiempo.
Es un conjunto estructurado de actividades para: Especificar, diseñar, implementar y probar software.
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 3 - Tema 2
Contenido: concepto, tipos, escenarios, casos de uso vs casos de prueba, atributos e importancia.
Estructuras de datos avanzadas: Casos de uso realesSoftware Guru
La utilización de estructuras de datos adecuadas para cada problema hace que se simplifiquen en gran medida los tiempos de respuestas y la cantidad de cómputo realizada.
Por Nelson González
Onboarding new members into an engineering team is not easy on anyone. In a short period of time, the new team member is required to be able to bring professional
Por Victoriya Kalmanovich
El secreto para ser un desarrollador SeniorSoftware Guru
En esta charla platicaremos sobre el “secreto” y el camino para llegar a ser un desarrollador Senior, experiencia, consejos y recomendaciones que en estos 8 años
Por René Sandoval
Apache Airflow es una plataforma en la que podemos crear flujos de datos de manera programática, planificarlos y monitorear de manera centralizada.
Por Yesi Díaz
How thick data can improve big data analysis for business:Software Guru
En esta presentación hablaré sobre cómo el Análisis de Datos Gruesos, específicamente el análisis antropológico y semiótico, puede ayudar a mejorar los resultados del Big Data
Por Martin Cuitzeo
CoDi® es la nueva forma de realizar pagos digitales desarrollada por el Banco de México. Por medio de CoDi puedes realizar cobros y pagos desde tu celular, utilizando una cuenta bancaria o de alguna institución financiera, sin comisiones.
Por Cristian Jaramillo
Gestionando la felicidad de los equipos con Management 3.0Software Guru
En las metodologías agiles hablamos de equipos colaborativos, autogestionados y felices. hablamos de lideres serviciales. El management 3.0 nos ayuda a cultivar el mindset correcto, aquel que servirá como el terreno fértil para que la agilidad florezca.
Por Andrea Vélez Cárdenas
Taller: Creación de Componentes Web re-usables con StencilJSSoftware Guru
Hoy por hoy las experiences de usuario pueden ser enriquecidas mediante el uso de Web Components, que son un estándar de la W3C soportado por la mayoría de los navegadores web modernos.
Por Alex Arriaga
Así publicamos las apps de Spotify sin stressSoftware Guru
En Spotify tenemos 1600+ ingenieros, trabajando en 280+ squads. Aún a esta escala, hemos logrado adoptar prácticas que nos han permitido acelerar la forma en que desarrollamos nuestro producto. Presentado por Erick Camacho en SG Virtual Conference 2020
Achieving Your Goals: 5 Tips to successfully achieve your goalsSoftware Guru
he measure of the executive, Peter F. Drucker reminds us, is the ability to "get the right things done." This involves having clarity on what are the right things as well as avoiding what is unproductive. Intelligence, creativity, and knowledge may all be wasted if not put to work on the things that matter.
Presentado por Cristina Nistor en SG Virtual Conference 2020
Acciones de comunidades tech en tiempos del Covid19Software Guru
Acciones de Comunidades Tech en tiempo del COVID-19 es una platica para informar acerca de las acciones que están realizando algunas comunidades de tecnología en México para luchar contra la propagación del COVID-19. Desde análisis de datos, visualizaciones, simulaciones de contagio, etc.
Presentado por Juana Martínez, Adriana Vallejo y Eduardo Ramírez en SG Virtual Conference 2020
De lo operativo a lo estratégico: un modelo de management de diseñoSoftware Guru
La charla presenta un modelo claro, generado por la ponente, para atender los niveles desde lo operativo a lo estratégico.
Presentado por Gabriela Salinas en SG Virtual Conference
En este documento analizamos ciertos conceptos relacionados con la ficha 1 y 2. Y concluimos, dando el porque es importante desarrollar nuestras habilidades de pensamiento.
Sara Sofia Bedoya Montezuma.
9-1.
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta in...espinozaernesto427
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta intensidad son un tipo de lámpara eléctrica de descarga de gas que produce luz por medio de un arco eléctrico entre electrodos de tungsteno alojados dentro de un tubo de alúmina o cuarzo moldeado translúcido o transparente.
lámparas más eficientes del mercado, debido a su menor consumo y por la cantidad de luz que emiten. Adquieren una vida útil de hasta 50.000 horas y no generan calor alguna. Si quieres cambiar la iluminación de tu hogar para hacerla mucho más eficiente, ¡esta es tu mejor opción!
Las nuevas lámparas de descarga de alta intensidad producen más luz visible por unidad de energía eléctrica consumida que las lámparas fluorescentes e incandescentes, ya que una mayor proporción de su radiación es luz visible, en contraste con la infrarroja. Sin embargo, la salida de lúmenes de la iluminación HID puede deteriorarse hasta en un 70% durante 10,000 horas de funcionamiento.
Muchos vehículos modernos usan bombillas HID para los principales sistemas de iluminación, aunque algunas aplicaciones ahora están pasando de bombillas HID a tecnología LED y láser.1 Modelos de lámparas van desde las típicas lámparas de 35 a 100 W de los autos, a las de más de 15 kW que se utilizan en los proyectores de cines IMAX.
Esta tecnología HID no es nueva y fue demostrada por primera vez por Francis Hauksbee en 1705. Lámpara de Nernst.
Lámpara incandescente.
Lámpara de descarga. Lámpara fluorescente. Lámpara fluorescente compacta. Lámpara de haluro metálico. Lámpara de vapor de sodio. Lámpara de vapor de mercurio. Lámpara de neón. Lámpara de deuterio. Lámpara xenón.
Lámpara LED.
Lámpara de plasma.
Flash (fotografía) Las lámparas de descarga de alta intensidad (HID) son un tipo de lámparas de descarga de gas muy utilizadas en la industria de la iluminación. Estas lámparas producen luz creando un arco eléctrico entre dos electrodos a través de un gas ionizado. Las lámparas HID son conocidas por su gran eficacia a la hora de convertir la electricidad en luz y por su larga vida útil.
A diferencia de las luces fluorescentes, que necesitan un recubrimiento de fósforo para emitir luz visible, las lámparas HID no necesitan ningún recubrimiento en el interior de sus tubos. El propio arco eléctrico emite luz visible. Sin embargo, algunas lámparas de halogenuros metálicos y muchas lámparas de vapor de mercurio tienen un recubrimiento de fósforo en el interior de la bombilla para mejorar el espectro luminoso y reproducción cromática. Las lámparas HID están disponibles en varias potencias, que van desde los 25 vatios de las lámparas de halogenuros metálicos autobalastradas y los 35 vatios de las lámparas de vapor de sodio de alta intensidad hasta los 1.000 vatios de las lámparas de vapor de mercurio y vapor de sodio de alta intensidad, e incluso hasta los 1.500 vatios de las lámparas de halogenuros metálicos.
Las lámparas HID requieren un equipo de control especial llamado balasto para funcionar
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
2. 2
Introducción
El testeo de aplicaciones (en inglés software testing) son las investigaciones que
proporcionan información objetiva e independiente sobre la calidad del producto a las partes
interesadas.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo.
Por esto, las actividades, técnicas, documentación, enfoques y demás elementos que
condicionarán las pruebas a realizar deben ser seleccionadas y utilizadas de la manera más
eficiente según contexto del proyecto.
3. 3
Introducción
El testeo de aplicaciones (en inglés software testing) son las investigaciones que
proporcionan información objetiva e independiente sobre la calidad del producto a las partes
interesadas.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo.
Por esto, las actividades, técnicas, documentación, enfoques y demás elementos que
condicionarán las pruebas a realizar deben ser seleccionadas y utilizadas de la manera más
eficiente según contexto del proyecto.
4. 4
Temario
1. Los Diferentes Tipos de Pruebas.
2. Las Etapas para la Generación de las Pruebas.
3. Obtener los Requerimientos.
4. Ciclo para la Generación de Casos de Pruebas.
5. Definición de Carga .
6. Ejecución de Pruebas.
7. Análisis de Resultados.
6. 6
Pruebas de Carga:
Se realiza generalmente para observar el comportamiento de una aplicación bajo una
cantidad de peticiones esperada. Esta carga puede ser el número esperado de usuarios
concurrentes utilizando la aplicación y que realizan un número específico de transacciones
durante el tiempo que dura la carga.
Pruebas de Estrés:
Permite ver el comportamiento de la aplicación con mas usuarios de los que fue diseñada .
se van incrementando el número de usuarios que se agregan a la aplicación hasta tirar la
aplicación o ver el comportamiento con carga excesiva.
Pruebas Funcionales:
Nos permite medir el comportamiento del programa desde el punto de vista del usuario
final.
Los Diferentes Tipos de Pruebas
7. 7
Pruebas de Regresión:
Es un tipo particular de prueba de carga en la cual el objetivo es la de probar un error
detectado en la aplicación, hacer las correcciones necesarias y volver a ejecutar la prueba
para ver si la aplicación presento el error detectado.
Pruebas de Caja Negra:
Las pruebas de caja negra se limita a suministrarle datos como entrada y estudiar la salida,
sin preocuparse de lo que pueda estar haciendo el módulo por dentro.
Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a
ser interactuar con el usuario (en sentido general: teclado, pantalla, ficheros, canales de
comunicaciones, etc. etc.).
Otro tipo de pruebas
Los Diferentes Tipos de Pruebas
9. 9
Fin
Obtener Requerimientos
Definir Carga para las
Aplicaciones
Creación de Casos de
Prueba
Ejecución de la Prueba
Analizar Resultados
Modificación al Sistema
Resultados No Esperados
Resultados Esperados
Las Etapas para la Generación de Pruebas
11. 11
Requerimientos:
También conocidos como requisitos, se definen como las necesidades o problemas que el cliente
o usuario desea resolver.
Su administración requiere de priorizarlos, documentarlos, revisarlos y aprobarlos.
El objetivo es que todas las partes cuenten con una explicación escrita del problema. Se pueden
obtener de escenarios de uso, relación de evento-respuesta, o descripción de necesidades.
Entre otra información los requerimientos contienen: Especificaciones, Reglas del Negocio,
Reglas de Cálculo, Validaciones de Información, Descripción de Procesos de la Operación.
Ejemplos:
1. Investigar la lentitud de la nueva aplicación en el ambiente de producción.
2. Comprobar la experiencia del usuario final con las nuevas opciones de la aplicación.
3. Generar registro contable por los intereses moratorios.
4. Realizar el pago de servicios médicos (Farmacia, Consultas Médicas) de manera directa para
proveedores de la red con 100 usuarios concurrentes.
5. Transferencia de Pago de Servicios (Tarjetas de Crédito, Cable, Teléfono).
Obtener los Requerimientos
13. 13
Ciclo para la Creación de Casos de Pruebas
Definir Lista de
Funciones
Identificar las
Reglas del Negocio
Definir Casos de
Pruebas
Generación de
Guiones
Creación de Casos
de Prueba
14. 14
Lista de Funciones (o pasos).
Una función es una acción dentro de la aplicación que regularmente esta asociada a un proceso
de negocio.
Lista de funciones es una relación de acciones ordenadas de manera lógica y que se llevan a
cabo de manera sistemática para llegar a un resultado deseado.
Puede representar acciones generales o particulares. Esto significa que pueden
descomponerse en subfunciones y así de manera sucesiva.
La descomposición debe llevarse a cabo de una manera ordenada y lógica.
Ciclo para la Creación de Casos de Pruebas
15. 15
Lista de Funciones (o pasos).
1. Escenarios de Uso.
2. Requerimientos.
3. Procesos de Negocio.
4. Procedimientos.
5. Diagramas de Flujo de Proceso.
6. Diseño de la Aplicación.
7. Especificaciones.
8. Instructivos de Operación.
9. Manuales de Usuario.
10.Entrevistas con el Usuario de la Aplicación.
Manua
l del
Sistem
a
Proces
o del
Negoc
io
Especificacio
nes
Ciclo para la Creación de Casos de Pruebas
16. 16
Ejemplo de Lista de Funciones:
Un ejemplo de una lista de funciones puede
darse al momento de efectuar un retiro de
efectivo de un cajero automático.
1. Insertar de Tarjeta
2. Teclear NIP
3. Consulta de Saldo
4. Retiro de Efectivo
5. Impresión de Comprobante
6. Retiro de Tarjeta
Retiro de Efectivo
1. Insertar Tarjeta
2. Teclear NIP
3. Consultar Saldo
4. Retirar Efectivo.
5. Imprimir
Comprobante
6. Retirar Tarjeta
Ciclo para la Creación de Casos de Pruebas
17. 17
Reglas del Negocio:
Son las condiciones que regulan el desarrollo de un proceso y establecen el deber ser.
Constituyen las políticas de operación o de servicio que se dan en un proceso.
Dentro de la aplicación, a menudo están determinadas por los valores de los datos y por la
relación de estos con otros y con los elementos de infraestructura.
Ciclo para la Creación de Casos de Pruebas
18. 18
Ejemplos de Reglas del Negocio:
a) No hay precios negativos para los artículos
Precio Negativo
$-20.00
Error
b) El sexo de una persona solo puede ser masculino o femenino
Sexo <> M / F Error
c) Una fecha siempre debe ser una fecha válida (No existe 30 de Febrero)
6/7/2013 Fecha Inválida Error
Ciclo para la Creación de Casos de Pruebas
19. 19
Reglas del Negocio.
Las Reglas del Negocio también pueden incluir premisas que pueden controlar las relaciones entre los
datos.
Por ejemplo estas reglas especifican:
a) Todo pedido debe ser realizado por un cliente y debe existir en el sistema con estatus vigente.
Si
Cliente
No
Elaborar Pedido
Cliente
Existe ?
Registrar Cliente
Ciclo para la Creación de Casos de Pruebas
20. 20
Si
No
Eliminar Pedidos
Tiene
Pedidos ?
Eliminar Cliente
b) Una vez que un cliente haya hecho algún pedido, se deberá garantizar que no es posible eliminarlo,
a menos que previamente se eliminen todos sus pedidos
Ciclo para la Creación de Casos de Pruebas
21. 21
Casos de Prueba.
1. Es una definición lógica de la prueba a la que se someterá un proceso de negocio bajo condiciones
determinadas.
2. El propósito es identificar un objetivo en forma de resultados esperados y definir los datos más
importantes, así como sus valores para obtener dicho resultado.
3. La característica principal es que existe una entrada conocida y una salida esperada.
4. Para su definición se utilizan la lista de funciones y las reglas de negocio asociadas con los
requerimientos.
Ciclo para la Creación de Casos de Pruebas
22. 22
Ciclo para la Creación de Casos de Pruebas
Casos de Prueba.
Caso 1
Entradas
Resultados
esperados
Casos
Especiales
Entradas
Resultados
esperados
Caso 2
Entradas
Resultados
esperados
Caso 3
Entradas
Resultados
esperados
Caso 4
Entradas
Resultados
esperados
Reglas de
Negocio
Lista de Funciones
23. 23
Casos de Prueba.
Con los casos seleccionados se pueden cubrir
con alguna de las diferentes tipos de
pruebas, por ejemplo:
1. Pruebas unitarias (Aplicadas por el
programador).
2. Pruebas de funcionalidad (Aplicadas por el
área de calidad).
3. Pruebas integrales / Aceptación (Aplicadas
en conjunto con el usuario final).
4. Pruebas de estrés, etc.
Pruebas
Unitarias
Módulo-
1
Módulo-
2 Módulo-
3
Caso 1
Entrad
as
Salidas
Casos
Esp.
Entrad
as
Salidas
Caso 2
Entrad
as
Salidas
Caso 3
Entrad
as
Salidas
Pruebas de
Funcionalidad
Caso 1
Entrad
as
Salidas
Casos
Esp.
Entrad
as
Salidas
Caso 2
Entrad
as
Salidas
Caso 3
Entrad
as
Salidas
Pruebas Integrales /
Aceptación
Ciclo para la Creación de Casos de Pruebas
24. 24
Ejemplos de Casos de Prueba:
Caso 1.
Objetivo. Confirmar la Cancelación de un Contrato por Falta de Pago.
Regla de Negocio: El pago de la membresía no se ha realizado para el periodo actual y han
transcurrido dos meses desde el aniversario del contrato.
Resultado esperado
1. Contrato cambia a estatus cancelado por falta de pago.
2. Se genera notificación correspondiente al cliente.
Caso 2.
Objetivo. Reactivar una contrato cancelado por falta de pago, sin cargo moratorio.
Regla de Negocio: Se ha realizado el pago de un contrato con estatus de pago pendiente y no han
transcurrido más de tres meses desde el aniversario.
Resultado esperado:
3. Contrato cambia a estatus vigente.
4. Se genera contabilidad del pago.
Ciclo para la Creación de Casos de Pruebas
25. 25
Elaboración de Guiones.
Objetivo de Prueba del Guión:
• Propósito del guión (Descripción de lo que se quiere probar).
• Función(es) Asociada(s).
Pasos para Procesar el Guión:
• Secuencia lógica de las acciones que se llevarán a cabo.
• Flujo de trabajo que muestra los pasos para realizar la prueba a través del guión.
Estructura de Cada Paso:
• Número o Nombre del Paso.
• Descripción del Paso.
• Resultados Esperados de cada Paso.
• Verificación de Resultados.
Ciclo para la Creación de Casos de Pruebas
26. 26
Ejercicio:
Durante este ejercicio usted practicará lo siguiente:
1. Identificar y definir el requerimiento de prueba.
2. Elaborar lista de funciones afectadas.
3. Identificar las reglas del negocio.
4. Definir asos de prueba.
Ciclo para la Creación de Casos de Pruebas
27. 27
Ejercicio:
La Aplicación
• Para validar el funcionamiento de la aplicación de correo, el cliente debe acceder a su cuenta de
correo a través de su usuario y password.
• El cliente deberá de enviar un correo a softwareguru@mexico.com.
• Se deberá de adjuntar cualquier tipo de archivo ubicado en la unidad c de su equipo de computo.
• Después de adjuntar el documento se deberá de seleccionar el acuse de recibo antes de enviar.
Requerimiento de adecuación (supuestos)
• El archivo a enviar deberá de ser menor a 2 MB.
• En la sección de asunto se deberá de ingresar: Archivo adjunto.
• En la sección de mensaje, enviar un saludo.
Ciclo para la Creación de Casos de Pruebas
28. 28
Ejercicio:
Definición del Problema
Requerimiento de Prueba:
• Confirmar que el archivo demo adjuntado salga del servidor de correo poniendo como destinatario el
correo del emisor.
• Para lo anterior se solicita generar los siguientes productos del proceso de pruebas.
• Elaborar el guión o los guiones de prueba considerando todas las actividades y funciones que usted
identifique.
• Se recomienda descomponer el proceso llegando al nivel de sus funciones más básicas y construir
los guiones asociados a dichas funciones.
Productos Requeridos:
1. Lista de funciones
2. Reglas del negocio
3. Casos de prueba
Ciclo para la Creación de Casos de Pruebas
29. 29
Solución del Ejercicio:
Lista de Funciones
1. Login a mi correo electrónico.
2. Oprimir el botón nuevo correo.
3. Adjuntar archivo ubicado en la unidad c.
4. Ingresar el correo de sofwareguru@mexico.com
5. Ingresar el correo de hugo.pallares@globallynx.com
6. En la sección asunto Ingresar: Archivo adjunto
7. En la sección mensaje ingresar : Buenos días.
8. Dar clic en el botón enviar.
9. Dar clic en el botón de correos entrantes.
10. Validar que exista el correo que acabo de enviar con el adjunto
11. Salir
Las funciones se ejecutan en el orden listado deseablemente
La función Login debe procesarse antes de enviar el correo
Ciclo para la Creación de Casos de Pruebas
30. 30
Solución del Ejercicio:
Reglas de Negocio
1. Se deberá de adjuntar un archivo menor a 2 MB.
2. Se deberá de ingresar el correo del emisor.
3. Se deberá de enviar un saludo.
Caso de Prueba
Caso 1.Envio de imagen de 1 MB . Operación exitosa
Caso 2. Envío de un archivo .zip de 4 MB. Error (Archivo muy grande)
Ciclo para la Creación de Casos de Pruebas
32. 32
Dependiendo el tipo de prueba que se va a generar, es necesario definir la cantidad de usuarios
que van a necesitar durante las pruebas.
Si en los requerimientos se pide que simule la carga de un día de trabajo necesitaríamos conocer
los procesos de negocio que se generan para esa aplicación , así como el horario de mayor carga
para saber el numero de usuarios que necesitamos.
Definición de Carga
33. 33
Procesos de
Negocio
Crear Cuenta 40 200 210 200 150
10
0 75 15
Búsqueda por vuelos 5 250 400 400 240
20
0 50
Comprar boletos 3 300 350 500 200
10
0 50 30
Procesos
Administrativos
Respaldo del
sistema 1 1 1 1
Max Usuarios
Definición de Carga
34. 34
¿Cuantas iteraciones (transacciones) necesitamos generar por minuto si la prueba
debe de emular 2 horas con 500 usuarios, asumiendo que el promedio de la iteracion
dura 5 min?
Cuantas transacciones se generarán por minuto:
• 120 min / 5 min = 24 por usuario
• 500 usuarios X 24 iteraciones = 120,000 iteraciones
• 120,000 iteraciones / 120 minutos = 1000 iteraciones por minuto
Definición de Carga
36. 36
Para la ejecución de la prueba debemos de considerar lo siguiente:
Ubicación de generadores de Carga: Es el lugar en el cual se estarán ejecutando los usuarios virtuales
/físicos.
Número de usuarios: El total de usuarios virtuales a ejecutar del proceso de negocio.
Procesos de negocio involucrados: El nombre del/los proceso de negocio a realizar.
Delay en “n” segundos: El tiempo de espera entre cada iteración del usuario.
Accesos de usuarios cada “n” segundos: Es el tiempo en el cual se agregara a la carga un nuevo
usuario virtual.
Ejecución de Pruebas
37. 37
Una vez definido lo anterior se generara el escenario de pruebas.
Ejecución de Pruebas
39. 39
Una vez generada la prueba se deberá de analizar todos los datos para determinar si
se cumplió o no con el objetivo planteado.
Análisis de Resultados
40. 40
Con el análisis de los datos podemos llegar a diferentes conclusiones de
acuerdo al comportamiento durante la prueba.
Análisis de Resultados
41. 41
Log de Defectos Revisar Defecto
Corregidor Defecto
Nueva Prueba
Cerrar Defecto
¿Necesita
Corregir?
Corregido?
Nuevo
Corregido
Cerrado /
Rejected
Estatus de
Defecto Ciclo de Vida de Defectos
Análisis de Resultados
Abierto/
Reabierto