Pruebas y Validación de Software

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Pruebas y Validación de Software por Mind Map: Pruebas y Validación de Software

1. Sikuli -->Alan Mauricio

1.1. Lenguajes

1.1.1. Python

1.1.2. Ruby

1.1.3. Js

2. Appium Appium es el estándar en automatización de pruebas para móviles. Se trata de un framework open source que permite probar aplicaciones nativas, híbridas o, como en nuestro caso, aplicaciones web. Se dice de appium que es como selenium, pero para aplicaciones móviles. -Mauricio Ricardo Melchor Andrade

3. Criterios de salida: Conjunto de condiciones genéricas y especificas, acordadas con los interesados del negocio, para permitir que un proceso sea finalizado oficialmente,; evitan que una tarea sea considerada finalizada cuando aun hay partes pendientes de la misma. --> Nathaly N. Dimas C.

4. Etapas

4.1. Planeacion de pruebas

4.2. Ejecución de pruebas: Proceso de ejecución de una prueba en el componente o sistema sometido a las mismas, produciendo resultados(s) reales(s). --> Nathaly N. Dimas C.

4.3. Registro de pruebas: Registro cronológico de detalles relevantes acerca de la ejecución de pruebas. --> Nathaly N. Dimas C.

4.3.1. Etapa en base a resultados

5. Calidad: El grado en el cual un componente, un sistema o un proceso cumple los requisitos ----- Luis Daniel Guerrero Ramírez

6. Ejemplo de Error: Un error de digitación, una malinterpretación de un requerimiento o de la funcionalidad de un método. ----- Luis Daniel Guerrero Ramírez

7. Repetición de pruebas: Pruebas que ejecutan los casos de prueba que fallaron la ultima vez que se ejecutaron, con el fin de verificar el éxito de las acciones correctivas. --> Nathaly N. Dimas C.

8. Las pruebas se realizan de manera secuencial ya que sigue la metodología de trabajo.

9. ¿para que sirven? -Mauricio ricardo melchor andrade

9.1. Sirve para asegurar el correcto funcionamiento del mismo y si es necesario corregir fallos -Mauricio Ricardo Melchor Andrade

10. Los ingenieros de software deberán participar en el aprendizaje continuo de la práctica de su profesión y promoverán un enfoque ético en la práctica de la profesión. Blanca Leticia Guerra

11. Qué es? Arquitectura abierta (no esta ligada a ningun sistema operativo ni sistema de ventanas) para pruebas de interfaz grafica. -Jorge Luis Ponce Rivera

12. Principios Generales

12.1. Defecto: Puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. ------ Luis Daniel Guerrero Ramírez

12.2. Falla: Una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, el cual es incapaz de funcionar correctamente. ----- Luis Daniel Guerrero Ramírez

12.3. Error: Es una equivocación cometida por el desarrollador.-----Luis Daniel Guerrero Ramírez

12.3.1. Ejemplo de Error: Un error de digitación, una malinterpretación de un requerimiento o de la funcionalidad de un método. ----- Luis Daniel Guerrero Ramírez

12.4. Calidad: El grado en el cual un componente, un sistema o un proceso cumple los requisitos ----- Luis Daniel Guerrero Ramírez

12.5. Principios Generales

12.5.1. Defecto: Puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. ------ Luis Daniel Guerrero Ramírez

12.5.2. Falla: Una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, el cual es incapaz de funcionar correctamente. ----- Luis Daniel Guerrero Ramírez

12.5.2.1. Error: Es una equivocación cometida por el desarrollador.-----Luis Daniel Guerrero Ramírez

12.6. Otros conceptos básicos Emmanuel Alexis Medrano León

12.6.1. Anomalía: Cualquier cosa observada en la documentación o en la operación del software que se desvía de expectativas base del producto de software previamente verificados o los documentos de referencia.

12.6.2. Caso de prueba: Un conjunto de entradas de prueba, de condiciones de ejecución, y de resultados previstos desarrollados para un objetivo particular, por ejemplo para realizar una trayectoria particular del programa o para verificar conformidad con un requisito específico. Documentación que especifica entradas, resultados previstos, y una serie de condiciones de ejecución para un elemento de la prueba.

