EliasExamen

son importantes porque aseguran el correcto cuumplimineto de la funcionalidad del producto, ayudan a ganar confianza, confirman la fiabilidad del uso y previenen defectos en produccion.

Donde se hace un esquema de ¿que se va a probar? ¿como se va a probar? ¿quien lo va a probar? y ¿cuando? A la salida de esta fase podemos mencionar que se obtiene un plan de pruebas maestro que incluye estrategia y enfoque de pruebas.

en esta fase se analizan los requerimientos y se diseñan los casos de prueba, incluyendo en esta actividad casos de prueba positivos y casos de prueba negativos

En esta fase es donde determinamos si se han alcanzado los objetivos de las pruebas, es decir, si la implementación de los requerimientos fue la óptima, lo ideal es que el usuario realice también otras pruebas para dar el visto bueno a la aplicación y ésta pueda ser puesta en producción.

Esta fase es la más importante ya que, es donde los casos de prueba son ejecutados en un ambiente de prueba o calidad para validar que los requerimientos especificados se hayan implementado de la manera correcta, es en este punto donde se aplica la estrategia de pruebas.

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

Son los requerimientos que el usuario define y exige de manera clara y precisa

Son los requerimientos que aunque el usuario no los especifique espera que el sistema sea entregado con estos

Documentacion que espefica las acciones a seguir para llegar a un objetivo especifico (resultado esperado) que contiene datos o deberia contener datos de entrada, resultados esperados y un conjunto de condiciones de ejecucion de un elemento de prueba.

Son diseñados con la intención de romper el requerimiento, módulo o sistema a probar, es decir, comprueban situaciones en las que hay tratamientos con errores, por ejemplo: datos de entrada inválidos.

Escenario default de un requerimiento. No se consideran caminos alternos, excepcionales o condiciones de error.

Son aquéllos que se diseñan para probar el requerimiento tal cual se diseñó y construyó. Estos casos de prueba aseguran que las funciones descritas en los casos de uso o requerimientos funcionales realmente estén implementadas en el sistema o módulo que se esté probando y que funcionen como se definieron. Muestran funcionalidad.

En el proceso de pruebas se registran los problemas encontrados o las incidencias detectadas. Dicho de manera técnica un desperfecto en un componente o sistema que puede causar que el sistema falle en desempeñar las funciones requeridas, por ejemplo: una sentencia o una definición de datos incorrecta.

Es el medio de trabajo para la aplicacion de pruebas de software, como documentacion, scripts , resultados esperados, configuracion, procedimientos, archivos, base de datos, y cualquier software adicional o servicios utilizados en pruebas.

Persona que asegura que el equipo de desarrollo ofrece la calidad necesaria a sus clientes. Centrandose en la entrega de un producto que proporcione mas valor que el negocio.

Se hace referencia a los componentes como módulos, clases o unidades, debido a que los desarrolladores pueden estar involucrados en la ejecución de pruebas, pueden llamarse también pruebas de desarrollador. Es importante mencionar que estas pruebas las ejecuta el desarrollador verificando que su código cumple con lo solicitado y no ha violado ningún estándar que ponga en riesgo la estabilidad del sistema.

también son conocidas como pruebas de interfaz, ya que comprueban la interacción entre componentes. Las pruebas de integración asumen que los módulos ya han sido probados de manera individual (pruebas unitarias).

Cuando el desarrollo del sistema comienza con piezas unitarias y crece hasta formar modulos

cuando se muestra el front de la aplicacion pero esta hueca por dentro y se comienza a trabajar desde los modulos mas grandes hasta llegar al detalle o en las partes unitarias

. Que va de la mano con xtreme programing porque el desarrollo no tiene un orden específico y puede ser al azar.

Se llevan a cabo cuando todo el desarrolo ha sido culminado y tenemos una version preliminar del sistema que saldra a produccion. consiste en probar un sistema integrado con el objeto de comprobar el cumplimiento de requisitos especificados.

El objetivo de este nivel de prueba es obtener el visto bueno del cliente, no se deberian encontrar defectos funcionales graves en el sistema.

El cliente utiliza el software para hacer el tratamiento de sus procesos de negocio en las dependencias del proveedor

Estas se ejecutan en las dependencias del cliente

se enfocan en validar la correcta implementación de las necesidades del cliente. La funcionalidad puede ser vinculada a los datos de entrada y de salida. Los datos de entrada serán ejecutados y mostrarán un resultado y dicho resultado será comparado con el resultado esperado (comportamiento)

Se enfocan a las características de un software

[blank_start]carga[blank_end] Pruebas a un sistema cubriendo la demanda esperada.

[blank_start]rendimiento[blank_end] Rapidez con la cual un sistema ejecuta una determinada función.

[blank_start]Estres[blank_end] Someter a la aplicación a una carga mucho mayor a la esperada y evaluar la capacidad del sistema de seguir su operación después de este tipo de demanda.

se enfocan a revisar el código y su estructura. No es más que asegurarnos que todo el código es ejecutado con los casos de prueba diseñados, de esa manera se evita que existan ramas muertas o código inaccesible.

El objetivo de estas pruebas es validar que la funcionalidad que ya se ha validado siga igual después de una modificación al código, hablamos de re-test, y pruebas de regresión, es decir, probar después de algún cambio.

[blank_start]prueba de regresión[blank_end] :Repetir una prueba de funcionalidad que ha sido verificada previamente.

comprenden métodos donde no se ejecutan los componentes u objetos de prueba (sistema).

Este análisis se lleva a cabo sobre el código fuente, consiste en analizar un objeto de prueba sin llevar a cabo la ejecución del mismo.

examinan la parte interna del programa, siempre se está observando el código, y los casos de prueba están basados en la estructura interna del programa (figura 6.2). Por ello, la implementación de estas pruebas depende de la disponibilidad del código fuente. Este tipo de pruebas permiten generar casos para ejercitar y validar los caminos de cada módulo, las condiciones lógicas, los bucles, etcétera.

se enfoca en probar el sistema sin tomar en cuenta la estructura interna del mismo, su objetivo es validar que las salidas sean las esperadas. Se centra en encontrar las circunstancias en las que el sistema no se comporta conforme a las especificaciones establecidas.

En esta etapa se llevan a cabo las primeras actividades correspondientes al proceso de pruebas, tiene como resultado un entregable denominado plan de pruebas