12.6.3. Diseño de la prueba : Documentación que especifica los detalles del enfoque de la prueba para identificar una característica del software o combinación de características del software y las pruebas asociadas.

12.6.4. Procedimiento de prueba : Instrucciones detalladas para la disposición, la ejecución, y la evaluación de los resultados para un caso dado de prueba. Un documento que contiene un conjunto de instrucciones asociadas. Documentación que especifica una secuencia de las acciones para la ejecución de una prueba.

12.6.5. Procesos del ciclo de vida : Conjunto de actividades correlacionadas que dan lugar al desarrollo o la evaluación de los productos de software. Cada actividad consiste en tareas. Los procesos del ciclo de vida pueden traslaparse uno con otro.

12.6.6. Prueba de aceptación : Prueba formal conducida para determinar si o no, un sistema satisface sus criterios de aceptación y permitir al usuario determinar si o no aceptar el sistema.

12.6.7. Prueba de componente : Prueba de los componentes individuales del hardware o de software o de un grupo de componentes relacionados.

12.6.8. Prueba de integración : Prueba en la cual los componentes de software, los componentes de hardware, o ambos se combinan y se prueban para evaluar la interacción entre ellos.

12.6.9. Prueba del sistema : Prueba conducida en un sistema completo, integrado para evaluar la conformidad del sistema con sus requerimientos especificados

12.6.10. Validación : El proceso de evaluación un sistema o componente durante o en el final del proceso del desarrollo para determinarse si satisface los requerimientos especificados.

12.6.11. Verificación : El proceso de evaluar un sistema o componente para determinar si el producto de una determinada fase de desarrollo satisface las condiciones impuestas al inicio de esa fase.

13. Fundamentos

13.1. Base

13.1.1. Base de prueba: La documentación acerca de la cual los casos de prueba se basan. Todos los documentos de los cuales los requisitos de un componente o sistema pueden ser deducidos. --> Nathaly N. Dimas C.

13.1.1.1. Requisito: Una condición o capacidad necesitada por un usuario para resolver un problema o lograr un objetivo que debe poseer un sistema o un componente del mismo para satisfacer un contrato, estándar, especificación u otro documento formal impuesto. --> Nathaly N. Dimas C.

13.1.1.2. Incidencia: Cualquier evento que ocurre y necesita investigación. --> Nathaly N. Dimas C.

13.1.1.3. Políticas de pruebas: Documento de alto nivel que describe los principios, métodos y objetivos principales de la organización respecto a las pruebas. --> Nathaly N. Dimas C.

13.1.1.4. Datos de prueba: Datos que existen antes que una prueba sea ejecutada, y que afectan al componente o sistema sometido a pruebas o son afectados por estos. --> Nathaly N. Dimas C.

13.2. Objetivo

13.2.1. Objetivo de prueba: Una razón o propósito para el diseño y la ejecución de una prueba. --> Nathaly N. Dimas C.

13.2.2. Conjunto de procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes. - Jorge Luis Oviedo Aguilar

13.3. Definición

13.3.1. Prueba: Conjunto de procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes. - Jorge Luis Oviedo Aguilar

13.3.2. Pruebas: Proceso que consiste en todas las actividades del ciclo de vida interesadas en la planificación, preparación y evaluación de los productos de software y los productos relacionados, para determinar que satisfagan los requisitos especificados, para demostrar que son aptos para el propósito y para detectar defectos. --> Nathaly N. Dimas C.

13.3.2.1. Tipos

13.3.2.1.1. Pruebas Unitarias: Encontrar defectos en las partes individuales del sistema sometidos a pruebas antes de que las partes estén totalmente integradas al mismo. --- Luis Daniel Guerrero Ramírez

13.3.2.1.2. Pruebas exhaustivas: Un método de pruebas en el cual el juego de pruebas comprende todas las combinaciones de los valores de entrada y las pre-condiciones. -->Nathaly N. Dimas C.

13.3.2.1.3. Pruebas de regresión: Pruebas de un programa previamente probado a raíz de una modificación para garantizar que defectos han sido introducidos o descubiertos en áreas no modificadas del software, como resultado de los cambios realizados. --> Nathaly N. Dimas C.

13.3.2.1.4. Funcionales

13.3.2.1.5. No Funcionales

13.3.2.2. se conocen como pruebas de escalabilidad, a aquellas pruebas no funcionales que permiten determinar el grado de escalabilidad que tiene un sistema. - Jorge Luis Oviedo Aguilar

13.3.2.3. Pruebas del Sistema: encontrar defectos en los comportamientos, funciones y respuestas generales y particulares del sistema sometido a pruebas en su totalidad. --- Luis Daniel Guerrero Ramírez

13.3.2.4. Pruebas Opoerativas: buscar otra vez un tipo particular de defectos, especialmente aquellos relacionados con las características no funcionales del sistema como la fiabilidad o la disponibilidad, usualmente en el entorno en funcionamiento. --- Luis Daniel Guerrero Ramírez

13.3.2.5. Caja Negra

13.3.2.5.1. Las lleva a cabo el equipo de pruebas o equipos de pruebas independientes. -> Joel Sabethai Carranza Pintor

13.3.2.5.2. en las metodologías convencionales la pruebas de caja negra las lleva a cabo el equipo de pruebas o equipos de pruebas independiente - mauricio ricardo melchor andrade

13.3.2.6. Caja Blanca

13.3.2.6.1. Están basadas en estudiar el código fuente y se utilizan, principalmente, desde una perspectiva interna en el desarrollo de software. -> Joel Sabethai Carranza Pintor

13.4. Evitan

13.4.1. Error: está provocado por la acción humana, por ejemplo el error lo provocará el desarrollador que realizará una incorrecta interpretación de un método del programa que producirá un resultado no esperado. - Jorge Luis Oviedo Aguilar

13.4.2. Pruebas de integración :encontrar defectos en las relaciones e interfaces entre los pares y grupos de componentes en el sistema sometido a pruebas a medida que las partes se juntan. -- Luis Daniel Guerrero Ramírez

13.4.3. Defecto: Un desperfecto que puede causar que el componente o el sistema falle al realizar su función requerida. -->Nathaly N. Dimas C.

13.4.4. Defecto: se les conoce comúnmente en el argot de los desarrolladores como Bug (bicho), y corresponde a un error, imperfecto o falla de una aplicación para computador que puede causar un resultado no deseado o incumplimiento de un requerimiento. - Jorge Luis Oviedo Aguilar

13.4.5. Reducen el costo del cambio. Ya que evitan que se descubran los defectos hasta el final del desarrollo de software. -Mauricio Ricardo melchor andrade

13.5. Herramientas

13.5.1. JMeter: una herramienta para realizar pruebas de rendimiento. - Jorge Luis Oviedo Aguilar

13.5.2. Selenium: Selenium es un conjunto de herramientas de software diferentes, cada una con un enfoque diferente para soportar la automatización de pruebas. - Jorge Luis Oviedo Aguilar

14. Proceso Básico

14.1. Plan de pruebas: Documento que describe el alcance, método, recursos y cronograma de actividades de pruebas previstas. Es un registro del proceso de planificación de pruebas. --> Nathaly N. Dimas C.

14.1.1. Necesita

14.1.1.1. Condición de prueba: Ítem o evento de un componente o sistema que pudiera ser verificado por uno o mas casos de prueba. --> Nathaly N. Dimas C.

14.1.2. Genera

14.1.2.1. Estrategia de pruebas: Descripción de alto nivel de los niveles de pruebas que deben ser realizados y las pruebas de esos niveles para una organización o programa. --> Nathaly N. Dimas C.

14.1.2.2. Caso de prueba: Un conjunto de valores de entrada, pre condiciones de ejecución, resultados esperados y pos condiciones de ejecución, desarrollados para un objetivo o condición de prueba particular. --> Nathaly N. Dimas C.

14.2. Documentación del proceso

14.3. Calidad: El grado en el cual un componente, un sistema o un proceso cumple con los requisitos especificados y/o las necesidades y las expectativas del usuario/cliente. --> Nathaly N. Dimas C.

14.4. Especifica

14.4.1. Cobertura: Grado, expresado como porcentaje, hasta el cual un ítem ha sido probado. --> Nathaly N. Dimas C.

15. Ética

15.1. EL PÚBLICO

15.1.1. Los ingenieros del software actuarán de manera consistente con el interés general. Blanca Leticia Guerra

15.1.1.1. Principios como público:

15.1.1.1.1. Aceptar completa responsabilidad por su trabajo.

15.1.1.1.2. Moderar los intereses del ingeniero del software, el empresario, el cliente y los usuarios con los del bienestar público.

15.1.1.1.3. Dar el visto bueno al software sólo si se tiene fundada creencia de que es seguro, cumple las especificaciones, ha pasado las pruebas pertinentes y no disminuye la calidad de la vida, disminuye la confidencialidad o daña al medio ambiente. El efecto último del trabajo debiera ser el bienestar público.

15.1.1.1.4. Cooperar en las materias relacionadas con las preocupaciones graves causadas por el software, su instalación, mantenimiento, soporte o documentación.

15.1.1.1.5. Mostrar a las personas o autoridades correspondientes cualquier peligro real o potencial para el usuario, la sociedad o el medio ambiente, que consideren, de manera razonable, que esté asociado con el software, o documentos relacionados.

15.1.1.1.6. Ser justo y veraz en todas las afirmaciones, especialmente en las que sean públicas, relativas al software o documentos relacionados, métodos y herramientas.

15.1.1.1.7. Considerar las cuestiones de discapacidades físicas, asignación de recursos, desventajas económicas y otros factores que puedan disminuir el acceso a los beneficios del software.

15.1.1.1.8. Estar dispuesto a donar las capacidades profesionales para buenas causas y contribuir a la educación del público en general con respecto a esta disciplina.

15.1.1.1.9. Rodrigo Alejandro Martinez Sanchez

15.2. EL CLIENTE Y EMPLEADOR

15.2.1. Los ingenieros de software deberán actuar de maneras en que se representen los mejores intereses para sus clientes y empresarios, consistentemente con el interés general. Blanca Leticia Guerra

15.2.1.1. Principios como cliente y empleador:

15.2.1.1.1. Proporcionar servicios sólo en las áreas de su competencia, siendo honestos y francos acerca de cualquiesquiera limitaciones en su experiencia o educación.

15.2.1.1.2. No utilizar conscientemente software obtenido o retenido de manera ilegal o no ética.

15.2.1.1.3. Utilizar la propiedad de un cliente o patrón sólo en maneras adecuadamente autorizadas, y con el conocimiento y consentimiento de los mismos.

15.2.1.1.4. Garantizar que cualquier documento en el que se confía ha sido aprobado, cuando así se requiera, por alguien con autoridad para hacerlo.

15.2.1.1.5. Mantener como privada cualquier información confidencial obtenida mediante el trabajo profesional, siempre que tal confidencialidad no sea inconsistente con los aspectos de interés general y con la ley.

15.2.1.1.6. Identificar, documentar, recoger evidencia e informar con prontitud al cliente o empresario si, en su opinión, es probable que fracase un proyecto, que se demuestre demasiado caro, que viole la legislación sobre propiedad intelectual, o que sea problemático.

15.2.1.1.7. Identificar, documentar e informar al empresario o cliente sobre cualquier asunto de interés social, o del que se tenga conocimiento, acerca del software o documentos relacionados.

15.2.1.1.8. No aceptar trabajo externo que vaya en detrimento del trabajo que se desarrolle para su principal contratante.

15.2.1.1.9. No representar interés contrario al del empresario o cliente, a menos que se comprometa otro valor ético más elevado; en este último caso se informará al empresario o a otra autoridad adecuada acerca de esa preocupación ética.

15.2.1.1.10. Rodrigo Alejandro Martinez Sanchez

15.2.2. Los ingenieros de software deberán progresar en la integridad y reputación de la profesión, consistentemente con el interés general.Blanca Leticia Guerra

15.2.2.1. Los ingenieros de software deberán garantizar que sus productos y las modificaciones relacionadas cumplen los estándares más elevados posibles. Blanca Leticia Guerra

15.2.2.1.1. Identificar, definir, y examinar temas éticos, económicos, culturales, legales y medioambientales relacionados con cualquier proyecto. Blanca Leticia Guerra

15.3. EL PRODUCTO

15.4. LA GESTIÓN

15.4.1. Los gestores y líderes en ingeniería del software suscribirán y promoverán un enfoque ético a la gestión del desarrollo y mantenimiento del software. Blanca Leticia Guerra

15.5. LA PROFESIÓN

15.6. LOS COLEGAS

15.6.1. Los ingenieros de software serán justos y serán soporte de sus compañeros. Blanca Leticia Guerra

15.6.1.1. Ayudar a los compañeros en el desarrollo profesional. Blanca Leticia Guerra

15.6.1.2. Reconocer completamente el trabajo de otros y abstenerse de atribuirse méritos no reconocidos. Blanca Leticia Guerra

15.6.1.3. Revisar el trabajo de otros de forma objetiva, sincera y adecuadamente documentada. Blanca Leticia Guerra

15.7. UNO MISMO

16. Ejemplo

16.1. Pruebas unitarias ->Alan Mauricio

16.1.1. Jest js ->Alan Mauricio

16.1.2. unittest python -> Alan Mauricio

16.1.3. Mocha js -> Alan Mauricio

16.1.4. Clover o Cobertura -> Joel Sabethai Carranza Pintor

16.1.5. En las metodologías ágiles son los ingenieros de desarrollo los encargados de ejecutar este tipo de pruebas mediante pruebas unitarias. -Mauricio Ricardo Melchor andrade

16.2. GUI Test->Alan Mauricio

16.2.1. OPEN HMI TESTER

16.2.1.1. Se Divide En

16.2.1.1.1. Módulo HMI Tester: tienecomoprincipalcometidoelcontrolarlosprocesos de grabacion (captura de eventos) y de reproduccion (ejecucion de eventos), ası como la gestion completa de la creacion y el mantenimiento de los archivos de pruebas (test suites). -Jorge Luis Ponce Rivera

16.2.1.1.2. El Módulo Preload: Es inyectado en la aplicación testada como una librería dinámica, con el fin de añadir la funcionalidad deseada. Su principal cometido será la captura de datos y eventos GUI, y también la ejecución de los eventos y ordenes recibidas desde el módulo HMI Tester. -Jorge Luis Ponce Rivera

16.2.1.2. Procesos

16.2.1.2.1. Anotación de la GUI: Durante este proceso se van anotando, uno por uno, los elementos cuyos valores puedan variar (cada nuevo valor da lugar a un nuevo caso de prueba) y los que tengan alguna propiedad que deba ser validada (se introducirán nuevas reglas de validación para estos elementos). -Jorge Luis Ponce Rivera

16.2.1.2.2. Generación Automática de Casos de Prueba: Se generará un nuevo caso de prueba para cada posible combinación de valores, y también se añadirán puntos de validación para satisfacer las reglas especificadas en la fase anterior. -Jorge Luis Ponce Rivera

16.2.1.2.3. Ejecución y Validación: En este proceso los casos de prueba generados en el paso anterior son ejecutados. Finalmente el proceso devuelve un informe en el que incluye el resultado (prueba superada o no con éxito) de cada uno de los casos de prueba ejecutados junto con el de las validaciones. -Jorge Luis Ponce Rivera

16.2.1.3. Funcionamiento

16.2.1.3.1. Comunicación

16.2.1.3.2. Acceso a la aplicación

16.2.1.4. ¿que es ? se trata de una arquitectura abierta ) para pruebas de interfaz grafi ca. -mauricio ricardo melchor andrade

16.2.1.5. Ventajas

16.2.1.5.1. Open HMI tester, al poder capturar de manera real los eventos y datos de las aplicaciones no tiene rehacer sus tests si la ventana de la aplicación a probar es más grande, le agregan más elementos, etc. -> Torres Heras Miguel Angel

16.2.1.5.2. evita crear modelos pesados y de enormes baterías de casos de prueba.-> Torres Heras Miguel

16.2.1.5.3. Su funcionamiento también puede ir acompañado de procesos de validación automática mediante la incorporación de eventos especiales. -> Torres Heras Miguel

16.2.2. Selenium -->Alan Mauricio

16.2.2.1. plataforma

16.2.2.1.1. web

16.2.2.2. Lenguajes -> Joel Sabethai Carranza Pintor

16.2.2.2.1. Java

16.2.2.2.2. PHP

16.2.2.2.3. C#

16.2.2.2.4. Phyton

16.2.2.2.5. Groovy

16.2.2.2.6. Perl

16.2.2.3. Ruby

16.2.3. AutoHotkey -->Alan Mauricio

16.2.3.1. lenguajes

16.2.3.1.1. script

16.2.3.1.2. bash

16.2.4. Robot Framework -->Alan Mauricio

16.2.4.1. plataformas

16.2.4.1.1. jvm

16.2.4.1.2. .NET

16.2.5. Watir -->Alan Mauricio

16.2.5.1. Lenguajes -> Joel Sabethai Carranza Pintor

16.2.5.1.1. Ruby

16.2.5.2. Compatibilidad con herramientas orientadas a negocios -> Joel Sabethai Carranza Pintor

16.2.5.2.1. RSpec

16.2.5.2.2. Cucumber

16.2.5.2.3. Test/Unit

16.2.6. Dojo Toolkit -->Alan Mauricio

16.2.6.1. lenguajes

16.2.6.1.1. js

16.2.7. windows

16.2.8. Unified Functional Testing -->Torres Heras Miguel

16.2.8.1. plataformas

16.2.8.1.1. Java

16.2.8.1.2. .NET

16.2.8.1.3. Mobile

16.2.9. Squish GUI Tester-->Torres Heras Miguel

16.2.9.1. plataformas

16.2.9.1.1. iOS

16.2.9.1.2. Android

16.2.9.1.3. Java

16.2.10. Telerik TestStudio -> Joel Sabethai Carranza Pintor

16.2.10.1. Lenguajes

16.2.10.1.1. JS

16.2.10.1.2. HTML

16.2.10.1.3. ASP

16.2.10.1.4. Silverlight

16.2.10.1.5. WPF

16.2.10.1.6. Visual Basic

16.2.10.2. Plataformas

16.2.10.2.1. Desktop

16.2.10.2.2. Web

16.2.10.2.3. Mobile

16.2.11. Appium-> Torres Heras Miguel

16.2.11.1. plataformas

16.2.11.1.1. Windows

16.2.11.1.2. Linux

16.2.11.1.3. Android

16.2.11.1.4. Web

16.2.11.2. lenguajes

16.2.11.2.1. C#

16.2.11.2.2. Java

16.2.11.2.3. Python

16.2.11.2.4. JavaScript

16.2.11.2.5. PHP

16.2.11.3. Plataforma -> Joel Sabethai Carranza Pintor

16.2.11.3.1. Web

16.3. Anomalía: Cualquier cosa observada en la documentación o en la operación del software que se desvía de expectativas base del producto de software previamente verificados o los documentos de referencia.

16.4. Caso de Prueba: Un conjunto de entradas de prueba, de condiciones de ejecución, y de resultados previstos desarrollados para un objetivo particular, por ejemplo para realizar una trayectoria particular del programa o para verificar conformidad con un requisito específico

16.5. Componentes: Una de las piezas que integra un sistema. Un componente puede ser hardware o software y puede estar subdividido en otros componentes

16.6. Diseño de la prueba: Documentación que especifica los detalles del enfoque de la prueba para identificar una característica del software o combinación de características del software y las pruebas asociadas.

16.7. Descripción del diseño del software: Una representación de un sistema de software creada para facilitar el análisis, planeación, implementación, y toma de decisiones. Un esquema o modelo de un sistema de software.

16.8. Elemento: Un componente (Diseño, especificaciones, código fuente, documentación, conjunto de pruebas, manuales de procedimientos, etc) que se ha diseñado para el uso en contextos múltiples.

16.9. Entradas requeridas: El conjunto de elementos necesarios para realizar las tareas mínimas de VV dentro de cualquier actividad del ciclo de vida.

16.10. Especificación de requerimientos del software: Documentación de los requerimientos esenciales (funciones, rendimiento, restricciones del diseño, y cualidades o atributos) del software y de sus interfases externas.

16.11. Procedimiento de prueba: Instrucciones detalladas para la disposición, la ejecución, y la evaluación de los resultados para un caso dado de prueba. Un documento que contiene un conjunto de instrucciones asociadas. Documentación que especifica una secuencia de las acciones para la ejecución de una prueba.

16.12. Procesos del ciclo de vida: Conjunto de actividades correlacionadas que dan lugar al desarrollo o la evaluación de los productos de software. Cada actividad consiste en tareas. Los procesos del ciclo de vida pueden traslaparse uno con otro. Para los propósitos de VV, no se concluye ningún proceso hasta que sus productos del desarrollo se verifican y se validan según las tareas definidas en el PVV.

16.13. Validación: El proceso de evaluación un sistema o componente durante o en el final del proceso del desarrollo para determinarse si satisface los requerimientos especificados.

16.14. Mario Alberto Vega González

16.15. TestRail (De pago)-> Samuel Vieyra Maldonado

16.15.1. Software integral de gestión de casos de prueba basado en proyectos web para gestionar, rastrear y organizar de manera eficiente las de prueba de software.-> Samuel Vieyra Maldonado

16.15.2. Características -> Samuel Vieyra Maldonado

16.15.2.1. Puede trabajar con cualquier proyecto orientado en un entorno web, permitiendo la gestión total de las pruebas, requerimientos y la posibilidad de gestionar por secciones -> Samuel Vieyra Maldonado

16.15.3. Herramientas -> Samuel Vieyra Maldonado

16.15.3.1. Compatibilidad para el manejo de Git-> Samuel Vieyra Maldonado

16.15.3.2. Almacenamiento en la Nube-> Samuel Vieyra Maldonado

16.15.3.3. Generador de Reportes por sección -> Samuel Vieyra Maldonado

16.15.3.4. Gráficos precisos de los datos de las pruebas y efectividad de cada uno de los integrantes del equipo -> Samuel Vieyra Maldonado

16.15.3.5. Configurador de pruebas de todo tipo, con la opción de hacer las pruebas en diferentes navegadores-> Samuel Vieyra Maldonado

16.15.3.6. Servicio de Control de la pagina web en el servidor-> Samuel Vieyra Maldonado

16.15.4. Ventajas -> Samuel Vieyra Maldonado

16.15.4.1. Exportar los reportes en diferentes formatos-> Samuel Vieyra Maldonado

16.15.4.2. Gestión completa de las pruebas y más de un sistema particular-> Samuel Vieyra Maldonado

16.15.4.3. Interfaz intuitiva y de fácil uso-> Samuel Vieyra Maldonado

16.15.4.4. Asignación de actividades y envío de emails a los colaboradores-> Samuel Vieyra Maldonado

16.15.4.5. Flexible y capacitado pero el uso en equipo y de uso remoto-> Samuel Vieyra Maldonado

16.15.4.6. Adaptable para el uso de diferentes metodologías de desarrolllo-> Samuel Vieyra Maldonado

17. Pruebas con enfoque convencional Diana Edda Espinosa Ovando

17.1. Pruebas relacionadas

17.1.1. Pruebas unitarias

17.1.1.1. Debe ser automatizable-->Torres Heras Miguel

17.1.2. Pruebas de integración

17.1.2.1. Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que prueban es que todos los elementos unitarios que componen el software, funcionan juntos correctamente probándolos en grupo - mauricio ricardo melchor andrade

17.1.3. Pruebas de aceptación

17.1.4. Pruebas de sistema

17.2. Dirección del desarrollo

17.2.1. Especificación de requisitos

17.2.1.1. Analisis y diseño -->Alan Mauricio

17.2.1.1.1. Implementación -->Alan Mauricio

17.2.2. Código

17.2.3. Casos de prueba

17.3. Objetivo principal de las pruebas en este enfoque

17.3.1. Comprobar que el desarrollo realizado cumple los requisitos definidos

17.4. Estas dependen directamente del resto de actividades del proceso de desarrollo. -> Joel Sabethai Carranza Pintor

17.4.1. En consecuencia se comprueba que casi en el 60% de los proyectos, las pruebas se diseñan cuando ya está el código o cuando se comienza la fase de pruebas. -> Joel Sabethai Carranza Pintor

18. Pruebas en las metodologías ágiles Diana Edda Espinosa Ovando

18.1. Función de las pruebas

18.1.1. Las historias de usuario con conjunto con las pruebas asociadas a cada una juegan el papel de especificaciones del sistema.

18.1.2. Esto ha traído como consecuencia una mejora de la calidad de los productos entregados en casi un 70% de los proyectos.

18.2. Pruebas relacionadas

18.2.1. TDD

18.2.1.1. Tiene como objetivo comprobar que la aplicación funcionara correctamente -> Joel Sabethai Carranza Pintor

18.2.2. ATDD

18.2.2.1. Se basa en pruebas de aceptación, toma como referencia al usuario -> Joel Sabethai Carranza Pintor

18.2.3. STDD

18.2.3.1. Es una extensión de TDD pero enfocado a prueba de aceptación de nivel superior -> Torres Heras Miguel

18.3. Establecimiento de requisitos

18.3.1. Historias de usuario

18.3.2. Criterios de aceptación

18.3.3. Casos de prueba

18.3.4. Codigo

18.4. No se distingue de forma específica las pruebas de integración sino que éstas simplemente se incorporan al conjunto de las pruebas que se definen ya sea en la aplicación de TDD o de ATDD

18.5. Las metodologías ágiles más populares y que hacen mayor hincapié son -> Torres Heras Miguel Angel

18.5.1. SCRUM

18.5.2. XP

18.6. enfoque de agil a pruebas -mauricio ricardo melchor andrade

19. En metodologías ágiles. Angel Yáñez.

19.1. Agile Testing. Angel Yáñez.

20. Es una práctica enfocada en pruebas de software para las metodologías ágiles. En ella se hace un enfoque en utilizar a todo el equipo para el testeo y que éste se realice de manera continua. Angel Yáñez.

21. Contiene una serie de principios enfocados en el Testeo Ágil Angel Yáñez.

22. Las pruebas no pertenecen a una fase. Angel Yáñez.

23. Las pruebas se realizan de manera continua junto con el desarrollo y las demás actividades del proyecto. Angel Yáñez.

24. Las pruebas hacen avanzar el proyecto. Angel Yáñez.

25. Al realizar las pruebas de manera continua, los errores se corrigen en el momento y permite que el proyecto avance a buen pie. Angel Yáñez.

26. Todo el equipo realiza pruebas. Angel Yáñez.

27. Tanto los testers como los analistas y desarrolladores deberán realizar las pruebas. Angel Yáñez.

28. Reducir tiempo de retroalimentación. Angel Yáñez.

29. Esto se logra gracias a que los expertos en el negocio están involucrados en cada iteración y no sólo en la fase de aceptación. Angel Yáñez.

30. Guiado por pruebas. Angel Yáñez.

31. Las pruebas siempre se harán durante el desarrollo y no después del mismo. Angel Yáñez.

32. Posee una serie de prácticas. Angel Yáñez.

33. Agile Testing. Angel Yáñez.

34. Test Driven Development. Angel Yáñez.

35. Acceptance Test Driven Development. Angel Yáñez.

36. Behaviour Driven Development. Angel Yáñez.

37. Testing exploratorio. Angel Yáñez.

38. Automatización de pruebas unitarias. Angel Yáñez.